cancel
Showing results for 
Search instead for 
Did you mean: 

SYMBIONT_xxx

 
SOLVED
Go to solution
Art Wiens
Respected Contributor

SYMBIONT_xxx

Is there an "easy" way to associate a SYMBIONT process pid with which queue it handles?

We "hit the ceiling" yesterday with MAXPROCESSCNT and the only unusual thing I noticed was about 70 SYMBIONT_xxx processes. I don't think there's that many print queues on that box.

Recent changes (~4 weeks ago) were DCPS v2.4 upgrade (from v2.3) ... no reboot was done at the time. I ran AUTOGEN and bumped up MAXPROCESSCNT and rebooted last night. System starts out with 15 SYMBIONTs and that sounds about right.

Alpha 800, 512MB, VMS v7.2-2, missing a few patches I'm sure ;-)

Cheers,
Art
53 REPLIES
Volker Halle
Honored Contributor

Re: SYMBIONT_xxx

Art,

if you do a SHOW PROC/ID= you'll see the allocated devices for that process. SHO QUE/DEV would show the device names together with the queue name.

PIPE SHOW DEV/FULL LT | SEA SYS$PIPE SYMBIONT should also provide similar results - assuming LAT device queues.

The DCPS$MAX_STREAMS logical will limit the no. of print-queue handled by one symbiont.

Maybe there was some problem with print-symbionts failing and being restarted, but not going away completely. Did you check OPERATOR.LOG (DCPS is good at writing error messages to OPCOM). Also check for *.DMP process dump files in SYS$MANAGER or SYS$SYSTEM

Volker.
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Sorry, no LAT, it's IP based printing and the BG device doesn't give any obvious clues.

$ show proc/id=212006f6

21-JUL-2005 12:27:40.47 User: SYSTEM Process ID: 212006F6
Node: xxxx Process name: "SYMBIONT_709"

Terminal:
User Identifier: [SYSTEM]
Base priority: 4
Default file spec: Not available
Number of Kthreads: 1

Devices allocated: BG452:

$ show dev/full bg452:

Device BG452:, device type unknown, is online, record-oriented device, network
device, mailbox device.

Error count 0 Operations completed 9
Owner process "SYMBIONT_709" Owner UIC [SYSTEM]
Owner process ID 212006F6 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
Reference count 1 Default buffer size 256

I'm thinking I have to do some incantation in SDA?

Art
Volker Halle
Honored Contributor

Re: SYMBIONT_xxx

Art,

does TCPIP SHOW DEV BG452 show a target IP address, which you could associate with the printer's IP ?

If you really want to do something with SDA, you could find the DEVICE_NAME in the SCB (Stream Control Block) structure in each symbiont process using SDA.

There is a SCB vector somewhere in P0 space of each symbiont process, which points to the SCBs for all streams. Inside the SCB, there is a pointer to the DEVICE_NAME string.

You just need to look at the source listings in [PRTSMB] to find the offset for psm$gl_scbvec in SMBSRVSHR.MAP - then you can locate the SCB vector and all the SCBs.

You could search with SDA in P0 space of a symbiont for 'BG'

SDA> set proc/ind=
SDA> SHOW PROC/PHD

SDA> SEA 0:/LENGTH=WORD/STEP=BYTE 4742

Volker.
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

It's TCPware ie. no SHOW DEVICE command.

Art
Jan van den Ende
Honored Contributor

Re: SYMBIONT_xxx

Art,

from your Forum Profile:


I have assigned points to 155 of 184 responses to my questions.


Maybe you can find some time to do some assigning?

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption < My Question(s) > you will find < questions or topics with unassigned points > Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. Nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before, then please do not take offence, certainly none is intended!

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Sheesh! How about now:

"I have assigned points to 185 of 185 responses to my questions. "

Even assigned points to those that hijacked my threads ;-)

Do you guys in Europe et al. see the tv show Drew Carey's - Whose Line Is It Anyways (yes I know it's a knock off of the English show) - to quote from the opening:

"A show where the answers are all made up and the points don't matter"

