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).
|