SYMBIONT_xxx

[Art Wiens]

"Please verify a working DCPS queue symbiont, whether you can find the SCB with SDA, so we know, that this method really works."

Doesn't seem to. I used the steps to look at an existing DCPS$qname_PID and didn't find the SCB. The image list is the same as I attached earlier for the other PID. As well, the P0 address is the same.(?)

"CTL$GQ_LOGIN"

The login time for the pid in the attachment matches when I rebooted the system a few weeks back. I would think it has to be an orphaned process if that pid doesn't match one of the current DCPS$*PID logicals, no?

"OPERATOR.LOG, DCPS is usually very good at sending error messages to OPCOM "

The pertinent DCPS messages in the log are one of three:

%DCPS-W-NOT_READY, Printer is not ready

%DCPS-I-PRINTERSTALLED, Printer "IP_RawTCP/aa.bb.cc.dd:9100" is stalled

%DCPS-F-CONTERMINATED, Connection abnormally terminated

The site has 8 of these printers (HP8000's and HP9050's). They print an awful lot and run the queues themselves. Corelating problems and log entries will be a "challenge".

In case some of you haven't looked at my forum profile, my Personal Quote stands ! ;-)

Cheers,
Art

[David Jones_21]

You could brute force it, copy SYS$SYSTEM:DCPS$SMB.EXE multiple times to DCPS$SMB_n.EXE and re-init each queue with a unique /processor image. I suspect you'll find that no particular queue is causing the zombies.

[Antoniov.]

Art,
I carefully reread the full thread and I'm convinced there is no direct solution.
I can't find any property to link queue with its executor.

Antonio Vigliotti

[Volker Halle]

Art,

if your 'problem symbionts' are all running DCPS$SMB.EXE and they do NOT have an appropriate DCPS$queuename_PID logical, I would consider them to be 'bad'.

DCPS may be using the SMB routines directly and not the PSM routines, which explains, why you can't find the SCB data structure in a working DCPS symbiont.

Finding your 'wedged' symbionts could be as follows:

look at all SYMBIONT_nnn processes
for of each process, check:
1) running image DCPS$SMB.EXE ?
2) is there a logical DCPS$*_
3) obtain CPU and IO count, wait some seconds and re-check CPU and IO. No change ?

If all above checks return true, use STOP/ID to get rid of symbiont. If you stop a SYMBIONT process, there will be 2 OPCOM messages from QMAN - but they won't tell you the affected Queue Name ;-( The queue - if it was really being handled by this symbiont - will go to STOPPED state. So if you do a SHO QUE/DEV/OUT=x.x before and after stopping the symbiont, you could do a DIFF and find out, which queue state has changed.

Volker.

[Antoniov.]

Finding your 'wedged' symbionts could be as follows:

look at all SYMBIONT_nnn processes
for of each process, check:
1) running image DCPS$SMB.EXE ?
2) is there a logical DCPS$*_
3) obtain CPU and IO count, wait some seconds and re-check CPU and IO. No change ?


The 3.th point is dangerous. If printer queue is idle for some seconds, you can kill active processor.
On other hand, I guess DCPS*_ exists even process is stalled.

Antonio Vigliotti

[Jan van den Ende]

Art (and others)

I sent a request to Guy Peleg to shine his light on this issue.

I am curious what he has to say.

Proost.

Have one on me.

jpe

[Guy Peleg]

How about:

pipe show queue/full | search sys$input "Server queue ","/PROCESSOR"


We'll consider adding

show queue/processor=name and show
queue/processor_ pid=xxxxxxxx into
a future release of the O/S

Guy

[Art Wiens]

Thanks Guy, but I'm not sure how that helps me in this instance.

There has been much discussion here, but the original question to the thread has not been answered (yet ;-).

I have not been able to find any link between a symbiont pid/process and which queue it belongs to - other than the obvious functioning DCPS queues.

Cheers,
Art

[Volker Halle · Accepted solution]

Art,

here we go...

The information is hidden in the QUEUE MANAGER database file (assuming the default queue manager name):

$ DUMP/REC/OUT=X.X SYS$SYSTEM:SYS$QUEUE_MANAGER.QMAN$QUEUES
$ SEARCH X.X /WIND=(5,12)

You'll find the extended PID in column 1 of the SDA> SHOW SUMM output or the SHOW PROC output /1st line).

The first line reported by SEARCH will show the queue name. The SYMBIONT PID is stored at offset 0x00B0 in each QUEUE record, which has a symbiont process associated.

It HAD to be in the file, because otherwise a QUEUE_MANAGER failover could not have worked !

Hope this is not again considered a 'brute force' solution ;-)

Volker.

[Volker Halle]

Art,

please find attached a little DCL procedure to report the queues and their associated symbiont extended PIDs ;-)

Tested on OpenVMS V8.2 with a small amount of queues. No guarantees included.

Volker.