I have just finished testing an automated nodes table generation package
running on LISTSERV. This should be considered as an official announcement,
although I won't release the package until next month: it has generated this
month's tables properly but I want to make sure that everything goes smoothly
when the NODUPD file is received from NETSERV and I'm not here to look at the
LISTSERV console (the psychological effect of having one's programmer looking
at you while you attempt to bug out has always been known to prevent programs
from malfunctioning). People who would like to beta-test the code should
contact me directly.
The problem is the following: the nodes table generation process is
"complicated" for people who don't know much about the network. It is at best
tedious for people who do know, and there are so many things to do that you're
bound to forget something every other month.
Once the package is installed and tailored, you must AFD your LISTSERV to *
NODUPD from the nearest NETSERV (or even from a nearby LISTSERV which provides
the file), with a prologtext of 'PUT &fn NODUPD whatever PW=whatever'. If this
is not possible and you receive the NODUPD files through another process, you
can always issue a PUTALL command from the postmaster's account, which is how
I tested the package.
Anyway when LISTSERV receives the file, a File Access Validation Exit is
invoked. It will first run UPDNODES to update BITEARN NODES (R/W access to the
master copy of the file is required), renaming the old version to NODEyymm.
GENROUTS is then invoked to generate XMAILER NAMES and routing statements for
the local node, which are stored in a file called NODES TABLE (which users
find much more handy to search than BITEARN NODES - well, assuming they do
have enough virtual storage to run NODES :-( ). Then LISTSERV optionally
obtains a R/W link to RSCS 191 (through a user exit) and creates a new RSCS
DIRECT from a RSCS TEMPLATE file, which contains everything except the routing
statements (note: I will assume RSCS V1 in the following discussion, but it
would work with RSCS V2 as well, in which case the name would be RSCS CONFIG).
This file can either be written as RSCS DIRECT with the old version renamed as
DIRyymm, or it can be filed as RSCS NEWDIRECT or whatever the user exit
chooses, with the old RSCS DIRECT being retained. LISTSERV will then call the
user exit to perform any additional local work that might be required, and
will eventually reboot itself, rebuilding its private nodes table as it
restarts. The postmaster gets informed of course.
In my case, all I have to do (well all my colleague has to do - I would
certainly prefer to do almost everything by hand, but what happens when I
leave FRECP11?) is to reboot RSCS and MAILER (it will rebuild its tables
automatically when it sees a new XMAILER/MAILER/DOMAIN NAMES file), clean up
the "network disk" when too many BITEARN NODEyymm have accumulated on it,
clean up RSCS 191, etc.
Release 1.5m of LISTSERV is required to run this package, because of a
10-lines mod to LSVFILID to allow generic entries in the FILEID files. This
can be circumvented by temporarily using a special filelist with just the
NODUPD entry in it and an '*DEFAULT*' statement in the corresponding FILEID
file, or by creating specific (ie non-generic) entries for the NODUPD files
"in advance". 4M of storage are recommended in order to be able to run
GENROUTS (sigh), although I did manage to run it with 3M this month (there is
an 'EXECDROP *' statement in the exec just before the GENROUTS call).
Eric
|