Sessions not terminating on terminal disconnect

[Randy Hancock]

We currently have two Alpha systems, ES40 and ES47. Many of our users login via Intermec 2425 hand held wireless terminals or hi-lo mounted 2455 wireless terminals. These connect through Intermec model 2100 access points. The problem we are noticing is that when a user loses connection from these terminals to the access point, the session on the Alpha does not recognize this, and stays active resulting in the user's inability to log in again until someone manually intervenes and terminates their process. It seems obvious to me that there is some setting somewhere either on the access point or within OpenVMS that is not properly set to recognize the loss of communication with the wireless device. Can anyone point me in the right direction to solve this problem? Thanks!

[Ian Miller. · Accepted solution]

what protocol are you using between the terminals and the VMS systems and what version of VMS are you using?

If telnet, have you looked at tcp keepidle settings?

[Randy Hancock]

OpenVMS V7.3-2. Do you mean TCP setting on Alpha?

[Ian Miller.]

yes, one cause of this I have seen is the keepidle timeout being large so it takes ages for the VMS system to know that the connection has gone.

[Randy Hancock]

makes sense, now as this is not something I do on a daily basis, do I find this within TCPIP? I.e., how do I get there and see what the setting is?

[Ian Miller.]

which tcpip product are you using and which version is it?

Do
sysconfig -q inet
and look for tcp_keep

(you may have had to define the sysconfig commmand. e.g @SYS$STARTUP:TCPIP$DEFINE_COMMANDS )

[Wim Van den Wyngaert]

do tcpip show servi telnet/fu
and check "socket opts" for the "Keepalive" word.

If not present : tcpip set servi telnet /sock=keepalive

Then do a type of tcpip$etc:sysconfigtab.dat
and check for tcp_keepcnt, tcp_keepidle and tcp_keepintvl. To abort the telnet after 5 minutes you could set them to 5, 120 and 120 (increase 5 to the number of minutes). Default is very high (2 hours ?).

Then restart tcp (will abort a lot, better reboot).

Wim

[Randy Hancock]

Hallelujah!

Just before you replied, I discovered the
sysconfig -q inet
command. I had differing reports that this did not used to happen before we purchased and installed our ES47, so I first looked at the configuration on the ES40:

tcp_keepidle=150

Then looked at our ES47

tcp_keepidle=14400

Well, I guess a user won't be too upset waiting 2 1/2 minutes to log back on. Chances are he won't even notice it. But 4 hours??! I guess it is set to the maximum.

Thanks for your quick response. Should have left a message on this forum sooner, this has been dogging us for months! I will be surprised if this does not address the problem...

[Randy Hancock]

Should have thought of this before last reply. Is this a dynamic setting, or will I need to wait until reboot for it to take effect?

[Wim Van den Wyngaert]

But the keepalive is only used if telnet has the socket option AND you use telnet (could also be rlogin or something dedicated).

Wim

[Wim Van den Wyngaert]

And the unit is 0.5 seconds (unix ...). So 2 hours it is.

Wim

[Wim Van den Wyngaert]

You can change in meory settings via
sysconfig -r inet att=val

but it is up to 6tcpip to decide if it will use the value (test it and after 5 minutes you will now). I'm sure it will not be used for open telnets.

Wim

[Ian Miller.]

I think you can change it on the fly (and put in the appropriate startup file) but you may have to change the options on the telnet service then disable/enable the telnet service to get it to be effective. disable/enable telnet will disconnect all telnet sessions (including the one you are using :-)

Parhaps setting tcp_keepalive_default = 1
which makes it default for all tcp sockets (I think) may make it effective sooner but affects all.

I think the default values changed in some recent version of UCX so the timeout is much longer.

[Randy Hancock]

I tried looking for a startup file that may have set this parameter, but could not find one...any thoughts on where I should be looking?

[Robert Gezelter]

Randy,

Note that there is a good chance that you can restart the TCP stack (or at least the Telnet portion of it) without a reboot.

For TCP/IP Services, you can stop and restart the IP stack with the system up, although you will need some connection other than a TCP/IP based connection to do it from.

Other stacks have different procedures. If not using TCP/IP Services, which stack are you using?

- Bob Gezelter, http://www.rlgsc.com

[Ian Miller.]

Last time I did this I put sysconfig commands in SYS$MANMAGER:TCPIP$SYSTARTUP.COM however
I think you can add them to sysconfigtab.

See
http://h71000.www7.hp.com/doc/732final/6631/6631pro_004.html#over_tune

for the full horror.

[Randy Hancock]

You are right. Scary stuff. Edited a file as follows (INET.TXT):


inet:
tcp_keepidle = 150


then within TCPIP:


TCPIP> sysconfigdb -a -f inet.txt inet


This appears to have added the parameter as


TCPIP> sysconfigdb -l


displays


net:

nfs:
tcp_threads = 8
udp_threads = 8
ovms_xqp_plus_enabled = 0

vfs:
vnode_age = 120

inet:
tcp_keepidle = 150


So, it appears I should be set for our next reboot?

[Robert Gezelter]

Randy,

As I noted previously, no reboot is needed. You just need to shutdown TCPIP services and then re-execute @SYS$STARTUP:TCPIP$STARTUP.COM

You do need to to this, of course, from either:
- a local terminal
- a terminal session using LAT
- a DECnet remote terminal session
- a SYSMAN SET ENVIRONMENT session
- (I haven't tried this recently) a batch job.

You will need to terminate all TCP/IP use for a minute or so, but that is far less time than a reboot.

- Bob Gezelter, http://www.rlgsc.com

[Randy Hancock]

I'm sorry, I didn't make it clear, I DID understand that we could do this without rebooting, it is just that we run a nearly 24 hour shop so it is tough to get users out of the system. At least this way I KNOW we should be ready at the next reboot, scheduled or not!

Thanks again!

[Robert Gezelter]

Randy,

Understood, but if at all possible I would recommend not altering a setting and waiting for the next reboot to happen.

You mentioned that you have two systems, an ES40 and an ES47. Can you make the change on one of the systems, shift the load to the other system in the cluster over a period of time, and then do a restart of IP on the (now) relatively idle system?

Then you can verify that the setting is indeed the problem, and make the change for both members of the cluster.

I apologise in advance if I am writing this on the presumption that other people, who may be less knowledgeable will read this thread.

- Bob Gezelter, http://www.rlgsc.com

[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