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