Tape dumping programs for Unix/Linux...

From: Stan Sieler <sieler_at_allegro.com>
Date: Thu May 2 17:26:01 2002

Re:

Frank writes:
> I'm not sure if "recovered read error" has such uses. Stan?
> Enlighten us?

As Frank probably knows, on MPE the FSETMODE intrinsic is used
to enable reporting recovered tape operations:

   12:1 Reporting tape device automatic error recovery.

      0 Do not report automatic error recovery on a tape device.

      1 Report tape device automatic error recovery by returning CCL
        to FREAD and FWRITE.

Uses during read:

   1) knowing the number of recovered read errors tells you something
      about the overall reliability of the tape data. A tape with 1000
      recovered read errors is more questionable than a tape with 0 recovered
      read errors.

   2) knowing more information about the reliability/veracity of a
      specific record read from the tape.

(similarly during write)

As for how the tape drive determines when to signal a recovered error?
I have no idea...if I ever knew, I probably forgot it 20+ years ago :)

Keep in mind one thing: engineers who spend their lives working on tape
hardware thought it was important enough to be able to signal recovered
errors ... for a reason.

Also, keep in mind something else: as far as I can tell, SCSI tapes
seem to lack a recovered error reporting capability. (Even on MPE :)
(Sure, on some drive, with some OS's, you might be able to access
the error log later...but that's not the same as a record by record
indicator.)

Checking for recovered errors is like checking for corrected single
bit errors in memory. Both indicate that a certain level of problems
are occurring.

> > > - ability to flag if an End-of-tape marker/indicator was seen
>
> I can see some use for this if you want to use the recovered
> image file with an emulator -- you can provide the physical-EOT
> indication to the emulator. What's it good for? I don't know, but
> I wouldn't be surprised if there is some software that relies on
> seeing the physical-EOT mark while reading.

Ditto. I haven't used it...but if it's ever returned by the
hardware I'm darn sure going to preserve that information!
 
> > Anyway, I encode that kins of descriptive information (what kind
> > of computer, encoding, #tracks, etc) in the filename, or in the
> > name of the directory containing the file, or in a README.
>
> There is something to be said for keeping all the related bits
> together in a single container, it keeps them from getting separated.

Yep.
 
> Where does one go to find "the emulator community"?
>
> I don't think there is one, I think there are several, just like there
> are at least two "TAP formats", both having to do with container files
> for tapes, only one is for proper serial magnetic media like I think
> we are discussing, and the other is for audio data cassettes on some
> 1980s bitty box (a Sinclair Spectrum I think).
>
> Are they going to care? Should they, so long as there's a reasonable
> way to down-convert a fancier tape container file format to their
> flavor of TAP format?

BTW, neither my tapedisk format nor the TAP format support the
unusual/oddball "continuous" tapes. I remember getting one off a
ship-board data recorder in 1970. We couldn't read it on an IBM
or Burroughs mainframe, but someone hand-coded an I/O channel program
on our CDC 3600 so that the I/O channel program was illegal: it
looped back onto itself. It worked, because we were able to write
the data (in fixed record chunks) to a slightly faster tape drive
as it came off the slightly slower tape drive.

Stan Sieler sieler_at_allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
Received on Thu May 02 2002 - 17:26:01 BST