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

[Al Mac <macwheel99@xxxxxxxxxxx>]

I not have as much experience as you but the ONLY time I have seen messages 
about "data corruption" on the 400 it was because

* Our UPS battery needed to be replaced and we did not know it, so when 
there were power outages, the 400 went down hard, and what got corrupted 
was the INDEX to the BPCS item master file ... the data was there, the 
index had to be rebuilt.

* We had a used hard drive that was 13 years old and IBM mean time to 
failure was 13 years ... I was telling my bosses that this meant IBM's 
expectation of life span & we need to replace this real soon.  I was told 
that I had fallen for marketing BS, that "mean" meant ON THE AVERAGE they 
expect something, but IBM makes great products, and tend to be conservative 
about such estimates.  Well it was 13 years old when it died.  I believe 
the IBM mean-time-to-failure, even if no one else does, and I agree "mean" 
in arithmetical terms is an average, but I did not believe that was how IBM 
was using the terminology.

If something serious happens, I would expect to find it in
DSPMSG QSYSMSG (that is assuming you created that message queue, which is 
optional)  All that's in ours right now is a log of power outages.

Last time I did a backup, I got an error message CPI1466 about 30,000 locks 
being suspicious for  job 634006/QSYSOPR/QEZBKTMSAT, but it backed up BPCS 
Ok..  Actually I thought the message was suspicious because 30,000 seemed 
to me to be a small number.  In theory nothing else was running on the 
system while this was going.  In practice, I signed off for an hour then 
checked back to see if it got done Ok.

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