🚀 go-pugleaf

In article <3a3e9c3c_3@news1.prserv.net>,
nospam.vbien@attglobal.net  (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.

<SNIP>

>  So I'm wondering whether IBM could supply a CRC list with a tool to
>check the diskimage files CRC against?

If you download the ZIP files for the RSU install and UNZIP them,
UNZIP will do CRC checking.

Have a look at:

http://www.warpdoctor.org/lib/ez/fp/zipchoice.html



--
**************************************************************
*  Dan Casey                                                 *
*  President                                                 *
*  V.O.I.C.E. (Virtual OS/2 International Consumer Education *
*  http://www.os2voice.org                                   *
*  DCasey on IRC                                             *
*  http://members.home.net/dcasey3                           *
*  Charter Associate member, Team SETI                       *
*  Board member: Warpstock, Inc.                             *
**************************************************************
*  E-Mail (subject: Req. PGP Key) for Public Key             *
**************************************************************

In aus.computers.os2 Victor Bien delete nspam. to reply <nospam.vbien@attglobal.net> wrote:

>   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

I only ever used loaddskf to on the .dsk files from IBM. It does report errors if the image is bad.

If you don't want to use a floppy (real or virtual), why not use the zip files?


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


Stop this mucking about and go straight to 14. You do not need any intermediate fixpacks.

You won't save yourself from anything with your approach; if a particular
fixpack causes your system to fail, the problems of recovering are the same
whether its' FP14 or FP10.




>   We are in a period of maximum sunspot activity perhaps with more
> incident cosmic rays capable of flipping bits.  The above mentioned

More likely, it's the flock of pigs over your head|p-)

> 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?

So ask IBM. md5sum is readily available and effective.

btw zip files are slef-checking too.



-- 

On 18 Dec 2000 23:22:36 GMT, Victor Bien delete nspam. to reply <nospam.vbien@attglobal.net> wrote:
>  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
...
>  So I'm wondering whether IBM could supply a CRC list with a tool to
>check the diskimage files CRC against?

DIUNPAK does not, indeed, perform CRC checking.

For that you need DSKXTRCT, which does.  (It's not written by IBM but it
works with almost all DSK images.)  DSKXTRCT is available here:
http://hobbes.nmsu.edu/pub/os2/system/patches/fixpack/dskxtr12.zip

-- 
--------------------------
Alex Taylor
alex@eddie.cis.uoguelph.ca
--------------------------

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/

Hi,
to my experience, their is another considerable source of problems ->
memory.  Large (>64MB), hispeed memory gives you a considerable risk of
bit errors, specially if memory is driven rather hot. Parity will only
catch One-Bit errors, all other can be seen only be ECC. Some memory
assemblies have no checking at all for a cheaper price. Memory testing
will not show these errors at all, because they occur only randomly. The
typical symptoms are:

- non-reproducable traps
- corrupted files after copying them (!) even if the CRCs of the source
where OK .

My advice:
- parity checked memory is a must,
- run memory stress tests at least before installing new SW,
- use boards and memory with ECC if ever possible if you use more than
128MB. The payback period is very short.

Regards
Uwe

---------------------------
"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/