[JR@YUKON.SCRC.Symbolics.COM: Incremental tape re-use]

[Kalman Reti <Reti@STONY-BROOK.SCRC.SYMBOLICS.COM>]

    Date: Thu, 10 Aug 89 10:41 EDT
    From: JR@YUKON.SCRC.Symbolics.COM (Johanna Rothman)

	Date: Wed, 9 Aug 89 08:31 PDT
	From: Mr. Spock <Spock@SAMSON.CADR.DIALNET.SYMBOLICS.COM>

	    Date: Wed, 9 Aug 89 01:02 EDT
	    From: pan@Athena.Pangaro.Dialnet.Symbolics.Com (Paul Pangaro)

	    [...]

		    The Truth as I know it:

		    1. 36xx tape drives don't support appending to tape.  They are not
		    physically capable of it.

	This is something I don't understand.  How can a tape drive be
	physically incapable of appending?

    36xx machines have streaming cart drives.  The actual problem is that
    the tape cannot space backwards.  To append, you must space forward
    until you find the end-of-tape (two consecutive filemarks), reverse
    space past the second filemark, and then write your data.  QIC-11 drives
    cannot space in reverse.  You can append after the second file mark, but
    then there is no way to know where the end of tape is.
Or, as the manuals for our 3640 and later tape drives point out, you can just
leave out the second tape mark entirely (using the erased part of the track
to indicate the end of the data written on the tape), and not have to backspace
over anything.

I confess, I didn't think this up by myself; I went to read the manuals.
However, I got a large hint that you could do it because many users of
carts on other workstations and even on PC's regularly append files to their
backup tapes.

I even suspect the old 3600 drives could do it; the manual is terrible and
doesn't say anything one way or the other about it, but the basic facilities
the drive needs for its streaming behavior sound like they are sufficient.
See my reply to Paul's original message for somewhat more detail.

		    3. I have to assume this is not an isolated incident, but to be honest,
		    I don't know of any others.  I'm sure DE and Reza will let me know if
		    there are others.

	The notorious 3600 IFU is another similar issue.  We had to educate our
	local support people on the seriousness of the problem after we found
	out about it.  There isn't any documentation that I know of on this
	(internal or otherwise).  But, I have been assured that Symbolics is
	aware of the problem (a race condition on the IFU) and is working on it.
Actually, I think this is slight misinformation too.  I believe the problem
is not with the IFU, but with the rest of the system that it's in.  I've
seen IFU board sets that have run 100% solidly for years.  Then I've seen
others you could never get to run reliably.  The salient feature was that
by swapping individual boards you hardly ever improved the situation, you
had to get a set that were 'tuned' to each other to fix things.

Early on in the development of the IFU there were many race conditions in it
(as you'd expect, it's hairy and does a lot of things at the same time), but many
people spent a LOT of time and effort getting rid of them.
On the other hand, the original 3600 design had relatively little effort devoted
to timing analysis (there weren't any tools for it, there weren't many people
working on it, the company was in startup mode...); because the IFU is doing
several things at once, it runs more of the rest of the hardware harder than
a TMC (oops, MC) does, so tends to expose timing and noise-related marginalities.

[Rest of discussion, though fascinating, deleted (since I have nothing to add).]