Re: RSTOBJ then CPYF CPF5090

[CRPence <CRPbottle@xxxxxxxxx>]

  I think it would be best to try to determine why the access paths 
rebuild and make the rebuilds become an unexpected outcome.  Polling for 
the condition of validity diagnosed either by failure of CPYF or by 
QUSRMBRD should not be generally necessary; nor is it desirable.  This 
is because given a simple save/restore scenario, it is probable there is 
a way to get the access paths to save and restore versus rebuild; that 
is the normal behavior, where no special conditions nor defects exist. 
An attempt to allocate the physical to prevent the accpth rebuilds is 
not generally possible unless the file exists before the restore; 
normally the library would be locked to effect that, but IIRC the QTEMP 
can not be locked.

  However stating that a "RSTOBJ physical and logical files from a save 
file" is somewhat limited in defining what is really done.  Not knowing 
most of the process and the definitions of the files\keys prohibits 
giving a /good/ response to the problem scenario.  Although there is 
mention of QTEMP, there is no explicit mention if the library is empty 
before the restore, nor that exactly one RSTOBJ is issued versus 
possibly one for each or...  Words versus scripted actions do not do 
well to define the problem clearly.

  The scenario of one versus three accpth rebuilds may be explained by 
one of the three not having been built at the time of the save, taken 
since the prior restore.  In fact if the save had ever taken place 
immediately after the failed copy, that save may even include an invalid 
unique access path.  Unique or not, invalid access paths are not saved, 
and thus must be rebuilt upon restore.  If this is the origin, the 
QUSRMBRD before the save is a better place, but if the CPYF works, it 
can be inferred that at least the unique access path is valid.

  For not knowing the files and keys, I can only offer that possibly if 
the unique could be moved to the physical, at least the CPF5090 would 
never be an issue [except as defect].

  Is it ever true that the FROMMBR of the FROMFILE will ever be empty, 
or that any selection on the CPYF might effect an empty result for copy? 
 If so I believe the CPYF may not even open the target TOMBR and thus a 
completion message would allow flowing in the CLP directly to the later 
save, increasing the opportunity to save while invalid; i.e. save 
without any access paths that were invalid due to the earlier restore.

  An inline request to RGZPFM [with exclusive with rebuild] of the PF 
member which has the unique LF access path defined can ensure valid 
access paths for the SAVOBJ that follows.

Regards, Chuck

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...  I 
> understand this is because the access paths are still being rebuilt 
> and I have seen someone else post about this with no "good" answer. I
> can see the 3 messages about access paths rebuilt for the 3 logicals
> doing the DSPLOG and see some after the CPYF's.  The one blowing up 
> took 34 seconds even though there was just one record.

> The last part of the program resaves those files back to the save
> file for recycling errors such as bad part numbers.  I am trying to
> debug this and try looking for locks.  So, I RSTOBJ to QTEMP like the
> job and I only see one access path rebuilt message for just one
> logical doing the DSPLOG and it was lightning quick. This has been
> happening sporadically but always first thing in the morning even
> though it runs throughout the day.  This happened two days in a row.
> This makes it seem like rebuilding the access paths then resaving
> makes things happy until the next day.  It's almost like there is
> caching going on. Monitoring and retrying should be easy.  I would
> just like to stop the long waiting if possible. My main question is:
> Why would it rebuild 3 access paths for a long time then after
> resaving and restoring, only rebuilding one quickly?
>
> As far as options for delaying and retyring if anyone is interested, 
> I have the following which should work:

> 1. MONMSG(CPF2972) the CPYF's then DLYJOB(3) in a loop 20 times.

> 2. Write an RPG program before the CPYF's looping on QUSRMBRD and 
> checking the access path validity and state.

> 3. ALCOBJ *EXCL on the physical.

> Obviously, I don't know if this would work or if there are locks 
> because I cannot debug.  If I knew this would work, this would be #1.
>
>
> Any thoughts?