Sessions not terminating on terminal disconnect

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

[Jess Goodman]

But you missed what is really funny. If you want to explicity use an upper case constant string in the symbol defintiion, isn't it a lot easier to just enter the string in UPPER CASE? Instead of using lower case and then a lexical function to upper case it for you.

So even if the original command has to be changed for case reasons (and it did not), why not change it to:

$sysconfig:==$SYS$SYSTEM:TCPIP$SYSCONFIG.EXE

It's almost like the person who made the change refuses to even touch the shift key on his keyboard. Obviously from a Unix background :).

[Barry Alford]

@jess

I smell the use of a tool...

...but if I had written the suspected command procedure, I too would have simply uppercased the line...

[EdgarZamora_1]

Jan,

In your first reply to this thread you mentioned...

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

I am having this rare problem (which I haven't been able to reproduce) wherein a disconnected telnet session will go into COM state and hog all the CPU. The session does not time out and remains logged in until manually killed. How did you fix this problem? TIA!

Config:
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 4
on a AlphaServer 4100 5/533 4MB running OpenVMS V7.3-2