Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site lsuc.UUCP
Path: utzoo!lsuc!jimomura
From: jimomura@lsuc.UUCP (Jim Omura)
Newsgroups: net.micro.68k
Subject: Re: Re: Re: Info on OS9 Operating System
Message-ID: <860@lsuc.UUCP>
Date: Sun, 20-Oct-85 13:35:58 EDT
Article-I.D.: lsuc.860
Posted: Sun Oct 20 13:35:58 1985
Date-Received: Sun, 20-Oct-85 13:59:49 EDT
References: <347@wlbr.UUCP> <9500001@datacube.UUCP> <126@mcrware.UUCP> <837@lsuc.UUCP> <379@wlbr.UUCP>
Reply-To: jimomura@lsuc.UUCP (Jim Omura)
Organization: Barrister & Solicitor, Toronto
Lines: 37
Summary: CRC

In article <379@wlbr.UUCP> steve@wlbr.UUCP (Steve Childress) writes:
>
>I say it was a mistake because disk files themselves have error checking.
>
>When I NOP'd the call to CRC check LOAD'ed modules I noted a large speed-up
>in hard disk systems. I sent the patches for the APPLE, CoCo, and SS50
>OS9 level I's to '68 Micro Journal (magazine) to publish for the users
>but they never printed..
>
>		Regards,
>			Steve Childress
>			Eaton IMS    R&D Group MS 43 
>			31717 La Tienda Drive
>			Westlake Village,  CA    91360
>			{trwrb, scgvaxd, ihnp4, voder, vortex} !wlbr!steve
>		        or	 		        ...wlbr!wlbreng1!steve


     Uh.  mmmm.  Steve, what error checking?  At write time?  Doesn't
catch everything.  I've had corrupted files.  At read all it does is
say that it seems to have gotten what seems to have been written.
Part of the problem is boarderline latency.  A write may verify at
the time it's done, but later, the magnetic pattern may not be as
clear.  Also, poor storage techniques of magnetic environmental
'noise' can cause this.

     I'd keep the CRC if I were you.  Especially for executable binary
files.

                                   Cheers! -- Jim O.

-- 
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
Compuserve: 72205,541
MTS at WU: GKL6