Joel C. Ewing writes: <begin extract> . . . a violation of one of the major tenets of mainframe design: that any data errors resulting from hardware issues should be at least detectable, if not correctable. </end extract>
Error detecting and correcting codes are by now a classical topic, and in any responsibly designed such code some errors can be detected and corrected and others can be detected but not corrected. The topic is too mathematical to discuss rigorously here; but the underlying notions are, as usual, entirely accessible. Consider an inefficient code in which 0 bits and 1 bits are each represented by four instances of themselves, o 0 ==> 0000 o 1 ==> 1111 The Hamming Distance h between two bit sequences of the same length is then defined as the number of bit positions in which their values differ. For , say, 0000b and 1111b the value of h is 4. Then for the 2^4 = 16 four-bit code-point values shown below we have 0000 licit code point, no error 0001 error, correctible to 0000 0010 error, correctible to 0000 0011 error, not correctible 0100 error, correctible to 0000 0101 error, not correctible 0110 error, not correctible 0111 error, correctible to 1111 1000 error, correctible to 0000 1010 error, not correctible 1011 error, correctible to 1111 1100 error, not correctible 1101 error, correctible to 1111 1110 error, correctible to 1111 1111 licit code point, no error Here a value that is in error is correctible to 0000 iff its Hamming Distance from 0000 is less than its Hamming Distance from 1111 and not correctible if these two distances are equal. Analogously, it is correctible to 1111 iff its Hamming Distance from 1111 is less than its Hamming Distasnce from 0000. This is the case in general, for even the cleverest proper EDCCs: They can always detect more than they can correct. (It is, of course, possible to construct degenerate EDCCs that cannot detect more than they can correct. They in effect forego or disable detection capacity; and they have found some uses in contexts in which what cannot be corrected is best passed over in silence, but these contexts are very special ones.) John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
