> From: Carl E. Ruth II
> To: Multiple recipients of list HP3000-L; TomE
> Subject: Vesoft - Security 3000 not always workin
> Date: Monday, February 19, 1996 7:15PM
>
> My main concern is group three (3).  With group three (3) we have
> defined a large group of users who might still be logged on our system
> from 01:00 to 03:00am and if they show no activatiy for 5 minutes they
> are to be aborted.  Problem is sometimes LOGOFF will log them off
> other times is shows them ripe for aborting; but never logs them off.
>
> What am I doing wrong?
>
>  Why does Security sometimes show these sessions "RIPE FOR ABORTING"
> yet never log them off?
 
The LOGOFF file you show below doesn't contain a $WARNTIME/WARNMESSAGE which
will cause the effect you're talking about.  Strange-but-true, if you send a
message to a user logged on via a VT-session, THAT user's session
accumulates CPU time!  (do a SHOWPROC against a PC/lan user, send a :TELL
message to the user, then check the CPU time again)  As you can see, if
LOGOFF sends a message to the user *JUST* before aborting them, the CPU
useage of the user jumps slightly causing LOGOFF to reset the timeout
counter.
 
> Why does Security sometimes take these exact same sessions and abort
> them like it is supposed to.
 
As I said, since you aren't using WARNTIME/WARNMESSAGE [yet], this isn't the
problem.  (I'm just telling you about it now so when you do implement it,
you'll know why LOGOFF will suddenly appear to stop working again).  Mr.
Kapsak's response explains some of the other possibilities - basically, when
LOGOFF attempts to abort the user, it calls the COMMAND intrinsic to send a
regular :ABORTJOB command.  Once the command has been issued, it's up to the
operating system to actually carry out the command.  The primary thing to
check for is LOGOFF's $stdlist (in SLOGOFF.DATA.VESOFT) to see if actual
:ABORTJOB attempts were made.  If they were, and they are using VT sessions,
some of the "activity" of aborting the user (sending the abort message,
clear-and-remove-block mode, etc.) may cause the session to accumulate more
CPU time.  On Logoff's next cycle, the session is still in the list, but the
CPU time has changed so logoff "thinks" it needs to wait again.
 
If the session remains, but due to the user being switched away or other
factors that impede the :ABORTJOB command from completing, no CPU changes
take place.  Logoff compares how long the terminal is idle, and if it has
been "idle" for more than TWICE the timeout period, it stops attempting to
abort the user.  Reason: since each time LOGOFF attempts to abort the user
it sends the abort message and any terminal-clearing escape sequences, it
uses a TERMINAL BUFFER.  Eventually, many (or all) of the available buffers
are allocated to this terminal/process, causing an overall system slowdown
(as mentioned in another thread recently).  To avoid this situation, logic
was added to detect this situation and discontinue the attempts.
 
Switching away from "terminal" mode to some-other-application in windows
(i.e., "iconizing" the session) has been known to cause this problem.
 Similarly, I've demonstrated that using a regular HP terminal, hooked up to
a DTC port, it's possible to do the same thing using control-K to "switch
away" from the active DTC port.  Strangely enough, when you next connect to
the port, you (sometimes) have enough time to issue a %LISTF or similar
command before the :ABORTJOB, done hours before, actually takes effect...
 
>
> LOGOFF.DATA.VESOFT:
>
> $MESSAGE "YOU DID NOT FINISH LOGGING OFF LAST NIGHT!"
> $PAUSETIME 420
> $TIMEOUT 14400
>      $TERMINALS INCLUDE 49
>
> $TIMEOUT 19800
>      $USERS INCLUDE [log in to unmask]
>
> $TIMEOUT 300
>      $USERS INCLUDE TUBE.MANMAN
>      $SELECT "BETWEEN (CLOCK, 5PM, 3AM)"
 
BTW: this doesn't work!
The BETWEEN() functions parameters are such that P2 <= P3 must be true.
 "Time" is a tricky subject in that people implicitly know and understand
what happens at midnight, but computers are literal beasts, so, while 8PM
might easily be AFTER 5pm (satisfying the first condition), it is also AFTER
3am, not BEFORE, making the second condition "false".  Likewise, 2am is
before 3am, but also before 5pm, again, a non-true situation.
 
The solution is to use negative logic and turn the above BETWEEN call around
to:
 
     $SELECT "NOT BETWEEN (CLOCK, 3AM, 5PM)"
 
This way, 8pm falls OUTSIDE the range of 3am to 5pm, but the result is
turned around making this a TRUE statement.  Likewise 2AM is outside the
range, while 11am and 4pm are both INSIDE the range, so when turned around,
they are NOT aborted during the day.
 
Tom Emerson
Former VESOFT technical support manager