PARCHK.DOC (description of the PARCHK program)
03/20/84
Skip Gilbrech (71445,534)
90 Lexington Ave. #10-G
New York, NY 10016
(212) 685-0551
USAGE: PARCHK /R (or) /D
/R = Report all errors which occur
/D = Disable reporting after an error

PARCHK is a resident program which replaces the ibm pc rom-bios NMI
(non-maskable interrupt) handler.
It will report any memory parity errors to the operator, but will allow the
system to continue running (or CTRL-ALT-DEL can be pressed during the printing
of the error message, if desired). An installation option lets you choose
whether or not to receive continued reports after the first error for a
particular channel (system memory or i/o channel). Regardless of the option
chosen, however, the first error for each channel will always be reported.
I wrote PARCHK mostly because of the frustration I felt a few days ago when the
message 'PARITY CHECK 2' appeared suddenly on my pc's screen. I had seen the
message a couple of times before, but never at a time like this: The machine
contained over 3 hours of unsaved work, and I knew there was not a thing I could
do about it, since the parity error handler in the rom-bios simply disables
interrupts and issues a HLT instruction to the cpu.
I have also read a number of messages on the Compuserve IBM-PC SIG which
indicate that I'm not the only one to have had this experience. IBM's approach
in the rom-bios makes some sense. The condition of system ram is unknown
following a parity error, and continued operation MIGHT result in all sorts of
horrible consequences, i.e., hopelessly corrupted data on disk, etc. On my
system, though, memory parity errors have been extremely rare, and have probably
resulted from a slight glitch on the power line, static, etc. I really have no
idea what would have happened if I had been able to continue operation in those
cases. However, I have crashed the system often enough (most of the time
probably executing random data or instructions somewhere) to have some
confidence that the most likely, if not the only possible, outcome of a
processor gone wild is simply a dead machine, i.e. interrupt vectors wiped out,
etc., which must be powered-down and up.
So, for me, the risks of continued operation -- at least until important
data in ram are saved -- seem relatively small when balanced against
the CERTAINTY of lost data when the rom-bios routine gets control: If
data HAS been corrupted, at least there remains the chance of later
being able to examine and possibly fix it.
Continued operation still DOES represent a risk, however, especially
if parity errors occur often, since that probably indicates a serious
hardware problem somewhere in the system.
If you don't want to take that risk, please don't use this program,
as I can't, of course, take responsibility for any damage, real or
otherwise, it may cause.
On the other hand, if PARCHK is ever responsible for saving a multi- million
dollar oil deal which would otherwise have fallen victim to an unruly parity
bit...... (suffice it to say that I would deem it an honor to allow you to
express your gratitude) The resident part of this code, by the way, uses up a
little over 1K of ram. Most of that space is taken up by routines which save
the current screen, write the error message, and then restore the screen. I
made no particular effort to make that code as compact as possible, so, if space
is at a premium, and/or you like doing such things, please feel free to squeeze
and optimize to your heart's content... As an alternative, if you don't mind
junk on your screen, it would be fairly easy to replace most of the error
message code with a short routine which uses the rom-bios 'write teletype'
function to print a message, but doesn't waste any memory by saving the screen.
It's probably best not to use dos functions here, since a parity error can be
reported at any time, even with interrupts disabled and/or while in the middle
of a dos routine -- and pc/ms-dos is notoriously non-reentrant.