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