🚀 go-pugleaf

  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/