The request to OPNDBF ACCPTH(*FILE) on the UNIQUE keyed LFM will
rebuild the access path inline to the job opening the file. As I recall
that is noted in the message CPF5090 as the recovery. The reorganize is
just a very generic way to effect the rebuild [without having to know
nor understand the dependents], but it does so for all of the access
paths for the specified physical member instead of only the unique LFs.
Of course either is acceptable as recovery for small amounts of rows,
but for large number of files or files with many rows, the rebuilds are
best avoided entirely, by ensuring that the saving and restoring of the
access paths is the outcome as a normal course. Request the save,
choose a restore option that enables restoring all access paths, and
then verify none are invalid and none were rebuilt after the restore.
FWiW there is also a somewhat flawed [if abused by poorly programmed
open requests that loop immediately on failure; there is a PRS APAR on
it] yet a somewhat functional side effect of the CPF5090. When that
message is sent from open, there is an event for the access path rebuild
that is signaled each time. The rebuild may be effected in the QDBSRV##
jobs after a short delay, without any explicit action by the opener,
such that another open [after sufficient delay] may then function.
Regards, Chuck
Tom Liotta wrote:
craigs@xxxxxxxxx wrote:
I know when I RSTOBJ physical and logical files from a save file
to QTEMP, the QDBSRVxx jobs kick off to rebuild access paths. The
next statement is CPYF with *ADD to QTEMP and blows with a CPF5090
- Unique access path problems prevent updates...
One minor note to add to any confusion... I've run into _somewhat_
similar problems in certain restore circumstances. A technique that
has worked /in these specific cases/ is to issue OPNDBF followed by
CLOF for the relevant logical files before running CPYF. From other
posts, I'd guess that that replaces RGZPFM.
The result has been /as if/ the request-to-open forces the database
to put resources into settling that particular access path ASAP.
I have a kind of simple utility that 'essentially' uses DSPDBR to
list relations. It then does the OPNDBF/CLOF for each keyed relation.
I don't know how/if this relates to the RGZPFM method, but I wouldn't
learning of differences.
