The behaviour you describe is a feature of IP protocol. One of the
reasons IP is often claimed to be "more efficient" than DECnet is that,
unlike DECnet, IP does not "monitor" the link, periodically checking
that both ends are still alive. If an application attempts to use the
link, after it's broken, it will receive an error. It's then up to the
application to do somethine about it. However if there are no requests
made, the application doesn't know the link has gone. In your case, an
I/O has been posted, but it won't time out. This is both an advantage and
a disadvantage. For example, you may be able to break a link (say hang up
a modem), then later reestablish it, without the "participants" knowing.
The disadvantage is that all applications which use the network must
implement their own timeout/retry/abort/whatever algorithms or you can
end up with processes which hang around unaware that their network
partner has gone away. TELNET is an example of an application which
doesn't perform such checks.
However, all is not lost if you are using UCX for TCP/IP. You can
configure your TELNET sessions to use virtual terminals with the
command:
$ UCX SET COMMUNICATION/REMOTE_TERMINAL=VIRTUAL
The effect is that your physical TNAxx terminals will be placed
"behind" a VTAxx device. OpenVMS will detect any disconnections. The
TNAxxx process will be deleted after (SYSGEN) TTY_TIMEOUT seconds
unless the user logs in again, in which case they will be given the
option to reconnect to their existing session and pick up where they
left off (very handy if your PC crashes or modem drops in the middle of
a 2 hour edit session!).
The default TTY_TIMEOUT is 15 minutes. You can adjust it up or down
dynamically according to your needs.
