The tape handling in VMS 7.1 got upgraded to permit mkdriver
to use SCSI skip by filemarks if more than 2 files were being
skipped. This uses the ability of modern tape drives to:
1. report their current position when asked, and
2. report blank tape error when they pass the current logical
end of tape.
These abilities get tested for in the 7.1 mkdriver and the
ability to use skip by filemarks is set accordingly. To some
extent the use of this can be disabled with sys$etc:mkset
but the initial tests are not all controlled this way.
Rather there is a table of tape device types in mkdriver, like
the one in dkdriver I wrote about, which flags tapes that are
known to hang or misbehave when queried so they can be handled
in the old way. This works off the device ID in SCSI INQUIRY
(the names visible at the >>>sh dev display before boot).
There are likely to be some tapes that get confused and are not
in the table (there being only 2 or 3 people who do any
mkdriver work generally, and limited numbers of random tape
devices and limited time) due to this new testing. Most of the
time it won't mess anything up, but "scsi" devices often only
implement a tiny bit of SCSI and may leave out something needed
by an OS that does interrupt driven DMA etc.
This is almost certainly why old savesets cannot be read; the
drive is* at first, or may be* in some skip
operation (less likely). The good news, if you have support, is
that you can probably get help telling mkdriver that your
tape cannot support skip by filemarks. If you don't, you'll
need to somehow get into mkdriver and patch it.
If you convince it your tape is suitably dumb things may start to
For a "dumb" tape I'd suggest replacing strings for
TZK10, TKZ60 or TKZ09 with the strings for your tape.
These exist in ascii in mkdriver. However be aware you are
on your own for this and for support. Don't do it to your
only copy of sys$mkdriver.exe!!!!