> If an old tape reel from the 1980s has a label on it that reads,
> "Memorex Cubic 6250 BPI SuperReel" and a typed tag saying "MSU
> Permanent Tap ID Number B 577" does that mean it was created at the
> Computer Lab, as it was then called?
> A former faculty member is interested in having a data recovery
> company try to recover files from it.
John,
The Memorex label indicates it was certified by them for 6250bpi data,
but that doesn't mean, of course, that data was actually written to it
at that density. My guess is the recording is 9-track, not 7-track,
based on the specified era, and probably > 800bpi density for the same
reason.
The VRN doesn't look like one from the MSUCL IBM mainframe system that
was installed in the '86-'87 time frame, unless the label was misread
and actually says "8577". I didn't do much of anything with tapes on
the Cyber system which preceeded it, so can't speak to those numbers.
There were other systems around for which the dates in my head are
fuzzier -- a VAX or two, a Convex supercomputer, possibly other things.
Again, I can't speak to tape numbering for those systems.
While 9-track tape drives were available which wrote at 3200bpi, it's a
fairly uncommon format. Chances are pretty good that the tape was
written at either 1600bpi or 6250bpi.
I've fairly trivially read 9-track tapes from the early- and mid-80s
without any significant trouble, even tapes which were stored in a
Michigan attic for many years. They're remarkably durable.
The principal issue which may arise for media of that era is that the
binder used to stick the oxide to the backing tends to absorb moisture
and become sticky. This glue/oxide mixture can then "shed" off the tape
onto the heads, which impedes smooth flow of the tape across the heads,
and in fact even stick to the heads and not move at all. Depending on
the drive, the tape could snap. Regardless, data is recorded on that
oxide, so you don't want to scrape it off. Some media manufacturers'
products do this worse than others, and a lot depends on the conditions
in which the tape has been stored. The usual solution to this "sticky
shed" problem is to bake the tapes gently to dry them, then carefully
and immediately read them once. The professionals will have a procedure
for this that optimizes their success rate, but I've been able to win
with stunts as simple as placing the tape in a food dehydrator for 24
hours.
It shouldn't be difficult to find a media conversion or data recovery
outfit that can do this, even in Australia.
The harder part of the process may be the data archaeology -- sifting
through the bits read from the tape to extract the end-user data from
whatever wrappers were applied by the tool used to write the tape. If
it's a PFDUMP tape written on the Cyber, Mark Riordan wrote an extractor
tool. For DEC/VAX or IBM formats, things are probably easier, since
those operating systems are still commercial products.
I have a tape imaging lecture that goes "Don't use unix 'dd' to image
tapes. It throws away tape block size information." If a recovery
company will be handing you a tape image, make sure they use a format
that retains that information.
De
|
