[Info-vax] Exabyte tapes to disk

[jbriggs444]

On Aug 28, 12:14 pm, Chris <cdandre... at yahoo.com> wrote:
> We have 8mm exabyte tapes with archived data on them. Our old vax
> machines could read/write these tapes with no problem with exabyte
> tape drives (SCSI connection). We would like to get the data off of
> these tapes and eventually onto disks (so that the data is more easily
> accessible, don't have to mess with tape drives etc.). However,
> whenever we use our vax to copy the data to disk, the files are not
> readable by other machines (e.g. there is a bunch of garbage before
> the data). We have been unable to find a way to use any other machine
> to copy the data from the tape to disk. Has anyone had any success
> with something like this? What worked?

My attempt to divine from the tea leaves what is likely to work:

1.  The data is on tape in BACKUP save set format.  It has been copied
to disk and then displayed

$ mount tape: /ov=id
$ copy /log tape:*.* []
$ dump somesavesetfilename.bck

or

$ mount tape: /foreign /block=32256
$ copy ./log tape:*.* []tapefile.dat
$ dump tapefile.dat;2 (skipping the VOL1 and HDRn records in
tapefile.dat;1)

I'm speculating that the "bunch of garbage" is coming the VMS backup
header information at the front of the save set.

The solution is to use BACKUP to restore the data to disk.


If I recall correctly you can't put an indexed file on disk, so the
garbage can't be the prologue from an indexed file.

It could conceivably be some 80 byte ANSI labels from a labelled tape.


Generally speaking, all mag tapes (except TU58 and DECtape) emulate 9
track mag tape.  The tape contents is structured as a sequence of
blocks where each block is separated from the next by an [emulated]
inter-record gap.  In addition, at the end of a sequence of blocks
there is a "Tape Mark" which is conventionally interpreted as "end-of-
file".  After the last file on tape, two back-to-back tape marks are
expected.  These conventionally indicate end-of-volume.

Tapes are written sequentially from the beginning to the end.  It is
possible to append to a tape from a starting point in the middle of
the tape after a pre-existing block or tape mark.  It is not possible
to update a tape in the middle.  An attempt to read past the block
most recently written will traditionally result in a parity error.  So
if you write a block in the middle of the tape, the remainder of the
reel is rendered unreadable until overwritten.  On more modern drives
or on emulated media, attempts to read past the last block written
often result in a fatal "position lost" diagnostic [the VMS driver
needs accurate knowledge of its position in terms of how many tape
marks it has passed and how many tape blocks it is past the last such
mark.  If hardware errors make this knowledge uncertain, the driver
reports "position lost" until it is commanded to rewind and thereby
regains its position knowledge].  Classic start/stop 9 track drives
didn't lose position that way.  Only streaming and emulated drives do.

Short blocks (less than 14 bytes or so) are forbidden for writing and
will not be seen when reading.


On an ANSI labelled tape the first "file" on the tape is a series of
80 byte blocks.  The first four characters in each block are "VOL1",
"HDR1", "HDR2", "HDR3", etc.  These are the tape labels.

The second "file" on the tape is an actual data file.  It is encoded
as described in the HDR labels.

The third "file" on the tape is a set of trailer labels, "EOF1",
"EOF2", etc iirc.

The pattern repeats with a set of HDR labels in front of each data
file and a set of EOF labels behind.

Finally you get the double-tape marks after a set of EOF or EOV
labels.  This indicates end of volume.

Back to back tape marks are permitted where an actual data file would
have appeared.  In this context the back to back tape marks do not
indicate end-of volume.

This ANSI labelling convention is quite similar to the EBCDIC
labelling convention referred to as IBM Standard Labels.  Key
difference other than character set is that ANSI labels use ASCII
printable characters (imposing a 9999 byte length limit in some
cases).  IBM labels use binary data in a few places, e.g. in record
and block length fields.