Re: Damaged IBM Cross Reference Files

[CRPence <CRPbottle@xxxxxxxxx>]

  I prefer not to use the term "damaged" except to denote what the 
OS classifies as "damage"; although a database message may allude to 
actual damage as an origin, it should only be in a list of more 
likely causes.  Most likely there is a software defect, possibly in 
timing, for which the QDBSRVXR job is [incorrectly] detecting an 
inconsistency with the data it tracks, and records that condition as 
an error.

  The origins of the problems with the *DBXREF data are mostly 
historical, being encountered presently.  The current error is 
likely a response to an error flag denoting a prior detected 
inconsistency for which the current operation is prohibited, or the 
current error is an error logged to the history and *sysopr to 
diagnose the detected inconsistency.  Only for the former would one 
have "had to run" the reclaim of the *DBXREF, and for the latter one 
could run indefinitely if no operation were performed for which the 
data in the *DBXREF must be accurate.  The errors are most likely 
going to have been manifest as some condition in a joblog, which are 
rarely saved, which is problematic for determining origin.  There is 
a /flight recorder/ however for which narrowing by object names and 
times might assist.  The history is scrubbed for a variety of 
CP_32## messages [and a couple others] to track incidents that may 
have been logged; many may be mostly informational having been 
logged only to QHST while others truly diagnostic having been logged 
to QSYSOPR but most often ignored since almost nobody had an actual 
operator nor are the messages alerted.

  Since some release the tracking of the accuracy of the *DBXREF 
data was pushed down to the library-level versus the entire system; 
i.e. "the system" as the database concept was not conducive to 
tracking all consistency issues, due to the impact.  Along with that 
change there was a limited function API delivered to limit reclaim 
activity to the specific library going in errors.  A later release 
added the features of the API to a new command RCLDBXREF which has a 
parameter option which will log the library name(s) where a data 
inconsistency was detected specific to that library; some conditions 
remain for which a specific can not be known, and the entire cross 
reference [to a specific class of data; files, triggers, relations, 
constraints, etc.] must be marked as in error, generally, across the 
ASP - since "the database" became "the iASP" versus "the system".

Regards, Chuck

Ketzes, Larry wrote:
> He is doing a lot with SQL tables.  I wish I could isolate what 
> exactly is the cause, and proactively put some type of 'Best 
> Practice' in.  that is assuming he is doing something SQL wise 
> that is not 'Best Practice'.
>
> I'll probably open a ticket with IBM.  Maybe a trace will show 
> something.
>
> Alan Campin wrote:
> > Had it happen once. He must be doing SQL tables or stuff with 
> > Referential Integrity. That is what caused mine.
> >
> > On Wed, Jul 15, 2009 at 9:48 AM, Chris Bipes wrote:
> >
> > > I have never had to run this.  I have been using the iSeries 
> > > since a B10 in 1988.  I am now managing 5 system all at V5R3.
> > >  I have 2 170's. an 820, and 2 520's.  What are you running
> > > on your system that is causing this to happen?
> > >
> > > Ketzes, Larry wrote:
> > > > Does anyone on this list have a problem with their IBM
> > > > Cross Reference Files getting corrupted on a kind of
> > > > regular basis? I know how to fix them, but was curious to
> > > > see if anyone else had to run the RCLSTG SELECT(*DBXREF)
> > > > more than a couple times a year.