That was one of the things I disliked much about Ohio State, the stupidly formatted userids. Those userids were NOT account numbers, they were just all that the programs they had to install the userids could create. It was just a standardized pattern. If I created userids on my own, I could use whatever was appropriate. There is a move from higher up there to change to a more mnemonic system. Places like CMUCCVMA and PSUVM disgust me. Don't take offense Mark, I am directing this all to accounting types, who either want to number everyone's lives, or who don't realize ther *IS* an account field in each userid. In fact, we actually use the ACCOUNT field here at Illinois. Too bad there is not one in the SFBLOK, we have to use the DIST field which messes up a few things. Q: Having looked at CMUCCVMA's CPQ NAMES, I see many userid's that do not conform to the XX9X coding. They are clearly service virtual machines in most cases, e.g. SMTPUSER. Are the lists you are going to run at CMUCCVMA not to be classified as services in the same way as the others? Is this going to be a student run service? Might I suggest that if you can get some administrator to back you up, that you push for a NEW userid coding system based on "-L" at the end for the lists. This seems to have become a defacto standard, with only a few exceptions. Since these userids SHOULD be set up in a NOLOG sort of way (not actually NOLOG since IBM "fixed" it to prevent getting spool file), then it should be OK to have userids so named. They would not normally be logged on, so who should care. Be sure to point out that non-conforming userids (albeit for special purposes) do exist, so the argument that the account programs cannot handle the userids really does not hold any water. One final thing: I would like to start a list to discuss things like which schools have which policies, trading of policy ideas, etc. Many new schools come onto Bitnet without concrete policies, either relating to Bitnet, or to just their computer service. It could be a forum to share ideas regarding these things. It could also me a clearing house for people who are changing institutions to know what hassles they might be running into at the place they are going to switch to. ======================================================================== Date: Sat, 23 Aug 86 16:12:46 CDT Reply-to: Distribution list for the Revised LISTSERV code <LSTSRV-L@FRECP11> Sender: Distribution list for the Revised LISTSERV code <LSTSRV-L@FRECP11> X-To: IBM 370 Assembler discussion <ASM370@UCF1VM>, REXX Discussion <REXXLIST@UCF1VM> From: Phil Howard <PHIL@UIUCVMD> Subject: A super RECEIVE command To: Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011> Me thinks it be nice thing if someone write super RECEIVE program. It SHOULD: 1. Run faster than IBM's RECEIVE EXEC 2. Be written in REXX or Assembler (or both) 3. Handle batched file decks. 4. Support CARD DUMP format. 5. Support TSO library transmissions. 6. SUpport retaining carriage controls on PRT files. 7. Allow users to select RECFM for unformatted input. 8. Be nucxloadable if in assembler. 9. Allow user to totally suppress acknowledgements. 10. Use a form of "QUACK" for acknowledgements. If I am asking for too much, then consider number 5 to be optional. ======================================================================== Date: Sun, 24 Aug 1986 21:32 SET Reply-to: Distribution list for the Revised LISTSERV code <LSTSRV-L@FRECP11> Sender: Distribution list for the Revised LISTSERV code <LSTSRV-L@FRECP11> From: Eric Thomas <ERIC@FRECP11> Subject: Some domain problem To: Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011> Marc Shannon found a problem in LISTSERV's handling of 'command' mailfiles: when he sends mail to [log in to unmask] (== listserv@cmuccvma), LISTSERV replies with a mailfile saying "List te.cc.cm does not exist" (the message came from [log in to unmask]). The reason for this is that LISTSERV does not "know" that CMUCCVMA == vma.cc.cmu.edu, and the mail file is therefore not treated as a command. It is therefore supposed to be a normal mailing file, and the corres ponding (and truncated) list does not exist, of course. The listname is picked from the list, where it has been put by LSVPROF before transferring the file from the list userid. Now a reply of "List (distcode) does not exist" seems to be very unfriendly... Why don't I pick the listname from the "To:" header? Just because of those darned mailing from ARPAland which do not have the destination userid in the "To:" field, when they have a "To:" field at all... *sigh* You get a mess commensurate with the protocol you've chosen (RFC822) :-( Eric