[Info-vax] Exabyte tapes to disk

[glen herrmannsfeldt]

jbriggs444 <jbriggs444 at gmail.com> wrote:
(snip)
 
< You ever hear the VAX Magic trick of "dual density mag tape"?  Guy had
< a reel that had a data set at 1600 BPI when read on one drive and a
< different data set at 800 BPI when read on another.  Much hair-pulling
< ensued.
 
< Turns out the reel had _two_ reflective strips near BOT.  One drive
< positioned early on the tape and scanned forward to find BOT.  The
< other drive positioned late and scanned backward.  Voila.  Two
< datasets on the same tape at two different densities.

It was not unusual to get two different densities on IBM systems.
When you write a tape, you specify the density you want.  First
the system verifies the label, in which case the drive adapts to
the density.  Then it skips existing files, again at the density
they were written at.  (It probably can find tape marks without
actually looking at the data, but it does have to read the label.)
Then new data is written at the specified density.

It is usual on IBM mainframes to require either a label (SL) or
no label (NL).  In the latter case, there must be a tape mark.
If you mount a brand new tape, the drive will run it off the reel
searching for the label.  (And get the operator mad at you.)

< [snip explanation about "position lost"]
<> I thought it didn't need that if mounted /FOREIGN, but I might
<> have forgotten.
 
< My memory isn't reliable either.
 
<> < Short blocks (less than 14 bytes or so) are forbidden for writing and
<> < will not be seen when reading.

<> The IBM numbers were 12 and 18. ?I believe they would refuse to
<> write less than 12 bytes. ?You could read short blocks, but if an
<> error was detected in a block less than 18 bytes, it was declared
<> noise. ?If no error, it was fine. ?(It might be that the 12 and 18
<> are reversed.)
 
< Looks like my VMS memory was accurate.
 
< http://www.openvms-rocks.com/docs/OPSYS/VMSOS731/vmsos731/6136/6136pro_011.html
 
< "The transferred byte count reflects the size of the block written. It
< is not possible to write a block less than 14 bytes in length. An
< attempt to do so results in the return of a bad parameter status for
< the QIO request."

(snip on multi volumes)
 
<> I had forgotten about the binary data. ?I do remember that you
<> can write VOL1 followed by the tape volume (six character) name
<> in EBCDIC in an 80 byte block, and the system will accept it.
<> (Sometimes easier than the official tape label process.)
 
< I think I've done this to "initialize" a tape that was already
< mounted /FOREIGN myself as well.  If I remember right that was before
< I found the complete set of things to /OVERRIDE= so that you could
< operate on a tape within a single human lifetime.  [/OVERRIDE=
< (OWNER,ACCESS,EXPIR) -- buys you a very nice speed-up]

For IBM systems, it only works for converting an NL tape to
an SL tape.  The tape must have data or at least a tape mark already.

-- glen