SYMBIONT_xxx

[Art Wiens]

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

[Volker Halle]

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]

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]

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]

It's TCPware ie. no SHOW DEVICE command.

Art

[Jan van den Ende]

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

[Art Wiens]

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.]

"Whose Line Is It Anyway" - a fine show best listened to on BBC Radio 4 (available world wide via the interweb).

[Antoniov.]

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

Cheers.
Antonio Vigliotti

[Antoniov.]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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

[Wim Van den Wyngaert]

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

Wim

[Ian Miller.]

me too :-)

Try adding it at
http://www.hpuseradvocacy.com/

[Art Wiens]

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.]

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

[Volker Halle]

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]

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]

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]

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.

[Art Wiens]

Yes, the DCPS pid's are the "easy" ones.

[David Jones_21]

Correction: DCPS$queuename_PID is the logical (no underbar following the dollar sign).

[Volker Halle]

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]

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]

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