[Info-vax] Exabyte tapes to disk

[jbriggs444]

On Sep 2, 1:56 pm, glen herrmannsfeldt <g... at ugcs.caltech.edu> wrote:
> jbriggs444 <jbriggs... at gmail.com> wrote:
>
> (snip)
>
> < Generally speaking, all mag tapes (except TU58 and DECtape) emulate 9
> < track mag tape.
[...]
> Maybe too general.  There are tapes other than TU58 and DECtape
> that use fixed length blocks.  (Often 512 or 1024 bytes.)
> Some have the ability to do random access (writes), others don't.
> There were cheaper cartridge drives that connected to a floppy disk
> controller, and pretty much wrote the data as a floppy disk would.
>
> Some drives (DDS, Exabyte, LTO) have a configuration option
> to read/write fixed length blocks, or more traditional variable
> length.

Cool.  I did not know that.  I've always assumed those kind of games
are dangerous to play -- skew the tape position a little bit here and
a little bit there and eventually you're overwriting somebody else's
block.

> Some tape systems try to be too smart.  For DDS (I believe) drives,
> if you start writing in the middle, the drive will refuse to let
> you read anything after the final EOF.  That is, even if the software
> will read through parity errors and block length errors, the drive
> will refuse.  If the tape is long, the only solution is to start
> writing, and then power down the drive before it can write an EOF
> mark to the tape.  You can then read through the errors and onto
> the later data, if it hasn't been overwritten in the process.

Nice trick -- stopping the drive from writing the EOF.  Low tech
rules!

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.

[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."

[...]

> There is also the complication, at least for IBM systems, of
> multi volumes.  That is, the data may take up more than one
> tape, and the system knows how to process it, requesting the
> next tape when needed.

Yep.  Same on ANSI labelled tapes.  You can hit EOV before you hit EOF
and the tape ACP has to run through the process of rewinding/unloading
one reel and loading/initializing/verifying the next before you can
resume reading or writing.

> 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]