To avoid  seeing your  system run  out of  spoolids because  of a  few hundred
incoming INFO-VAX messages, as it recently happened to the central node of the
Netherlands  (HEARN),   the  next  version   of  LISTSERV  will  be   able  to
automatically  go offline  when the  system  or RSCS  spool exceed  predefined
thresholds  (see  full  description  below).  Since you  cannot  rely  on  the
operators bringing  it back online when  the spool situation has  improved, it
will also be  able to come back  online by itself when the  number of spoolids
goes below another predefined threshold. All of this is, of course, optional.
 
HOWEVER, THE MECHANISM WILL BE ACTIVATED  BY DEFAULT with the values indicated
below. If you wish to disable it,  or to change the threshold values, you will
have  to modify  your LOCAL  SYSVARS file,  as usual.  THE DEFAULT  VALUES ARE
PROBABLY NOT  SUITABLE FOR  LARGE HPO5  OR XA SYSTEMS,  for which  15000 spool
files might well be a 'normal' value. It is important for you to note that you
can insert the threshold definition in  your LOCAL SYSVARS file in advance, ie
NOW, to avoid  future problems when you install the  next version of LISTSERV,
at which time you might well have forgotten the very existence of this warning
:-) All  you have to do  is to insert the  paragraph below at the  end of your
LOCAL SYSVARS file and  modify the threshold values as you  see fit. You don't
even have  to reboot your  server as this variable  is ignored by  the present
version of the code.
 
  Eric
 
---> Description to be appended to LOCAL SYSVARS
*
* OFFLINETHR
*
* Defines the  system and RSCS  spool thresholds for  automatic offline/online
* control. This is an array of 4 numbers, which we will call 's1 s2 r1 r2' for
* easier reference. The  first two numbers apply to the  system spool, and the
* two last  to the RSCS spool  (ie the spool  files belonging to the  first or
* only userid you  have listed in the 'RSCS' system  variable). Whenever there
* are more  than 's1'  files in  the system spool,  as determined  by a  'Q F'
* command,  LISTSERV automatically  goes offline.  It will  automatically come
* back online when  the number of files  in the system spool  goes below 's2'.
* The same  holds true of  the RSCS  spool with respect  to the 'r1'  and 'r2'
* thresholds. If 's1'  or 'r1' is set  to '0', the corresponding  test will be
* bypassed  (and 's2'/'r2'  will  be  irrelevant, although  it  must still  be
* numeric). If  's2' and  'r2' are  set to  '0', LISTSERV  will not  come back
* online  automatically.   To  ensure  consistent  operation,   the  following
* relations must hold true ('x' meaning either 's' or 'r'):
*
* - x1 > x2  (obviously) and, to avoid LISTSERV going  offline and back online
*   every 30  seconds, x1-x2 should be  on the order  of 500 to 1000.  This is
*   assuming, of course, that x1 is nonzero.
*
* - r1 < s1 (unless s1=0), otherwise it will never get triggered.
*
* - r2 < s2 (unless s1=0 or r1=0), for a similar reason.
*
* - s2 > r1 (unless s1=0), otherwise LISTSERV might decide to come back online
*   because there are less than 's2' files in the system spool, and then to go
*   back offline because there are more than 'r1' files in the RSCS spool.
*
* That is, if both r1 and s1 are nonzero, you should have:
*
*                     s1 > s2 > r1 > r2
*
OFFLINETHR = '9000 8000 3000 2000'
 
---> Sample messages sent to the postmasters (the threshold values I used are
     not supposed to make any sense).