Re: Access path rebuild trouble -- CPF5090 in a CL program

On 10/29/13 3:40 PM, James H. H. Lampert wrote:

I've got a problem with a CL program that's restoring a logical
saved from a generic library into a library that might have an
out-of-date version of that logical, then adding records to the
underlying physical.

It's throwing a CPF5090, because it's updating the PF before the
access path in the LF is ready.

How do I get it to either (1) rebuild the access path explicitly
and synchronously,

1a) Open the Logical Database File Member that defines the Unique keyed Access Path, using a keyed access method; e.g. Open Database File (OPNDBF) using ACCPTH(*FILE)

1b) CRTLF from DDS source, or use CREATE UNIQUE /* WHERE NOT NULL
*/ INDEX on the physical instead of restoring.

1c) RGZPFM ALWCANCEL(*NO) the physical database file member using *YES on the Rebuild access paths (RBDACCPTH) parameter; as I recall, the LFM can *not* be specified as the KEYFILE(), because the same effective condition diagnosed by CPF5090.

1d) Perhaps allowed?: CHGLF of the Unique keyed LF, specifying *YES for the Force rebuild of access path (FRCRBDAP) parameter.

1e) RSTOBJ using the FILEMBR((*ALL *NONE)) and then implement the addition of the Logical File Member using ADDLFM.

1f) Implement the create of the LF using CRTDUPOBJ, instead of directly restoring the Unique keyed LF over the existing data.

or (2) wait for the access path to be rebuilt
asynchronously before executing the next statement?

2) There is since some /newer/ release, a database file used by the /Navigator/ feature, to tracked access path rebuilds. That file may be able to be queried for a record matching the keyed LF awaiting rebuild, but I have never looked into the implementation; I am unaware of any API to that feature, however.