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

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

    Date: Wed, 9 Aug 89 22:44 EDT
    From: Paul Pangaro <pan@Athena.Pangaro.Dialnet.Symbolics.Com>

	Date: Wed, 9 Aug 89 20:22 EDT
	From: Reti@RIVERSIDE.SCRC.SYMBOLICS.COM

	[Slug removed, because this is part rumor rather than known facts.]
[Slug added back in, because I just read the manuals.]

    Can you consider relaxing this description and sending it to the whole
    list? It is too valuable to lose.
Maybe yes, maybe no.  In any case, I'll defer to your judgement.  And, its
late at night and I've gone a long time without sleep and I needed a break.

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

	    Anyone from SLUG have any opinions on this? What about useful
	    suggestions?  Can the community of users help Symbolics invent ideas on
	    how it can create a viable corporate memory. Users are already part of
	    it (since it already acts in that capacity, by responding to slug e-mail
	    from users), but how should such a mechanism be instrumented?

	    PANgaro
	    ****************************************************************
	I realize your mail was addressed to the meta-topic of how Symbolics corporate
	memory can be improved, I believe the topic of this message exchange needs some
	further explication.  The following is what I've heard about the subject from
	various sources I no longer remember.  [That appending works on some drives
	I know from reading drive manuals; that it works one our particular drive
	I know only from hearsay, i.e. I've never seen a manual for our drive.]
I have now seen the manuals for our drives; they live in a pretty well-organized set
of hardware documentation in SCH and even though it was the dead of night (I'm taking
a break from my 'real' job) and no-one was around, I got the information I needed.
(Someone did something right; I don't even know whom to commend for setting up the library.
So I'll just let loose a barrage of undirected kudos.)

	The old 3600 drives couldn't append, but the newer drives used in later machines
	(364x, 367x OBS, all NBS) are reputed to be able to append.  However, their
	ability is said to be limited to overwriting a single tape mark at the end
	of the data.
This was fairly close (the error is that cart tapes can't overwrite even the single
tape mark but that doesn't prevent them from appending).  

The old drives we used in the 3600's were made by Cipher (Series 400 Quarterback, 
the manual covers four models, two formatted and two unformatted, so it
has to be one of the former [F420-90 or F420-30, the suffix refers to the tape
speed in inches per second]).  Its manual is remarkably silent one way or the other
on its ability to do appends; however, its basic logic is similar to other drives
that CAN do appends (of the streaming cart variety, see below), that it would probably
have been worth the experiment to see if it worked or not. (The manuals also stated
that a formatted drive could control up to three unformatted drives, so it would
also have been possible to have a 3600 with more than one cart tape drive.)

The newer drives are both from Archive (Sidewinder and Scorpion) and their manuals
describe appending explicitly.

Appending on a streaming cart tape drive is different from appending on a magtape
drive.  On a magtape you write a file mark after your data, then a second file
mark to signal logical end of volume, and finally you backspace over the second
tape mark.  If you decide to write another file on the tape at this point, the
drive will just erase this second tape mark and continue writing.  Similarly,
if you mount a tape, read till you hit two tapemarks in a row and then backspace,
you are in exactly the same state, and can continue writing new data onto the end
of the tape.

Cart drives, on the other hand, can neither backspace (under user control) nor
overwrite anything that is already written on the tape; this means they cannot
append in exactly the same manner that a magtape does.  However, because of their
streaming nature they already have the ablility to stop the tape when the CPU doesn't
provide output fast enough, internally backspace, and then, once the data appears,
scan past the already written blocks until they come to the erased portion and then
start writing the new blocks.  This ability is basic to the streaming nature of the drive,
and is sufficient to implement a simpler model of appending, to wit: write
files to tape followed by a single tape mark and let the "no more data" indication
of erased tape serve the function of the second tape mark in magtape terms (to
signal the end of the useful data on this tape).

So, the method for appending data to a tape is to read until you get this error,
and then simply start writing.  As I said, this is explicitly mentioned in the
manuals for the newer drives; since the older manual doesn't say anything one
way or the other, you'd just have to perform the experiment to find out (or
call the relevant people [if you could find them and they'd remember and remember
correctly {hmmm... corporate memory, yup, rings a bell}].

Obviously, the old drives could have had a bug where they considered reading into
the erased portion a fatal error and wouldn't let you start the write operation, but
that's just guesswork.  I'm pretty sure that the original developers writing the
cart tape code (all long since gone) didn't understand this stuff very well (I
remember talking to them about it) so I doubt that they tried the experiment.

	Because the cart formats we use try very hard to look like magtape formats
	(i.e. to be generic), they uniformly end with two tape marks which makes
	the special purpose append of which the drive is capable of useless.
This is completely bogus (I can be pretty severe in my criticism, since I know the
author wouldn't dare chide me); if you use the "no data" indication that you have
reached the erased portion of the track as the second tape mark, you have something
that is 100% analogous, just implemented differently.

(Oh, I should probably mention since some may not know it, that in contrast to
a magtape which writes N (most commonly N=9, but in the old days...) tracks
simultaneously, a cart tape writes its N tracks (N=4, 9, ...) serially, first
going one direction then the other.  Whenever it starts writing track 0 at
BOT, it turns on its erase head to erases the entire width of the tape,
i.e. ALL the tracks, ahead of the write head [which is in turn ahead of the
read head so it can check what it just wrote over what it just erased].)

	Of course, this added information only serves to underscore the necessity
	of improving Symbolics' corporate memory.

    As Jerry Lettvin was famous for saying just when you had made 1his0 point,
    thank you.
Unfortunately, I don't know Jerry Lettvin.

	On this meta-topic, however, I also have a point.  There is a completely
	different group within Symbolics which doesn't read SLUG, doesn't read
	most of the bug-lists and which therefore probably never heard of the
	discussion, but which nevertheless might know the answer definitively,
	so the problem may be more one of corporate communications than corporate
	memory.  I'll check this out after tomorrow, when I fly to California,
	and let you know.

    This simply shows the artificiality (whether in artifical i. or not) to
    distinguishing internal communcations from memory. I am most anxious to
    hear what you learn in CA.
Well, I talked to some of the people who might have known but who didn't; however
the most likely candidates were on vacation or away, so I don't yet have a definitive
answer to this part.

I'll say this for Chatsworth though, the manuals were here. (Go kudos!)  I wanted
to look this up several times during my years at SCRC and could never find them when
I went looking, (mostly late at night when noone was around, taking a break from
my real work).

    Best,
    PANgaro
Hope this helps. -- Kalman