Cheers,
Art
Ian Miller.
Honored Contributor

Re: SYMBIONT_xxx

"Whose Line Is It Anyway" - a fine show best listened to on BBC Radio 4 (available world wide via the interweb).
____________________
Purely Personal Opinion
Antoniov.
Honored Contributor

Re: SYMBIONT_xxx

Art,
I have to thank you because you was the first fellow gave soem point to me some months ago.

Cheers.
Antonio Vigliotti

Antonio Maria Vigliotti
Antoniov.
Honored Contributor

Re: SYMBIONT_xxx

I guess you can do it with a dcl procedure.
At first galnce you could redirect output of "show dev bg" command to a file, than you could read sequentially line and ask for owner with F$GETDVI(,"OWNUIC").

Antonio Vigliotti
Antonio Maria Vigliotti
Wim Van den Wyngaert
Honored Contributor

Re: SYMBIONT_xxx

The queue manager is well aware of which process is handling which queue because it starts the process when needed and stops the queue(s) when you kill the process.

It would be a nice 8.2+ feature to return the pid as an item in f$getq.

Wim
Wim
Jan van den Ende
Honored Contributor

Re: SYMBIONT_xxx

So,

if I get 5 "Me too" votes, I will make it a formal request to Guy Peleg.
Count Wim as 1, and me as 2.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: SYMBIONT_xxx

And add /symbiont to show que. This should give the name and process id of the symbiont.

Wim
Wim
Ian Miller.
Honored Contributor

Re: SYMBIONT_xxx

me too :-)

Try adding it at
http://www.hpuseradvocacy.com/
____________________
Purely Personal Opinion
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Antonio, All the BG devices are owned by SYSTEM with the exception of two (TCPware_FTP and TCPware_NETCP) so that doesn't tell me.

There has to be a way other than Volker's "brute force" search through memory.

How about the reverse then, from a given queue, how do you determine which symbiont is running it?

On the system in question which started out with 15 SYMBIONT_xxx processes, now has 30 listed.

Cheers,
Art
Art
Antoniov.
Honored Contributor

Re: SYMBIONT_xxx

Art,
I've got a different system from you, so I'm not able to see same environment.
If you need to search all owner of BG devices which have process name beginning with SYMBIONT look at attached DCL procedure. It's just an example.

Antonio Vigliotti
Antonio Maria Vigliotti
Volker Halle
Honored Contributor

Re: SYMBIONT_xxx

Art,

which symbionts are your queues running (SHOW QUE/FULL queue will list the image as /PROCESSOR=xxx) ?

Do the symbionts have logfiles (SDA> SHOW PROC/CHAN/ID=) ? Do the logfiles tell you something ?

If the no. of symbionts keep increasing, you might be forced to use what you call my 'brute force attack' ;-)

If TCPware does not allow you to find the remote IP address associated with a BG device, the only place this information (queue <-> symbiont) can be located may be in the QUEUE_MANAGER (memory or qmgr database) or in the memory of the symbionts.

When re-thinking my SDA approach, I had to recognize, that it's not the BG device name, that's stored in the PSM$Q_DEVICE_NAME field of the SCB, but the string specified with the /ON=xxx qualifier of the queue. Once we've located the SCB vector inside SMBSRVSHR.EXE, it's getting easy to obtain the DEVICE_NAME for each SCB.

Volker.

Volker Halle
Honored Contributor

Re: SYMBIONT_xxx

Art,

the SCB type and size (Stream Control Block) did not change since a couple of VMS versions, so you should be able to easily locate the SCB in P0 address space of your print symbionts:

SDA> SET PROC/IND=
SDA> SHOW PROC/IMAGE
! verify that SMBSRVSHR is listed, if not - forget this method

SDA> SHOW PROC/PHD
First free P0 VA 00000000.002EC000 ...
...
SDA> SEA 0:2EC000 02E80103 ! use P0 addr from above
...
Match at 00000000.001D87A8 02E80103
...

