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