Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!gp.govt.nz!zl2tnm!don
From: don@zl2tnm.gp.govt.nz (Don Stokes)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <56qmo1w162w@zl2tnm.gp.govt.nz>
Date: 28 Aug 90 11:38:17 GMT
References: <6797.26d6edce@vax1.tcd.ie>
Organization: Me?  Organised?
Lines: 77

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

Since when was PC memory not used to the last bit?  Every PC I have ever
had to deal with suffered severe "ram cram" (why, oh why do people
insist on treating '386s as 8086s, with their measly memory maps?).
A memory mix of 100K of system software, 200K of application and 300K of
data isn't unreasonable or atypical.

>                                        OK take the very unlikely case that
> it is in your data.  

Unlikely?  In the mix I give, I make it about 50%.  "Unlikely" isn't how
I'd describe it.

> For me that means in the source for a program I'm writing

Ah.  Now we reveal true colours.  I hate to bring the real world crashing
about your ears, but the *vast* majority of PC users are *not*
programmers.  You take an extremely self-centered view.

> This is no problem, I can just fix the one trashed character when the compile
> barfs on the code.

Even as a programmer, do you not fear unexepected bugs creeping into
your code due to unexpected errors?  I recall back in the dim darks in
my Apple ][ days (no flames please, I was receiving good money for
this), I ran into a problem where well tested code simply stopped
working properly; it didn't give errors, just wrong answers (not nice
when the incorrect answers are cheque totals to go into a general
ledger).  It turned out that there was a bug in the Apple-supplied
BASIC line renumbering program, which would result in constants
occasionally being "renumbered" as well as GOTO/GOSUB targets.  It cost
me over half a day to find the problem, fix it and fully verify that the
problem had indeed been fixed.  It would have been Real Nice if it had
happened just before implementation, wouldn't it?

Compilers often do not barf on single bit errors.  Single bit errors are
the difference between a '+' and '*', '.' and '/', 0 and 1, 'x' and 'y'
(don't try to tell me you don't use single letter temporary variables!).

The PC's I have to deal with are used for typesetting work as well as
more "normal" applications such as running Lotus, word processing etc
(although most users use the spreadsheet available on the VAX).

> minutes' work. Or say the error is in a floating-point number in a spreadshee
> 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.

...or plus or minus $65,536, which in a ~$200,000 bottom line, is easily
missed, but could represent the difference between a profit and a loss;
not to mention the poor bean-counter's job when the mistake is
discovered.

> (Suppose you have a parity error while running a Speed Disk program: kiss you
> hard disk goodbye. Let's see, when did I do my last full backup?). So the PC
> parity protection is worse than useless.

Implementation detail: Norton's Speed Disk writes the directory entry
only after moving files; until the file pointers are finally changed,
they still point to the old, valid copies of data.  The machine crashes
-- so what?  Nothing has been lost.  Now imagine an undetected single
bit error while moving the BACKUP program, that causes backups to be
soundlessly trashed.  Now imagine the inevitable hard disk crash.  Now
imagine the trashed backups being your business records; your livelihood.

Don Stokes, ZL2TNM  /  /                            Home: don@zl2tnm.gp.govt.nz
Systems Programmer /GP/ Government Printing Office  Work:        don@gp.govt.nz
__________________/  /__Wellington, New Zealand_____or:_PSI%(5301)47000028::DON