Dennis,
This is very interesting, and sort of encouraging. Thanks for
the advice. I see there is a data conversion company that
specializes in DEC formats, so if we decide this tape is one that came
from our tape drive, I may talk to them, too.
John
At 11:49 AM 3/26/2013, Dennis Boone wrote:
> 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