Re: RSTOBJ then CPYF CPF5090

[CRPence <CRPbottle@xxxxxxxxx>]

  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.