Telnet session termination problem

[Learn_1]

Hi,
i am administrating compaq alpha server gs80 running openvms7.3.i am having a problem regarding telnet session.user connect to this server using smarter340 terminal software using telnet service.if due to any electrical fluctuation at client end user session disconnects,the session remain active at the server end.so when user try to re-connect he/she is denied access as the session remain active at the server end.so we have to manually kill this user process so that he may login again.
can anyone help in this regard

[Gorazd Kikelj]

Do you have by any chance enabled virtual terminals?

[Stephen Hoffman]

Please provide some information on the IP stack and ECO level, though I will answer with an assumption that this system is running TCP/IP Services V5.3 with the current ECO. (If you are not running the current ECO for TCP/IP Services and the mandatory ECOs for OpenVMS, please load them now.) I will also assume that this is a direct telnet connection into the OpenVMS host, with no intervening servers.

As the previous response has indicated, if you have virtual terminals enabled (and see the OpenVMS Ask The Wizard area for some pointers on how to enable virtual terminals for telnet sessions), you should receive a prompt during login offering to reconnect to the session.

It is also possible that an application is botching a hangup (SS$_HANGUP) signal in its signal handler, as this can effectively cause a session to fail to correctly disconnect.

The terminal emulator is an unknown factor here, as that can potentially cause all manner of odd problems if its IP stack should become confused.

That the session is denied implies that there is some local settings or software that prevent the login, as most OpenVMS configurations allow multiple parallel logins by default. (It is possible to configure OpenVMS and the logins to deny this, and this appears to be the case here. Some details of this denial (and the exact error messages) might be interesting, too.

[Learn_1]

Thanks for replying.i had to enable the keepalive setting which is by default disabled.similarly i modified the following parameters,
$@sys$manager:tcpip$define_commands
$ sysconfig -q inet
$sysconfig -r inet tcp_keepalive_default=1
$sysconfig -r inet tcp_init=20
$sysconfig -r inet tcp_idle=60
$sysconfig -r inet tcp_cnt=4
$sysconfig -r inet tcp_keepintvl=30

i also added these parameters in the
sys$startup:tcpip$systartup.com by creating this file so that these should be configured automatically at the startup.
if we apply the above stated parameters on running system then we will have to retart the telnet service so that these values may take effect.
after applying these value the prblem has been resolved.

[Henk Ouwersloot]

Hi,

I want to make a remark on your last update. TCPIP$SYSTARTUP.COM is executed at the end
of TCPIP$STARTUP.COM. And that is after all services are started. Commands entered in
TCPIP$SYSTARTUP.COM effect only Dynamic parameters! In your current setup, the SYSCONFIG
commands to change the inet parameters will have no effect on your TELNET service
because TCPIP$INETACP and the TELNET service are allready started.

To set these Inet parameters during a startup you have the following options:

1) Setting the values in TCPIP$SYSTARTUP.COM and restart the TELNET service:
For example:

$ sysconfig -r inet tcp_keepalive_default=1
$ sysconfig -r inet tcp_init=20
$ sysconfig -r inet tcp_idle=60
$ sysconfig -r inet tcp_cnt=4
$ sysconfig -r inet tcp_keepintvl=30
$ @SYS$MANAGER:TCPIP$TELNET_SHUTDOWN.COM
$ @SYS$MANAGER:TCPIP$TELNET_STARTUP.COM


2) Adding the required Inet parameters in the SYSCONFIGTAB.DAT (V5.3 only):

This data file is read at the beginning of TCPIP startup, before InetACP and any
services are started. Adding parameters to this data file requires a specific
procedure and Utility, the SYSCONFIGDB utility.

Further information on modifying the SYSCONFIGTAB.DAT and the SYSCONFIGDB
utility can be found in the TCPIP V5.3 Release notes paragraph 1.6.

[Learn_1]

Thanks Henk.
After modifying the parameters that i stated in my last message did solve the problem for quite a few days but now the problem has started again and i have checked the modified parameters.they all are in the required value.i have also restarted the telnet service,have applied the latest eco kit for tcpip v5.3 but the problem remain same.can anybody suggest any further checking.

[Henk Ouwersloot]

Hi,

Be sure that the values are also active! The sysconfig -q commando does indeed say what the current value is for the parameter, but if the service is started before the values op the parameters are changed, the service operates with the default values.

[Richard W Hunt]

You did not make clear whether it was your desire to allow a reconnect or simply kill the dangling job.

If all you want to do is clean things up, you can look up several job-killer products on the web. RAXCO makes one. There are products called Hit-Man and Robomon. I'm sure there are others. Heck, when budgets were tight, I even wrote a DCL script that could do the job for me. It required several F$GETJPI calls and it wasn't the cleanest script in the world, but job trimming is not that hard a process. Still, a commercially available product might be enough for your needs if you don't want to build your own job trimmer.

The discussion regarding enabling virtual terminals is the solution if you want the user to be able to reconnect and NOT lose the session. At our site, policy dictates that the session must be considered lost because virtual terminals have certain security implications our staff didn't like. Of course, since they pay my salary, they have this strange notion that they have the right to dictate policy now and then. I humor them as long as they keep on paying me.

[Martin P.J. Zinser]

If you are looking for a free idle killer have a look at

http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=watcher&description=&author=&system=Either&language=All