Sessions not terminating on terminal disconnect

[Randy Hancock]

That is a possible solution to shift users over to the other system. As I mentioned earlier, tcp_keepidle is already set to 150 on the ES40 system. So, only the ES47 needs to have TCPIP restarted.

It may be several days before this opportunity arises.

[Jan van den Ende]

Randy,

if you go this way (and I think you should, one way or another) you should also enable Virtual Terminal (and this is from biological memory, so please verify: ISTR that it is by adding %X2000 to SYSGEN param TTY_DEFCHAR2 ).
Various applications (among them certainly Progress) will have the disconnected sessions (pseude-randomly, ie, if they happen to try to communicate with the remote end of the session) enter ComputeBound COM state, which again will prevent timeout...
We had quite some "interesting" time to learn this the hard way.

Success.

Proost.

Have one on me.

jpe

[John Gillings]

Randy,

I'm amazed at the amount of discussion here before someone finally mentioned virtual terminals! (thanks Jan!)

Rather than kill the process on a disconnection, allow your users to reconnect to the same session. No lost work or context. This can be VERY handy if you have bouncy comms links.

On OpenVMS Alpha, to enable virtual terminals, set the DISCONNECT bit in SYSGEN parameter TTY_DEFCHAR2. Add %X20000 (not %X2000 - you were close Jan!)

In your startup, add the line:

$ MCR SYSGEN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE

and, for TCPIP support on TELNET and/or RLOGIN sessions:

$ DEFINE/SYSTEM/EXEC TCPIP$TELNET_VTA "TRUE"
$ DEFINE/SYSTEM/EXEC TCPIP$RLOGIN_VTA "TRUE"

You can control the time that a session will remain connectable before being kiled with SYSGEN parameter TTY_TIMEOUT (in seconds, default is 900 = 15 minutes)

[John Gillings]

Forgot to mention, changing TTY_DEFCHAR2 requries a reboot, (sorry). For ephemeral terminals like TNA devices, there is no other way to set the DISCONNECT characteristic.

FWIW, the reason you need all the TCPIP settings is because of the double edged sword of TCPIP. For "efficiency" Telnet sessions are not as "connection oriented" as (say) DECnet or LAT. This avoids the overheads of maintaining a strong connection between hosts, but suffers the consequence that a dropped connection will only be detected if an I/O is attempted from the surviving host (in which case it will see a failure). Eventually a keepalive message will detect the broken connection, but, by default, that can be hours.

Adjusting the keepalive parameters can reduce the time to detection. This also increases connection overheads, and defeats any arguments about how much more efficient telnet is than LAT or DECnet.

[Randy Hancock]

Now you have me wondering:

What is the meaning of these parameters (other than keepidle we have been discussing)? I don't see just tcp_keepalive.


tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 150
tcp_keepinit = 150
tcp_keepintvl = 150

[Ian Miller.]

See
http://h71000.www7.hp.com/doc/732final/6631/6631pro_005.html#keepalive

[Randy Hancock]

Whew!

Now it REALLY begins to make sense. If I am understanding this correctly, as our system is set up the keepidle setting triggers a keepalive probe after 75 seconds. If no response, it will try again in 75 seconds and repeat this process 8 times (totalling 10 minutes) before terminating the session. As it was set up before, this would have meant the termination would not have occurred for 2 hours, 8 minutes and 45 seconds.

Thanks!

[Jess Goodman]

I was just looking at the command file mentioned above, TCPIP$DEFINE_COMMANDS.COM, and saw something I thought was pretty funny.

In the VMS 7.2-2 version of it they use:
$sysconfig:==$sys$system:tcpip$sysconfig.exe

But in the 7.3-2 version someonc has changed that line (and all the others too) to be:
$ sysconfig :== $'f$edit(-
"sys$system:tcpip$sysconfig.exe","upcase")'

I would call that a very unnecessary use of a lexical function.

[Jan van den Ende]

@Jess:

it just reflects the fact that on ODS-5, with the process set to respect case-sensitivity, it still should work.
That is called Defensive Programming.

Proost.

Have one on me.

jpe

[Jess Goodman]

Well I thought about ODS5 but I still say that the F$EDIT is completely unnecessary.

The much simpler original symbol assignment:

$sysconfig:==$sys$system:tcpip$sysconfig.exe

will result in a uppercase string even when SET PROCESS/PARSE=EXTENDED in effect. := strings are alway upcased unless quoted.