Re: Damaged IBM Cross Reference Files

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.