We had distribution problems (the 5-cards which have been moved 5 cards away
again) with UPD15G SHIPMENT. The file was received and processed correctly by
all servers, except that:
1. The WSUVM1 server had had DISTRIBUTE disabled because it was not in its own
tables. This problem can not occur any more with 1.5g but some nodes may
not have received the files. I'll check that with Vic and have the files
resent properly
2. The files reached NCSUVM without problem, and were distributed from there
to SUVM (thence CANADA01, etc) without any problem. However, the copy recei-
ved by CMUCCVMA was botched up and consequently all the following nodes
received a bad copy:
CMUCCVMA, OUACCVMA, AKRONVM, UIUCVMD, UIUCVME, WUVMD, IRISHVM, UTCVM, UGA,
RICE, TCSVM, TAMVM1, TAMCBA and UTARLVM1.
If your node is among this list, please discard the shipment file you
received from me and obtain a new one from Harold.
Now the question is: why the heck was the file botched? Funny, CMUCCVMA is
the first node in the distribution path that's on the other side of OHSTVMA
(the dreaded RSCS V2 that doesn't quite work perfectly yet). Another possi-
bility is that the CMUCCVMA server has had an installation problem but I
doubt it. I'll check with Marc and we'll re-install his server if we find
something wrong.
3. One of you has complained about getting TWICE the same file on his LISTSERV
disk after the CARD LOAD. This is due to the incompatibility between the
VM/SP3 CARD MODULE and the VM/SP4 one and it causes the disk to be
DESTROYED (that is you'd better re-format it). I've checked it again, the
version of CARD that is shipped with LISTSERV is Rel 4. So please check
that YOUR version of CARD module is either the one I sent with LISTSERV
(release 1.4 or better -- I can't swear that the file shipped with release
1.3 of LISTSERV was the good version), or, if you have discarded it because
it's on a public disk at your installation, please check that the version
on this public disk is the release 4 one. Its lrecl should be 8184 and the
string "RENAME" should appear in the object code, otherwise you have the
SP3 version. VM/SP3 systems are not affected of course.
4. As I had said I was shipping my TEST 1.5g version because of the problems
it solved with MAIL, et al. There are also new features but I have NOT said
that they were finished or that they should be used. Some of you have found
problems with the new commands and sometimes managed to crash their server,
which is not surprising since some of the stuff is NOT FINISHED. However
they do have a point when they say that a general user should not be able
to bring the server down just because I'm adding a new command and it's not
yet operational. I'll therefore try to finish what I had started today and
will distribute a 1.5h update shipment to fix those problems. Sorry for the
extra load, but I really didn't expect people to sneak into the code to
locate the new command entries in LSVCMD and LSVRDR, etc :-)
A last word about support of mixed case userids. This has been a long story
and I'm going to put it to an end. I have explained several times why I did
not want to allow mixed case userids, what my opinion of those systems that
can't convert all caps to all lowercase is, and how much of a pain it would be
for me (and all french users) to have mixed case userids when the "@" sign
displays as "a" on our terminals (so what's anastasiaacadia? ANASTASI@ACADIA?
ANASTASIA@CADIA? etc). I will amend LSVADD and LSVSORT so as not to upcase
domain-type userids, while NJE-type userids will still get upcased. Domain-
type userids are a mess anyway so the "a" -> "@" problem is acceptable and if
it can solve MAILER problems, tant mieux. I will not make a single other change
to the code to support lower case userids for NJE-type addresses like
[log in to unmask] I wish RFC822 had imposed uppercase userids and node names.
Eric
|
