 |
 |
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