× 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 4/19/11 5:19 PM, James Lampert wrote:
Anybody ever see this before?

We got a distress call from a customer who'd had a power failure, and
an application that wouldn't come up.

I looked into it, and found that the keyed access path of a crucial
file was being blocked from being reconstructed, because somehow, the
power failure had caused duplicate records to appear in it.


I would suggest reviewing the history log, at least for CPF3100 range of MSGID for anything about that LF besides the condition of "could not be built". I recall such symptoms for some defect conditions or as a legitimate effect of main storage lost [in this case for lack or failure of UPS] without SMAPP or journaling having been enabled to prevent the loss for the data and\or access path.

Explicit STRJRNAP or [more aggressive?] SMAPP would probably prevent the condition, even if origin by defect.

Another scenario might arise instead from the application opening the PF for update while the LF access path was invalid\non-enforce [i.e. the LF being blocked from re-create due to the duplicate key values], and that the application added [by insert or update] the duplicates. If the AccPth was not valid during the open of the PFM, then the open should have signaled the access-path rebuild event [to the QDBSRV01 job] to request the immediate rebuild be scheduled in the QDBSRV## low-priority jobs and to become visible on EDTRBDAP if not already. I do not recall what effects invalid\non-enforce versus invalid\enforce for a UNIQUE defined key. I doubt that is only used for physical keys or constraints; I recall every normal scenario was supposed to ensure invalid w/ enforce, specifically to prevent this scenario. As I recall, the open of the PFM should always fail with CPF5090 when any invalid UNIQUE keyed LF exists over the data. The CPF5090 is the message sent when\after the rebuild request is signaled. If there is a normal condition for invalid\non-enforce, that problem should be prevented again either by explicit STRJRNAP, [more aggressive?] SMAPP, or ensuring after an abnormal termination that the access paths are rebuilt before I/O. The application [or instead a pre-requisite operation to the application] can do that itself, by opening the LFM using the key [open with keyed access] before opening another path to the PFM data. There are also the RECOVERY [with appropriate MAINT] parameter specifications on the CRTLF and CHGLF to move the access path recovery to the *IPL versus *AFTIPL [or *NO]; IIRC the start of rebuild processing is completed in IPL for the former, but IPL continues after all remaining work is offloaded to the database rebuild server jobs even though rebuilds continue... though the RECOVER parameter help text I believe suggests access path rebuild completion.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.