Path: utzoo!attcan!uunet!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!fts1!nrcaer!sce!cognos!geovision!gd
From: gd@geovision.uucp (Gord Deinstadt)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <1189@geovision.UUCP>
Date: 1 Sep 90 19:33:22 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> <6797.26d6edce@vax1.tcd.ie>
Organization: GeoVision Corp., Ottawa, Ontario
Lines: 19

rwallace@vax1.tcd.ie writes:
> 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).

In all the parity checking memories I've seen, parity is only checked when
the data is fetched by the CPU or DMA controller.  So it *is* in use.
ECC systems do generally access
memory locations that are not in use, but that's because they can usually
do something useful, ie. fix the data if only a single bit is in error.

> 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.

No doubt 32198742.88888 posters have already replied to this.  What they said.
--
Gord Deinstadt  gdeinstadt@geovision.UUCP