| >>> In the cases of the no response systems noted above, we get no response
>>> on OPA0 from either PCM or (using an a/b switch) the direct connect
>>> terminals available to the system. OPA0 is logging errors (about
>>> 1/second) and the Device Status is either TIM, INT, ONLINE, TIMEOUT or
>>> TIM, INT, ONLINE, BSY.
On a VAX 7740 running OpenVMS 6.1 VAX we experienced a similar problem
yesterday. All of the above symptoms were there. BTW, PCM 1.6-300 on OpenVMS
6.2 AXP.
>>> In one case, there was an owner of the OPA0 device - we stopped the
>>> process successfully, but still get no reaction from
>>> the system.
We also had an operator logged onto the VAX from the PCM and when we
stopped the process it didn't matter either. Errors kept logging in the
count not the error log.
We also run a logging program and when I looked at the operator's
log for that time period yesterday he was running a repetitive SHOW QUEUE
command in the middle of that got a %RMS-W-TMO, timeout period expired
error message which kept repeating (I guess until we stopped the process).
We eventually did a shutdown and re-boot. Once the machine was
shutdown the operator was able to do a Ctrl-P.
>>> Is this a known problem? Is there any fix for it (other then shutting
>>> down and doing an init, which is not an option for this customer
>>> currently)? Anything else I should look at? What further information
>>> will I need to provide if I have to escallate this (which seems fairly
>>> likely at this point)?
Any status on this problem as of today?
|
|
Hi,
Are there any further updates on this problem?
I have a customer in the UK who has very similar symptoms:
errors on opa0. opa0 times out, loss of Opcom, no response
on PCM or a directly connected terminal.
console firmware is 4.3-3842
vax7720 running vms v6.1
connected via decserver (v3.3 bl39)
to PCM system (vax vms 6.2)
The current theory is a h/w problem on the 7720 is the cause, but
I believe this could still be a firmware problem. Any help
appreciated.
thanks
Brian
|