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