The global list registration code is available for beta-testing (I will distribute the beta-test shipments on monday evening my time - then I'll be off until friday). Here is a description of the way it operates: ---------------------- End-user's viewpoint ---------------------------------- 1. A "request" for something (presently, only SUBSCRIBE and REVIEW) is sent to just any LISTSERV that has the feature installed. If the list exists on that server, either as a 'real' listname or as a List-ID, the request is satisfied. 2. If the server the command was sent to is not on the backbone, it will immediately forward the request to the nearest backbone server with a message sent to the user. Go execute step 3 on the attached processor. 3. If the server is on the backbone, it will search its GLOBLIST FILE for a match. It may reply that "No such list is known to exist on the LISTSERV network", game over insert coin. It may also inform you that there are several lists bearing the same name (note that peers count as a single list and are represented by their nearest member), give you a list of them, and ask you to choose for yourself. It will, hopefully, find a single match and forward the request to the appropriate server. ---------------------- LISTSERV's viewpoint ---------------------------------- 1. Every so often (by default, every night), LSVLDELT is called to compare the current status of the LIST files with last time's. If a difference is found, a delta file is built and a distribution job (X-LUPD command) is submitted to the nearest backbone server, possibly the server itself. This process is responsible for the creation of LOCLIST FILE, which defines the List-IDs for all the local lists (and ONLY the local lists). The main advantage of this 'asynchronous' approach is that there is no problem with lists that have been modified by hand, using XEDIT from the LISTSERV userid (what, you mean you've never done that?? :-) ) 2. The backbone server receiving the X-LUPD job will apply the update to its own GLOBLIST FILE, and cause a copy to be forwarded to all the other backbone servers by means of a DIST2 job. There is a mechanism to ensure that older updates are not applied over recent ones, even if they are received in the wrong order. Note that the use of DIST2 vs DIST1 reduces CPU consumption in a factor of 10 on the second and following runs. 3. Some commands request that the LOCLIST FILE be checked for a synonym. Some don't. In the long run, they will all support synonyms. 4. Some commands will cause the request to be forwarded to the appropriate server if it couldn't be satisfied locally. Some don't, and never will (eg GET - you don't want to GET a network-wide name, you want to GET a particular peer from a particular server). The new X-FOR command is used in that case, and the new "FWDED=" command keyword is used to prevent accidental loops. In any case, the new code does not "know" whether a particular backbone site has it installed or not, and sends to all backbone servers. You will probably get copies of X-LUPD and maybe X-FOR jobs if you run a backbone server. Just ignore them unless they create problems (they shouldn't!) Eric