2 May
2002
2 May
'02
10:26 a.m.
Re:
Frank writes:
Ditto. I haven't used it...but if it's ever returned by the
hardware I'm darn sure going to preserve that information!
Yep.
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. 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. 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(a)allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler