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

["Jim Damato" <jdamato@xxxxxxxxxxxxxxxxx>]

Monitoring for CPF3777 is a very bad practice regardless of the cause of
the message.  If GLTRAN weren't backed up for months because of locks
due to predictable, consistent use you'd be in the same boat.  Any time
we get a "partially saved" or "not saved" incident we have to look into
it.  Damaged objects are a problem -- potentially with the OS or with
your operations.  Missing damaged objects for months is just
irresponsible systems administration.

I've never seen constant database corruption, but we have had periods
when some files became damaged week after week.  The backup's job log
messages and QHST allowed us to trace the damage to specific jobs which
were canceled while active, performing long-running access path builds
or SQL.  It usually meant we needed to rewrite online updates as batch
processing, so that we wouldn't take damage when a user dropped his or
her session, or an operator cancels the workstation job for a checkpoint
or cold backup.

I wonder if you could use a similar approach to see how your application
files become damaged and to see whether something you're doing
operationally is horking up LDAP's supporting tables.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, April 11, 2006 10:34 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Constant corruption in DB2-UDB on the i5.

Is it just me or are any of the rest of you getting tired of the
constant 
database corruption occurring in DB2 on the i5?

CPF3285-Damage found on file LDAP_ENTRY in library QUSRDIRDB.
CPF3741-FILE LDAP_ENTRY in QUSRDIRDB not saved.
CPF3771-242 objects saved from QUSRDIRDB. 1 not saved.
CPF3777-171 libraries saved, 1 partially saved, 0 not saved.

CPF3285-Damage found on file GLTRAN in library MGR1499091.
CPF3741-FILE GLTRAN in MGR1499091 not saved.
CPF3771-986 objects saved from MGR1499091. 1 not saved.
CPF3285-Damage found on file QAYPSYSTEM in library QMGTC.
CPF3741-FILE QAYPSYSTEM in QMGTC not saved.
CPF3771-14 objects saved from QMGTC. 1 not saved.
CPF3777-816 libraries saved, 2 partially saved, 0 not saved.

IBM's stock answer is that's what you do backups for.

Sad thing is that when the backup program was written it was common to
get 
CPF3777's because of object locks.  They normally saved ok the next
night 
or so.  So a MONMSG was added for CPF3777.  Thus we haven't backed up 
GLTRAN in a few months.  Got lucky.  Found out that it is a work file.

Rob Berendt