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