🚀 go-pugleaf

Victor, the FixTool does the checking for you, honest.

You have 2 possible failure scenarios, one for the first unpack, either
the DSK image or the ZIP, and that is done buy the LOADDSKF or xxxZIP
program. They will catch a corrupted ZIP in thier control areas.

Next, the FixTool itself, as all FP's have CRC's (no, not the normal
ones you find around) for every file in a FP file. When installing, and
after unpacking, each and every file gets checked before trying to lay
it down. Well, this isn't entirely true, you must have FixTool 1.40 or
later, as it wasn't in earlier versions.

Irv

"Victor Bien delete nspam. to reply" wrote:
> 
>   A few weeks ago I asked this group whether for me any FP > 9 were
> any good.  One observation made by Jim L <lifedata@xxvol.com> in the
> discussion was that some hardware responds badly to certain FPs.
> While this may be true I am now wondering whether some problems that
> people, including I, have encounterd are due to slightly corrupt
> downloads or at least slightly corrupt files?  These downloads may not
> only be done by oneself but by a colleague and passed on via CD-ROM.
> 
>   The reason for my suspicion is that, for example, the XR_M010.ddk
> obtained by CD-ROM unpacked with "no errors" by DIUNPACK nevertheless
> did not produce a CMD.EX_ file.  When Service & Fservice ran it fell
> over when it could not install this file.  I had to break off and
> download a fresh copy of FP10 from Hobbes and after doing another
> DIUNPACK on the fresh XR_M010.ddk would the application of service
> complete.  (Incidentally FP10 applied OK and so far it looks good.  So
> I've been able to move on from FP9!  I intend to observe the system
> under use for while and move onto the following FPs one step at a time
> hoping to reach FP14 with its new kernel!).
> 
>   Another example of a faulty download appeared in a 3MB installation
> file for the Windows environment.  This fell over when I tried to run
> it.  I downloaded another copy and everything went fine.  The
> interesting thing was that the byte count of the two copies were
> exactly the same.  However, running COMP on the files showed more than
> 10 bytes different when COMP exited saying there were too many
> differences!
> 
>   We are in a period of maximum sunspot activity perhaps with more
> incident cosmic rays capable of flipping bits.  The above mentioned
> Windows file installed OK when first downloaded a couple of weeks ago.
> So maybe the download was OK and then became "faulty".  There are no
> viruses on this OS/2 machine and in any case there are very few
> viruses against OS/2 anyway.
> 
>   So I'm wondering whether IBM could supply a CRC list with a tool to
> check the diskimage files CRC against?
> 
> Victor Bien
> VCB Computing Alternatives (R)
> http://sydney.dialix.com.au/~vcbien/