> From: Randy Smith
> Subject: Vesoft - Security 3000 not always workin
> Date: Thursday, February 22, 1996 11:52AM
>
> > Problem is sometimes LOGOFF will log them off other times is shows them
> >ripe for aborting; but never logs them off.
>
> Same problem.
>
> We've had the problem ever since we went to 5.0 & 25, which has been
several
> months now.  It used to work fine before we upgraded.
>
>  [snip]
>
> Anyone out there have a solution.  Perhaps someone from VESOFT?
 
Although I'm no longer with VESOFT, I'll give you a bit of history and the
"current" solution.
 
Initially, LOGOFF was designed for logging off sessions that had been "idle"
for too long.  Somebody (customer? VESOFT employee? don't know -- it was
before my time there) realized that if the timeout period was short enough,
(say, 20 seconds), it would be virtually impossible for anyone to remain
"logged on" while you tried to start things like system backups.  Word got
around, and for a while even VESOFT promoted this "use" of the product.
 
The downside of this practice, however, is the fact that LOGOFF will wake up
as often as the SHORTEST interval to perform checks of "idleness".  Although
there is a "$SELECT" keyword that is often coupled with a "BETWEEN (clock,
11pm,11:15pm)" (or whatever time you start your backup), LOGOFF still has to
"wake up" at the shortest interval JUST to see if the $SELECT is valid
(remember, the $SELECT doesn't have to be time-based, it could, for
instance, check on the existance of a file).  The net result is that this
becomes very resource-intensive for "short" timeouts, so this practice
should be avoided.
 
To help alleviate the aformentioned problem, one of the VESOFT technicians
created a command file/script that essentially parsed the output of the
SHOWJOB command into a set of "ABORTJOB #S123" commands.  The resulting
commands would then be executed as a command file and thus log everyone off.
 [note: the actual origin of this command file is somewhat fuzzy -- there
may have been two or three other "sources" of similar command files,
including one from HP's tech support, but all of these command files had the
same eventual effect]
 
Around the time of release 2.4, the concept of USERsets, similar to
FILEsets, became the focus of many new and existing commands.  This may have
been late in the 2.4 release, and is certainly in the 2.5 release (also
known as 25.nnnnn).  One of the commands that was "enhanced" was the MPE
ABORTJOB command.  By adding the full capability of "usersets" to this
command, very specific "kill every session that matches this criteria"
commands could be issued.  The simplest is "%ABORTJOB ONLINE", but this has
the (in some cases) unfortunate side effect of logging you (the person
issuing the command) off before the command actually completes...
 
Needless to say, this is a far more efficient mechanism for aborting all
users prior to a backup than running LOGOFF with a short timeout interval,
although there is still one case where LOGOFF may make a better choice than
ABORTJOB.  Users that are in "block mode" programs (VIEW oriented) benefit
more from being aborted by LOGOFF than by ABORTJOB.  The reason for this is
because LOGOFF sends a set of escape sequences to the terminal to take the
user out of block mode prior to being aborted.  This reduces the confusion
from user's trying to log on the next day with their terminal in a "wierd"
state.
 
==================================================================
 
In an earlier note in this thread I explained some of the reasons this
"strange behaviour" of LOGOFF is occuring (where sometimes LOGOFF works, but
not always)  Basically, once LOGOFF passes an ABORTJOB command to the
system, it's the system's responsibility to actually abort the user.  This
may seem like finger-pointing, but  I've seen cases where users have
"switched away" from their current R1 application (perhaps making it an
icon) as well as users who "switch away" from a DTC session and do not get
aborted properly when an ABORTJOB command is issued from the console.
 
Hope this has shed some light on the subject
Tom Emerson