SDA> def scb=001D87A8-8
SDA> exa @(scb+58);@(scb+54)&ff-1
3131313A 312E312E 312E3122 4000001A ...@"1.1.1.1:111 001BAB08
SDA> exa @(scb+68);@(scb+64)&ff
001B8010 40000012 54534554 40000012 ...@TEST...@.... 001B8800

(I had created a queue name TEST with /on="1.1.1.1:111" to easily locate the ASCII string in P0 space).

Repeat these step (starting with DEF SCB=xxx) for all matches found and you'll get the list of all queues and their /ON=xxx strings for this symbiont.

Volker.
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Volker, where does the value you're searching for come from? (02e80103)

When I do a SHOW PROC/IMAGE I do see SMBSRVSHR:

SMBSRVSHR 000D2000 001537FF GLBL SHR 7FF38D20

and from SHOW PROC/PHD I see:

First free P0 VA 00000000.0045E000

I think we're almost there ... you will be handsomely rewarded with "points" shortly ;-)

Cheers,
Art

ps. the queues' processor are either DCPS$SMB or TCPWARE_TSSYM
David Jones_21
Trusted Contributor

Re: SYMBIONT_xxx

On my system, the DCPS symbiont creates logicals of the form DCPS$_queuename_PID in the system logical name table for every DCPS queue running. The equivalence string of the logical is the PID of the corresponding symbiont process.
I'm looking for marbles all day long.
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Yes, the DCPS pid's are the "easy" ones.
David Jones_21
Trusted Contributor

Re: SYMBIONT_xxx

Correction: DCPS$queuename_PID is the logical (no underbar following the dollar sign).
I'm looking for marbles all day long.
Volker Halle
Honored Contributor

Re: SYMBIONT_xxx

Art,

02E80103 is the type/size field at offset 8 of the SCB data structure, it hasn't changed since many years, so it's a good 'constant' to search for ;-)

I've run my test on V8.2 and I know this value from V5.5 times. Back in 1992 there was the so-called 'looping LATSYM' problem, when the LATSYM process went into a CPU loop intermittently. I was involved in the diagnosis and solution of this problem in the good old days at Digital. So I still feel quite comfortable diagnosing SMBSRVSHR problems using SDA.

Volker.
Martin Vorlaender
Honored Contributor

Re: SYMBIONT_xxx

Art,

coming back to Volker's suggestion:
>>>
does TCPIP SHOW DEV BG452 show a target IP address, which you could associate with the printer's IP ?
<<<

and your answer:
>>>
It's TCPware ie. no SHOW DEVICE command.
<<<

Just for the sake of finding the target IP of a BG device, you can use TCPware's

$ NETCU SHOW CONNECTION /NUMERIC /NOHOST /NOALL

TCPware(R) for OpenVMS Active Internet Connections:

ID RecvQ SendQ Local Address Foreign Address State
-- ----- ----- ------------- --------------- -----
BG27 0 0 127.0.0.1.1035 127.0.0.1.705 ESTABLISHED
BG28 0 0 127.0.0.1.705 127.0.0.1.1035 ESTABLISHED
...

and filter out the line that holds the particular BG device.

cu,
Martin
Art Wiens
Respected Contributor

Re: SYMBIONT_xxx

Volker: I started doing the searches and didn't find any matches (I got "tired" after about 4 or 5 ;-). Would that mean that those are "orphaned" symbiont processes?

Martin: I don't see BGxx devices in TCPware NETCU SHOW, I only see INETxxxx connections. TCPware v5.6-2 .

There are 56 SYMBIONT processes now. We are having a DCPS problem where the queue shows BUSY, the entry shows STARTING but no printing occurs. A STOP/QUEUE/RESET gets it going. I'm wondering if this is leaving the old processes behind?

A posted solution to this problem is to define a logical DCPS$queue_name_NO_SYNC to avoid an initialization sequence at the printer, but it didn't "fix" the problem.

Anyways, one more time, does anyone know an "easy" way to determine if a process named SYMBIONT_xxx which has a BGxxx: device allocated, is still active or just debris?

Cheers,
Art