Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!akgua!gatech!seismo!lll-crg!ucdavis!ucbvax!info-vax
From: goldstein@2124.DEC (Andy Goldstein)
Newsgroups: mod.computers.vax
Subject: Re: My mind is going Dave;  I can feel it
Message-ID: <8511221637.AA08796@decwrl.DEC.COM>
Date: Fri, 22-Nov-85 11:04:20 EST
Article-I.D.: decwrl.8511221637.AA08796
Posted: Fri Nov 22 11:04:20 1985
Date-Received: Sun, 24-Nov-85 11:17:50 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 45
Approved: info-vax@sri-kl.arpa


Sorry about this one, folks. We committed one of the classic no-no's
in tape handling: writing a label record after reading forwards. For
those of you not familiar with this bit of arcane magtape folklore,
the gory details follow:

A standard tape drive has separate read and write heads, with the
write head ahead of the read head, from the point of view of the tape
motion, so that the read head can read back and check what's just
been written. The two heads are separated by .15". This fact can get
you into trouble when you switch from reading to writing in the
middle of tape records. What happens to BACKUP is this:

You init a tape. This puts a VOL1 header label on the tape, followed
by header and trailer labels for an empty dummy file. The file is
recognizable as a dummy by the fact that it is given a zero sequence
number. Now you tell BACKUP to write a save set to the tape, using
the default tape handling, which is to append to the tape. BACKUP
recognizes the dummy file labels, rewinds the tape, and spaces over
the VOL1 label to write the real file labels for the save set.
At this point, things look like this:


            *BOT*   VOL1   HDR1   HDR2   *TM*   .....
                         ^^
                         ||
                         |write head
                         read head

When you're dealing with GCR tape, the gap between the labels is only
.3", and the read head will have coasted a ways into the gap, meaning
that the write head is .15" further along. Now when you start writing,
the tape has to get up to speed before the write head turns on. By the time
this happens, HDR1 may have already gone by. (Remember that at 6250 BPI,
an 80 byte label record is microscopic.) The new HDR1 and HDR2 get laid
somehow on top of the old HDR2. The result is trash in the wake of
the old HDR1 that the tape drive can't make any sense of, so when
you try to read the tape back, all you see is the old HDR1; sanity
finally returns with the tape mark.

Anyway... BACKUP will get fixed in VMS V4.3, by rewriting VOL1 in this
circumstance. In the meantime, there's a workaround. The problem only
occurs when you write a save set to a newly inited tape using /NOREWIND
(the default). Therefore, if you're writing to a fresh tape, tell
BACKUP /REWIND, and you'll avoid the problem.