[Info-vax] Copying VMS SaveSet Under Windows

[jbriggs444]

On Nov 21, 2:50 pm, Michael Kraemer <M.Krae... at gsi.de> wrote:
> JF Mezei schrieb:
>
> > About ANSI tapes:
>
> > Question: does the tape drive itself signal end of file and end of tape
> > ? Or just end of tape ?
>
> > or does the tape automatically  skip inter block gaps and return block
> > after block, with only end of tape being signaled ?
>
> there's nothing magic about ANSI tapes.
>  From the tape drive's (and UNIX') point of view,
> the files on tape are still sacks of bytes,
> separated by single tape marks, and a double tape
> mark signals the EOT.

To the best of my knowledge, modern tape drives
still adhere to the classical presentation:

blocks separated from one another by [emulated] inter-record gaps.
files separated from one another by [emulated] tape marks.
end of tape is encoded as [emulated] consecutive tape marks.

Even Unix is able to detect and report inter-record gaps on tape:
How many bytes came back from that read()?

If a Unix application wishes to hide record boundaries from
its user community, that's irrelevant to the tape drive or
driver.

> It's just that some OS's (e.g. VMS) wraps
> each tape file in an extra header
> and an extra trailer file containing additional
> file info (name, date, recl etc), and the whole
> tape is assigned a volume label recorded somewhere
> in the first header. It's not rocket science,
> but of course requires some extra work to teach a Unix system
> to read that information - if anybody would be interested.

Yes indeed.  One "gotcha" with this approach is
that ANSI labelled mag tape allows the possibility of
an empty file encoded as a pair of back-to-back tape
marks.  Classically there is no way to encode an
empty drive on tape.  Some tape drives have (or had)
firmware that considers an encoded empty file
to constitute end-of-tape.

Easy way to cut your teeth on ANSI labels is to treat
the tape as a sequence of files, three real "files" per ANSI
labelled "file".  Read off one file from a /FOREIGN mounted
tape for the header records, one file for the encoded file
contents and a third file for the trailer records.  Lather,
rinse, repeat until you find a second tape mark where the
header records would have been.  Or write the /FOREIGN
tape as a sequence of three files per file in the same
manner.

Header and trailer labels are sequences of 80 byte
fixed length tape blocks where the first four characters
identify the record contents, e.g. "VOL1", "HDR1",
"HDR2", "HDR3", "EOF1", "EOV1",

I'm not familiar with the encoding techniques that
would be used if a Unix user were to request a ten
byte write operation (classical 8 track mag tape
drives have a minimum supported record length
of 14 bytes iirc).

> I did such things about twenty years ago to facilitate
> data exchange with the non-DEC world. DEC Unices
> (Ultrix, OSF/1) have the "ltf" utility on board,
> but iirc it has limited capabilities (i.e. no
> multivolume support etc.)