Discussion:
Opa0 in TIMOUT state
Add Reply
abrsvc
2021-07-07 16:36:51 UTC
Reply
Permalink
Anyone seen this before? I have a customer with the terminal device in TIMOUT state. I've not seen this before nor can I figure out how it got into this state. It does not seem to impact the system at all other than showing increasing errors for the device every time a reply message is received by the console.

Ideas?

Thanks,
Dan
Simon Clubley
2021-07-07 17:23:53 UTC
Reply
Permalink
Post by abrsvc
Anyone seen this before? I have a customer with the terminal device in TIMOUT state. I've not seen this before nor can I figure out how it got into this state. It does not seem to impact the system at all other than showing increasing errors for the device every time a reply message is received by the console.
Ideas?
Never seen _that_ one before. :-)

What's the allocation status and reference count for OPA0: ?

Can you post a $ show device opa0: ?

Has someone been playing with opening OPA0: directly while SHARE
privilege was enabled ?

What are the terminal settings for OPA0: ? Could modem control signals
come into play for example ? If so, has the cable for OPA0: been damaged ?

What is OPA0: actually connected to ? A dumb terminal or something else ?

I suppose you have tried typing Ctrl-Q on the console just in case ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-07-07 17:48:11 UTC
Reply
Permalink
Post by Simon Clubley
Post by abrsvc
Anyone seen this before? I have a customer with the terminal device in TIMOUT state. I've not seen this before nor can I figure out how it got into this state. It does not seem to impact the system at all other than showing increasing errors for the device every time a reply message is received by the console.
Ideas?
Never seen _that_ one before. :-)
What's the allocation status and reference count for OPA0: ?
Can you post a $ show device opa0: ?
Has someone been playing with opening OPA0: directly while SHARE
privilege was enabled ?
What are the terminal settings for OPA0: ? Could modem control signals
come into play for example ? If so, has the cable for OPA0: been damaged ?
What is OPA0: actually connected to ? A dumb terminal or something else ?
I suppose you have tried typing Ctrl-Q on the console just in case ? :-)
Another idea:

Have you examined the data structures to locate and view the _input_
buffer for OPA0: ? Is the input buffer full for some reason or does
it have junk in it ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Volker Halle
2021-07-07 17:52:06 UTC
Reply
Permalink
Dan,

could this be related (you didn't specify type of system and/or OpenVMS version) ?

https://community.hpe.com/t5/Operating-System-OpenVMS/OPA0/td-p/4049992#.YOXpGDNxfcs

Volker.
abrsvc
2021-07-07 18:02:59 UTC
Reply
Permalink
Post by Volker Halle
Dan,
could this be related (you didn't specify type of system and/or OpenVMS version) ?
https://community.hpe.com/t5/Operating-System-OpenVMS/OPA0/td-p/4049992#.YOXpGDNxfcs
Volker.
I should have known better, but the configuration is as follows:

VAX 4000 model 108. OpenVMS version 7.3

The error count appears to increase when any reply/all is performed or any operator message is sent to OPA0.

This is in a virtual environment where OPA0 us channelled to a socket connection. Unknown details about that connection.

Dan
Simon Clubley
2021-07-07 18:14:41 UTC
Reply
Permalink
Post by abrsvc
This is in a virtual environment where OPA0 us channelled to a socket connection. Unknown details about that connection.
Well that changes things.

This could easily be an emulator bug or a problem triggered by
a genuine external event with the socket.

If the emulated OPA0: is an emulated serial port, have you checked
the serial port device registers as seen by VMS to see if something
is stuck on or off in the status bits that should not be ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-07-07 18:27:55 UTC
Reply
Permalink
Post by abrsvc
Post by Volker Halle
Dan,
could this be related (you didn't specify type of system and/or OpenVMS version) ?
https://community.hpe.com/t5/Operating-System-OpenVMS/OPA0/td-p/4049992#.YOXpGDNxfcs
Volker.
VAX 4000 model 108. OpenVMS version 7.3
The error count appears to increase when any reply/all is performed or any operator message is sent to OPA0.
This is in a virtual environment where OPA0 us channelled to a socket connection. Unknown details about that connection.
Dan
Has the socket simply lost it's connection?
Is it something remotely that connects to this socket?

I would expect a lost socket connection to look like
an LA120 that is out of paper...
Post by abrsvc
Unknown details about that connection...
Probably the key words here.
abrsvc
2021-07-07 19:58:51 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Volker Halle
Dan,
could this be related (you didn't specify type of system and/or OpenVMS version) ?
https://community.hpe.com/t5/Operating-System-OpenVMS/OPA0/td-p/4049992#.YOXpGDNxfcs
Volker.
VAX 4000 model 108. OpenVMS version 7.3
The error count appears to increase when any reply/all is performed or any operator message is sent to OPA0.
This is in a virtual environment where OPA0 us channelled to a socket connection. Unknown details about that connection.
Dan
Has the socket simply lost it's connection?
Is it something remotely that connects to this socket?
I would expect a lost socket connection to look like
an LA120 that is out of paper...
Unknown details about that connection...
Probably the key words here.
I would have expected the opa0 port to be in an Xoff state if the socket connection were severed rather than just a timeout state. Am I correct in this?

The terminal state was as expected except for the timeout state.
Volker Halle
2021-07-08 17:58:23 UTC
Reply
Permalink
Dan,

the EXE$TIMEOUT routine scans the UCB device database every second and - if timeouts for a device are enabled and UCB$L_DUETIM for this device is LEQ EXE$GL_ABSTIM, then the device is marked as 'timed out' by setting bit UCB$M_TIMOUT and the drivers timeout routine is called.

Trying to write any messages to a 'timed out' device will result in an error...

If this happened on an emulated VAX, did you check the emulator logfile ? May be some interrupt got lost ?

Volker.
Simon Clubley
2021-07-08 18:03:01 UTC
Reply
Permalink
Post by abrsvc
I would have expected the opa0 port to be in an Xoff state if the socket connection were severed rather than just a timeout state. Am I correct in this?
I wouldn't be too sure about that. The error might be getting reported
within VMS at a much lower level than this, which is why I wondered what
the device status registers looked like under VMS for the emulated
console serial port.

Assuming the emulator is running under another normal environment such as
Linux, have you looked to see what the socket state is on the operating
system running the emulator ?

BTW, it's not fully clear from your original message whether the console
messages appear on OPA0: anyway but with an increase in the error
count, or if they are silently lost. Which one is it ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Loading...