topic Re: Sessions not terminating on terminal disconnect in Operating System - OpenVMS

Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 09:21:31 GMT

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!

Re: Sessions not terminating on terminal disconnect

Ian Miller. — Wed, 02 Aug 2006 09:37:38 GMT

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?

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 09:47:06 GMT

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

Re: Sessions not terminating on terminal disconnect

Ian Miller. — Wed, 02 Aug 2006 09:52:02 GMT

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.

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 09:55:04 GMT

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?

Re: Sessions not terminating on terminal disconnect

Ian Miller. — Wed, 02 Aug 2006 10:11:15 GMT

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 )

Re: Sessions not terminating on terminal disconnect

Wim Van den Wyngaert — Wed, 02 Aug 2006 10:13:34 GMT

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

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 10:17:06 GMT

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...

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 10:21:31 GMT

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?

Re: Sessions not terminating on terminal disconnect

Wim Van den Wyngaert — Wed, 02 Aug 2006 10:35:00 GMT

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

Wim

Re: Sessions not terminating on terminal disconnect

Wim Van den Wyngaert — Wed, 02 Aug 2006 10:35:47 GMT

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

Wim

Re: Sessions not terminating on terminal disconnect

Wim Van den Wyngaert — Wed, 02 Aug 2006 10:46:51 GMT

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

Re: Sessions not terminating on terminal disconnect

Ian Miller. — Wed, 02 Aug 2006 11:08:35 GMT

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.

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 12:02:39 GMT

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?

Re: Sessions not terminating on terminal disconnect

Robert Gezelter — Wed, 02 Aug 2006 13:05:48 GMT

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

Re: Sessions not terminating on terminal disconnect

Ian Miller. — Wed, 02 Aug 2006 13:09:29 GMT

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.

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 13:49:24 GMT

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?

Re: Sessions not terminating on terminal disconnect

Robert Gezelter — Wed, 02 Aug 2006 13:57:01 GMT

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

Re: Sessions not terminating on terminal disconnect

Randy Hancock — Wed, 02 Aug 2006 14:04:48 GMT

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!

Re: Sessions not terminating on terminal disconnect

Robert Gezelter — Wed, 02 Aug 2006 14:12:22 GMT

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