2

Preamble

For a while, I had a copy of a BESM-6 Pascal compiler which worked only on very simple programs, like "Hello, world", and would throw a division by 0 exception on anything more complicated, and, on another disk image, a copy of a slightly older revision of the same compiler which worked perfectly.

Last week, I got a chance to figure out what was going on by doing a comparison of the two compiler binaries; luckily, they synchronized quite well except for a slight difference in offsets in procedure calls.

The difference was in a couple of instructions, which were completely nonsensical in the bad version. After replacing them with the corresponding instructions from the good version (correcting for a procedure offset), the problem went away.

Question

As far as I remember, the IBM 9-track tape with the disk image was given to a guy who had a tape drive in his garage, and he had sent back the result, so it is unknown if reading of the block with the corruption was flagged as I/O error — because of the differing parity of the bytes between the good and the bad version — or not.

How plausible is a media corruption of an 800 bpi (NRZI, I guess) 9-track tape which would cause reading of the byte sequence ... 10 D9 8C 45 32 6E ... instead of the correct ... 10 00 35 D9 8C 6E ...?

Improve this question
7
  • Are the numbers supposed to be decimal?
    – Raffzahn
    Oct 28 '20 at 22:20
  • The tree-digit notation of bytes, with some of them starting with 0, is traditionally octal, as in UNIX od -b.
    – Leo B.
    Oct 28 '20 at 23:30
  • Quite confusing without explicit notation, especially when referring to IBM in the same context.
    – Raffzahn
    Oct 28 '20 at 23:34
  • @Raffzahn Fair enough, I've converted them to hex.
    – Leo B.
    Oct 28 '20 at 23:38
  • Data corruption did happen occasionally, even with well maintained hardware and professional operators and tape librarians. Old tapes were "retired" after a certain amount of use to minimize the consequences. In fact there were optical inspection devices which contained a fluid with fine suspended magnetic particles, which could be used by tape librarians to visually assess the condition of a tape. Of course there is no way to know how your tape had been stored and handled over the years, or the condition of the hardware and/or software that read it.
    – alephzero
    Oct 29 '20 at 1:28
5

Comparing the two set of bytes suggests there might have been a problem where the tape physically "stuck" and then "jumped", reading erroneous data:

10 10
   00
   35
D9 D9
8C 8C
45
32
6E 6E

Of course there is no way to know what conditions the tape had been stored in, how well the tape reader had been maintained, and how the reading software would have handled hardware errors (including parity errors).

Improve this answer
1
  • I've noticed the out of order match as well. The erroneous read is on the left; to achieve that, it had to be that two bytes were skipped, then two bytes were read correctly, then two bytes of garbage were produced, then the tape resynchronized. Interesting....
    – Leo B.
    Oct 29 '20 at 3:06
3

There is no easy answer without way more information - especially as it's a non-IBM machine.

In any case, a bit flip on 9 track is of course possible, like with any media. Detecting it depends on a lot of factors not mentioned so far - for example what format is used, what block structure, if at all, and what additional checking this block structure offers.

Without seeing the parity bit noting can be guessed from the byte sequence shown.

Basic to all formats is only a single parity bit per character. Already a double bit flip within the byte will pass undetected. Only additional protection like record and block checksums/CRC may detect such - if used. Basic recording on 800 NRZI 9 track does operate with records and no additional error check information. If the data is recorded in basic record format, an I/O error will only be be raised on single (or any uneven) bit flip within a single byte.

Long story short, it would be helpful to know more about the higher format layers used and see the raw header data (CRC in block formats is stored at block start).

Improve this answer
2
  • There was no higher format layer. Just a sequence of blocks, 6K bytes (1K 48-bit words) each, no checksums. It is my understanding that n NRZI, a sampling error might have different effects depending on surrounding signal levels.
    – Leo B.
    Oct 28 '20 at 23:45
  • Well, analogue signal level dropout would come in addition for any format.
    – Raffzahn
    Oct 29 '20 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.