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