EROS DATA CENTER

************************************BOUNCER************************************
	BOUNCER is yet another idle terminal killer.  The differences between
 BOUNCER and other idle terminal killers are that the killing is optional and
 the entire process tree is examined as one unit.

	On our system, we allow users to be idle unless we run out of lines
 (we have a port selector).  The default mode only monitors and reports idle
 users to the operator, and the operator manually kills them when necessary.
 The exception to this rule is that privileged users are always killed, without
 warning, after exceeding the idle time limit.  The console (OPA0:) and the
 user defined in exempt_user (OPS on our system) are never timed out.

	BOUNCER has a variable idle time limit (in minute increments), and any
 user exceeding that limit is logged in [SYSMGR]BOUNCER.LOG and optionally
 killed.  BOUNCER also writes a file once a minute which is called 
 [SYSMGR]DEADBEATS.LOG and contains an entry for each user which has been idle
 for more than a minute.  The operator or system manager can type this file
 to see who has been idle how long (we have defined a symbol which types it).

	A process is idle if hasn't used any BIO (buffered I/O's), DIO (direct
 I/O's) and has used less than 10 milleseconds of cpu time.  Because issuing
 GETJPI calls causes a kernel mode AST to run in the context of the target
 process, CPU time is occasionally incremented in the target process even
 though it is truly idle.  Since GETJPI reports CPU time in 10 millesecond
 increments and the GETJPI call seems to increment their CPU time by less
 than a millesecond, we only occasionally see the change in CPU time.  By
 allowing a process to use 10 milleseconds of CPU time and still be considered
 idle, we can eliminate the possibility of mis-reporting a process as being
 active.  Some will argue that an active process could use 10 milleseconds
 (or less) of CPU in one minute and still be doing usefull work... but I won't
 beleive it unless I see it.  If you disagree, you may change IDLE_CPU to 0,
 which will treat any increment in CPU time as "active" CPU time.

	BOUNCER properly handles sub-processes and will not consider a process
 idle if any subprocess is active.  All subprocess BIO's, DIO's and CPU times
 are added to those of the root process. 

	To use bouncer, do the following;

		BOUNCER :== $SYS$MANAGER:BOUNCER
		DEAD    :== TYPE SYS$MANAGER:DEADBEATS.LOG
		BOUNCE 20	!Monitor users, write in log if idle 20 min
		   or
		BOUNCE -20	!Monitor and bounce idle users after 20 min

	At our sight, we run BOUNCER detached.  We have set up a command
 procedure which is invoked in systartup.  Two command procedures are actually
 used, BOUNCE.COM which creates a detached process which invokes BOUNCE.CMD
 (these command procedures are included here).  I have assumed that BOUNCER
 will reside in SYS$MANAGER.  If not, you must change the command procedures
 and the above examples.

	The DEAD symbol will allow you to get an up to the minute report on
 who is idle.  All users wishing access to this info can define DEAD in their
 LOGIN.COM.  DEAD is short for DEADBEATS!


	NOTE: Use of this program requires WORLD, OPER and write access to 
SYS$MANAGER.

	NOTE: BOUNCER has not been tested under VMS V4.0 but should run
properly if recompiled and relinked.

	Compile and link thusly;
		@BUILD

*******************************************************************************

	EROS stands for Earth Resources Observation Systems and is not related
in any way with the skin mag of the same name.  We are a government agency
which primarily stores, enhances and sells LANDSAT and other imagery.

	Written and submitted by:


		Thomas Bodoh
		U.S.G.S. / EROS data center
		Mundt Federal Building
		Sioux Falls, SD  57198
		(605) 594-2271