RE: Constant corruption in DB2-UDB on the i5.

["Jones, John \(US\)" <John.Jones@xxxxxxxxxx>]

FAIK, like a basic CHKDSK scan, RCLSTG is really only verifying the
files aren't corrupt from a disk placement & header standpoint (file
allocation table stuff).  It does not actually read every record of
every file to find data stored on marginal/bad disk sectors or
mismatched pointers within the db. 

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, April 11, 2006 12:27 PM
To: Midrange Systems Technical Discussion
Subject: RE: Constant corruption in DB2-UDB on the i5.

I'm sure that IBM did not create message id CPF3285 just for little ol' 
me.

PMR 06414,500
He had me unconfigure and reconfigure LDAP.  Since we really weren't
using it.

I had another PMR opened in Feb 05 regarding DB corruption for
management central pmr 79884,500.  That got closed and reopened as
38427,500.  Still open.

Happens so often for Management Central files that I do a save of those
libraries into a save file in qtemp prior to a full system save to
delete the offending files prior to it hanging up the full system save.
Written up instructions that whoever performs the full system save does
the qtemp save prior.

Nasty thing is that we run a RCLSTG immediately prior to the full system
save and it does nothing with these corrupted files.


Rob Berendt