Re: RSTOBJ then CPYF CPF5090

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.