10 Jun
2015
10 Jun
'15
12:36 p.m.
On 2015-06-10 17:05, Dennis Boone wrote:
One problem with "preserving errors" is that actual tapes do not have
any indication that you have a tape error. In fact, many times you can
recover a tape block by repeatedly read it. Eventually you might read it
without errors. Not to mention how many tapes I have "fixed" by just
folding the tape in the opposite direction where there have been a
bend/kink in it. Easy fix.
I guess it could possibly be useful to indicate a bad block on a tape,
in order to preserve the numbering of all the blocks, and constantly
giving a read error when used in a simulator. But it's kindof a weird
reflection of a physical error into a virtual one.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
This
hypothetical interface + matching software would be intended for
archiving old tapes and/or making new copies from archived file
(i.e., to make new boot media for bringup of an old computer). Key
features would include preservation of block sizes (even if varying
arbitrarily) and file marks. I'm not sure if there's already a good
file format for that, and I have a dim memory of previously reading a
lament about common archival methods failing to preserve blocking.
The E11/SimH .tap formats are dead simple, and relatively complete as
far as capturing the arrangement of the bits on tape. They retain block
size, actual data, file marks, and have a provision for indicating
errors encountered when reading the tape. There was a discussion
recently (simh list?) about standardizing the behavior of the error
marks. The format doesn't have a mechanism for preserving metadata. In
the SimH variant, record lengths must be even. In the E11 variant, they
on't have to be. Otherwise, the two are equivalent.
Using dd to read tapes to disk discards the block size information.