Re: SYMBIONT_xxx

SOLVED

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

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

I'm looking for marbles all day long.

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.

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

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

Art,

which symbionts are we talking about, i.e. what main image is running in all those (4-5) SYMBIONT_xxx processes you've been looking into with SDA ?

What is it you didn't find: 02E80103 ?

Did you check any working SYMBIONT ? SHOW SYS/PROC=SYMBIONT* should show increasing IOs for the 'working' ones. If you find 02E80103 in a working symbiont, we know that we are on the right track.

STOP/QUE/RESET could probably leave bad symbiont processes around. If the symbiont did not really finish it's initialization, it may also hang around after a /RESET...

Did you check OPERATOR.LOG for any symbiont/queue_manager related messages ?

Volker.

Volker: as an example, attached is the results from trying to find out which queue SYMBIONT_695 belongs to using your steps.

Is this a "deceased" DCPS symbiont?

Art

Did you try using command "$ tcpip show device BGxxx" to see if it is bound to a socket? If so, the remote address should tell you which printer it was trying to connect to.

I'm looking for marbles all day long.

It's Process Software's TCPware not Digital's TCPIP ie. there is no TCPIP SHOW DEVICE command!

A DCL SHOW DEVICE gives what's in the attachment.

A NETCU SHOW CONNECTION doesn't show any BGxx: devices, only INETxxxx: .

Art

Art,

if these are DCPS$SMB symbionts, you may want to check, if the DCPS$queuename_PID logical exists. If not, this may already be an indication of a 'bad' symbiont process.

Please check OPERATOR.LOG, DCPS is usually very good at sending error messages to OPCOM (consider to enable your terminal as an OPERATOR terminal with REPLY/ENABLE when troubleshooting DCPS printer problems).

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

Note that you can easily find out with SDA, when a process has been started:

SDA> SET PROC/IND=
SDA> EXA/time CTL$GQ_LOGIN

I noted that the IO operations count on the BG15: device is quite high, also the accumulated CPU time for SYMBIONT_695. For a non-working symbiont, why would it consume CPU and IOs ?

Volker.