Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 Apply fix 17A-001o (HIPER), dated 91-07-10 I know, I know, fixes are a waste of your time and I only make them so I can have an excuse to fill your mailbox with junk mail. Here the problem is that RICEVM2 was deleted in VERS9109. The Rice folks had informed me in advance of the removal of the LISTSERV on that machine, so I updated PEERS NAMES and distributed it. Apparently, the update did not reach everyone, which is no surprise since the DISTRIBUTE backbone is totally screwed up. We have sites with a broken REXX interpreter (the only part of CMS that was bug-free, and IBM had to break it), and won't apply the fix because it would force them to apply 2,000 unrelated fixes (courtesy of SES and OCO), so we simply have to accept the fact that, from time to time, the REXX interpreter crashes and files are lost. I can't even blame the poor chaps, I've been there myself, and I can't expect every site to have BITNET as a high-priority item. Then we have sites that didn't bother to increase the size of LISTSERV 191 to allow 1.7a to load, but who did bother to fetch the new format BITEARN NODES file and install it. Well I'm afraid the main reason I wasted so much time making an 1.7a is that 1.6e doesn't support the new format, so DISTRIBUTE takes another hit. Then you have the bug in CMS 5.5 that causes LISTSERV to run out of storage, because the only way to sort things with acceptable performance under (vanilla) CMS is to use the system editor, and a bug in some terminal I/O routine caused it to forget to deallocate storage every time it is called. Users are not affected in practice, but things like LISTSERV which call it hundreds of times a day end up with no storage. Then, of course, after 3-4 years of planning, EARN and the NIC made very sure not to announce the migration to the new format until after it had taken place, and then only because I asked Ulrich and Jim Conklin to do so (actually, I doubt Jim has seen my note yet). So people happily obtained VERS9109 from NETSERV and proceeded to run UPDNODES, possibly via an automated procedure. End result: some 12,000 lines of error messages, an error return code, but since none of the errors is fatal you do get an output file (totally unusable, of course). Well the procedure prints an error message and exits, leaving an updated BITEARN NODES on the public disk. LISTSERV sees BITEARN NODES has been changed, rebuilds its tables from this corrupted version, and there goes another DISTRIBUTE site. I guess some people thought it intuitively obvious that one has to FTP a new copy of the base file from BITNIC (or another place) before one can run VERS9109. I also guess it would have been too hard to make a new version of UPDNODES that checks for the new format and require that version in VERS9109, to ensure nothing wrong happens to the file. Or to make sure that the XMAILER NAMES file would be generated properly - in advance. But then, with only 3-4 years of advance planning, you can't possibly expect a smooth transition. Eric