Chuck:
Thank you SO much for all this information. I will digest it and pass it on to my operations people. I believe that we still need to look into this further after reading your post.
Again, thanks!
-Brent
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 15, 2013 5:01 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Unable to create keyed SQL files
On 15 May 2013 13:45, Raymond B. Dunn wrote:
It turned out to be a damaged object.
A logically damaged file might be the effect versus a cause of the errors with the DBXREF. Recovery from logical damage is supposed to [at least used to] explicitly /overlook/ most inconsistencies with the data.
A physically damaged file is at least somewhat likely to give origin, to cause, an inconsistency error with the DBXREF.
I would not be surprised if instead of a specific incident of a damaged object being the cause, the problem was /explained away/ as being caused by a "damaged object", and that explanation was accepted.
We had to execute a reclaim Database Crossreference.
The only recovery is to correct the *DBXREF data, but whether that can be done by RCLDBXREF or RCLSTG may be an issue.
This fixed the problem, if anyone else ever encounters it.
FWiW the "reclaim Database Cross-Reference" is somewhat ambiguous, thus so is saying "This fixed the problem". Either of the commands Reclaim DB Cross-Reference (RCLDBXREF) and Reclaim Storage (RCLSTG), each having variable invocations, are capable of correcting an issue with the *DBXREF data. However each invocation uses different means and refreshes the data to a different degree, to effect a fix to the *DBXREF data.
Be warned however, that a request to reclaim the *DBXREF information runs asynchronous to the requester, so any RCLxxx request that includes the *DBXREF must only be performed to recover data errors with the feature. A RCLxxx request that includes the *DBXREF should not be performed as an attempt to recover a functional error with the system jobs that implement the feature; i.e. if the QDBSRVXR or QDBSRVXR2 system jobs are reporting repeated "help me I can't get up" messages vs simply reporting occasional "I seem to have found inconsistent data"
messages, then always fix the functional problem before trying to ask those jobs to correct their data... which they can not do while they are non-functional.
Evidently, this is an on-going issue. Once we got to the right
person, it was a "Oh yeah that happens, it's fixed by...." response.
As I noted, there is only one recovery [irrespective of the command used to effect that recovery]. Thus that "it's fixed by..." response is always appropriate. But IMO "the right person" would have suggested first to have gathered documentation, or actually done so even if that doc were left on the system, to assist in review of\if a new occurrence of the apparently /same/ incident transpires again [soon].
To say that the receipt of the condition is "on-going" seems to me like a mis-characterization, or at least seems to have a negative implication; as if to say that *DTAARA damage is "on-going" if the response had been to suggest that the error "is fixed by DLTDTAARA" due to that request being the correct and only complete recovery for a damaged data area.
Of course if one never determines the actual origin for the issue, and that error continually recurs due to never having implemented something that prevents the condition [most likely with a preventive PTF], then "on-going" would seem to be an appropriate term to describe the issue. But the noted condition CPD32B0 RC7 should almost never happen on any system, and is, with the exception of origin by CPF32A1, almost always has an origin from a defect [or like with CPF32A1, possibly occur per loss of main storage; e.g. due to a crash with power outage and then loss of protection from a UPS].
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
