Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <6797.26d6edce@vax1.tcd.ie>
Date: 25 Aug 90 21:29:50 GMT
References: <1990Aug3.204358.330@portia.Stanford.EDU> <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> <2421@crdos1.crd.ge.COM> <1990Aug18.210132.25203@sco.COM> <2434@crdos1.crd.ge.COM>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 34

In article <2434@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>   In spite of all that, I'd rather have parity checking, because I have
> had real genuine errors in the data memory, and I want to know about it
> when it happens.

If the operating system just told you about it when there was a parity error
I'd agree with you, something like flashing up a message on the screen:
"Parity error detected in code segment at 1234:5678, reboot? (Y/N) ".
However automatically crasing the computer is NOT acceptable behaviour: I'd
much rather do without the parity checking. Consider: suppose a parity error
occurs on a 640K machine. The error is probably in either an unused area of
memory (e.g. at the DOS prompt) or in a section of code that isn't going to be
executed on this session with the program (e.g. error handling code). (I'm
talking only about transient errors here: the boot time memory check will get
other kinds). So ignoring the parity error will probably have no effect. If
it's in a section of code that will be executed, the machine will just crash
which is what would have happened anyway. OK take the very unlikely case that
it is in your data. For me that means in the source for a program I'm writing.
This is no problem, I can just fix the one trashed character when the compiler
barfs on the code. Much better than having the machine crash and lose several
minutes' work. Or say the error is in a floating-point number in a spreadsheet.
Chances are the program will crash with a floating-point error or at least
produce obviously wrong results e.g. profit for 1989 was $-32198742.88888.

The point is that ignoring a parity error is a pretty safe thing to do; there's
very little chance of getting a misleading answer. Much better than crashing
the computer, which is guaranteed to lose you whatever you had in memory.
(Suppose you have a parity error while running a Speed Disk program: kiss your
hard disk goodbye. Let's see, when did I do my last full backup?). So the PC
parity protection is worse than useless.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie