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

I don't know about anyone else, but I've rarely seen one of these messages.
In nearly ten years, I never saw one at SSA.  Not to say there haven't been
instances, but "constant database corruption"?  Hardly.  Of course, that's
not on an i5.  You seem to be implying that you're seeing a lot more CPF3285
messages on your i5.  In my opinion, if you've seen more than one or two of
these messages, then you have a serious problem.

I'd like to know who at IBM told you that "that's what backups are for".  I
doubt it was somebody from the DB2/400 team.  DB2/400 is rock solid, and if
whatever you're doing is corrupting data, then someone needs to know about
it.  And soon.

Joe


> From: rob@xxxxxxxxx
> 
> 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.