Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!crg5!powell
From: powell@crg5.UUCP (Powell Quiring)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <19875@crg5.UUCP>
Date: 29 Aug 90 04:36:47 GMT
References: <6797.26d6edce@vax1.tcd.ie> <56qmo1w162w@zl2tnm.gp.govt.nz>
Reply-To: powell@crg5.UUCP (Powell Quiring)
Organization: Sequent Computer Systems, Inc
Lines: 15

In article <56qmo1w162w@zl2tnm.gp.govt.nz> don@zl2tnm.gp.govt.nz (Don Stokes) writes:
>rwallace@vax1.tcd.ie writes:
>
>> 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 b
>> executed on this session with the program (e.g. error handling code).

The fact that you got a parity error indicates that the memory has
been read.  The only question is how much this incorrect value
is going to screw you up.