Some notes about using the FAST-APPEND R-OPTION:

When this option is specified, output to the mail file is done
in "write-over mode", so that COMSAT does not have to re-write
the entire file each time it adds a new message.  This is very much
faster, but the creaky ITS file system imposes some cautions on
its use, which are listed below.

The problem is basically that if for any reason the append of
a message is interrupted or aborted, the incomplete junk will
remain at the end.  Furthermore, if the abort happened due
to a system crash, the salvager will rename the file by AOS'ing
the FN2.  These hassles necessitate the following rules:

Rule 1:	FN2 MUST NOT BE 6 CHARS LONG.
	The FN2 of the mail file should be 5 chars or less in length,
	as should any other file with the same FN1.  This enables
	AOS'd FN2's (such as produced by system crashes) to be
	uniquely distinguished.  If no file exists for the right
	filename, COMSAT will look for an AOS'd version, and rename
	it to the right thing if one exists.
	This is what you should do too if you are looking for the file
	and it seems to have disappeared; try using "!" in the 6th char
	position of the FN2 to get the AOS'd version.

Rule 2: DON'T TOUCH THE FILE!
	Actually this rule should be followed for ALL mail files.
	It is OK to read a mail file, but you should never try
	to write out a new one (e.g. by editing with EMACS), because
	any new mail added to the file between your read and write
	will be lost.  The best way to hack them is like RMAIL does:
	rename the file to something else, which can then be
	munged as you please.
	This also applies for AOS'd versions of the file; be careful to
	simply rename it to the right thing (if you tire of waiting
	for the next message to spur COMSAT into doing it for you)
	instead of creating it again; you should never have both
	the file and its AOS'd version simultaneously!

COMSAT actually goes to some effort to make sure that there is no
garbage at the end of a FAST-APPEND file; it will back up over the
last characters until it sees a ^_ (message separator).  If there is
any junk at the end, wait for the next message to arrive; it should
clean things up.  Incidentally, this is yet another reason not to
touch the file; if you accidentally delete the last separator char,
you'll lose the last message since COMSAT will think it's garbage.

The main reason for caution is simply that this is a new feature,
which needs to be proven before it can be fully recommended.  Please
do report any problems...

[Lexical note: "AOS" refers to the Add-One-&-Skip PDP-10 instruction.
The sixbit machine word containing the FN2 is actually incremented
arithmetically to get a new FN2; the usual result of this is a "!" in
the 6th char position, or the next higher character in the ASCII
sequence if there was already something there.]