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