× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.