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
|
