ARGUS3

        ARGUS3 is a brand-new rewrite of a  submission  to  an  old  SIG
        tape.   I  wish  I  could remember which tape it came from, so I
        could give  proper  credit.   In  any  event,  two  things  have
        happened which obsolete it.

        1.  The old one depended on the PID  being  two  words,  one  of
            which was a slot identifier, and the other a sequence number
            (like   file   IDs).    The   program   preallocated   slots
            corresponding  to the slot identifier, and used the sequence
            number to tell when a new user appeared.

            It appears that the PID  structure  is  changing;   since  I
            couldn't get any good information about what it was changing
            to, I played it safe and used a complete PID search.  It may
            not  be  elegant,  but it will work unless they do something
            REALLY bizarre.

        2.  The old ARGUS, having been coded in the old  VMS  2.0  days,
            did  not  consider subprocesses.  You could use subprocesses
            in those days, but it didn't become easy until SPAWN (or one
            of  the  UNIX lookalikes).  The algorithm I have used simply
            does not consider processes (or subprocesses) which  have  a
            non-zero  process  count.  The end nodes of the process tree
            can  be  pruned,  however,  so  a  completely  idle  process
            structure  will  eventually be removed, piece by piece, from
            the bottom up.

        The parameters which controll how it works are all settable  (in
        the CONST section of the source).  Here's how it works:

        ARGUS3 scans the open processes  once  every  INTERVAL  minutes,
        where  INTERVAL  is an integer that divides evenly into 60.  (1,
        2, 3, 4, 5, 6, 10, 12, 15, 30).  It will consider a process idle
        which does not perform at least CPU_THRESHOLD TIC's (a TIC is 10
        milliseconds) or IO_THRESHOLD buffered  IO's,  and  it  keeps  a
        count of the number of consecutive times a process is considered
        idle.

        When  the  number  of  consecutive  idle  counts   has   reached
        N_TO_WARN,  it begins warning the owner of the process.  When it
        reaches N_TO_KILL, it removes the process from the system.

        ARGUS will ignore the presence of an image in a  process;   thus
        an idle process is killed even if it is executing something.

        A process tree (main process, some number of  sub-processes)  is
        handled  by  refusing  to kill a process which has subprocesses.
        The subprocesses,  if  they  are  idle,  will  be  killed,  thus
        reducing  the  process  count;   hence an idle process tree will
        eventually be killed by this pruning mechanism.
                                                                  Page 2


        As delivered, ARGUS3 is set to the folowing values:

                INTERVAL = 5
                CPU_THRESHOLD = 30
                IO_THRESHOLD =  1
                N_TO_WARN =  4
                N_TO_KILL =  6

        The effect will be:  ARGUS runs  every  five  minutes.   If  the
        terminal  is  idle,  it will be warned at 20 and 25 minutes, and
        killed at  30.   The  threshold  values  are  necessary  because
        examining  a  process  causes a small amount (a few TIC's) to be
        charged against the target process.  So I have to ignore the CPU
        time I am causing.

        Warnings and deletions are broadcast to the user's terminal.

        ARGUS3 produces a log file in  SYS$MANAGER.   (See  the  startup
        command  procedure  to  modify  that.)  Normally,  it receives a
        one-line message for each warning and each process deletion.  If
        you  set  the  system-  wide logical name ARGUSDEBUG to TRUE you
        will get a more verbose  log  file.   If  you  have  particulary
        hostile users, you might need it to justify your brutality.

        ARGUS3 is started up as a detached process  (see  RUNARGUS.COM),
        and  the log file is a directed SYS$OUTPUT.  That means you have
        to kill ARGUS3 and restart it in order to get at it.  That's not
        very  elegant,  but ARGUS3 is new and hasn't had time to acquire
        bells and whistles.

                                FUTURES
        There are a couple of good things I want to put into this  thing
        that I simply haven't had time to do yet.

        1.  It will be possible to modify the operational parameters  by
            setting  system-wide  logical  names.  Then people who don't
            have PASCAL will not be stuck with the default settings.

        2.  The reason for going to all the trouble of synchronizing the
            times  (with  INTERVAL  at  5, it wakes up at exectly on the
            hour,  five  past  the  hour,  etc)  it  that  I  intend  to
            incorporate  a  performance  monitoring  function,  and it's
            always nice when data is gathered on even time boundaries.

            The performance file will only  be  opened  when  ARGUS3  is
            adding to it, and immediately closed.  So it can be examined
            at any time, and if the system crashes, it will not only  be
            intact,  but  will  provide  a  good  record  of  uptime and
            downtime.


        One final thing:  in the heat of getting this together  for  the
        symposium,  I  cannot  find the source for QUADMATH.  If you are
        nervous about using non-sourced code in a privileged image  (and
        I  don't blame you) it would not take much to rewrite it...  the
        functions  are  obvious...just  quad-word  add,  subtract,   and
        multiply.