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