Re: CPF5090 - Unique access path problems prevent updates to member ...

[CRPence <CRPbottle@xxxxxxxxx>]

  A thirty second delay for that activity, and for just a couple rows, 
seems a bit extreme.  The even to rebuild goes to QDBSRV01 which passes 
the rebuild work to a runpty-52 QDBSRV## job.  I believe V5R4 added more 
tracking to a database file, but even with that additional work, a half 
minute seems excessive unless the system is very heavily CPU-bound for 
processes with better than runpty-52.

  Is the restore done over existing files, or is it a /scratch restore/ 
of the files?  If the former case, then the files over which the files 
on media are being restored must be a prior restore of those files.

  There was once, a defect where the access path level identifier was 
being corrupted by ALTER, so that restores over even a prior restore of 
the files would exhibit the same access path rebuild.  Even for a 
scratch restore of the files, if the corrective fix for the access path 
level ID is on the target system, the same mismatch can occur requiring 
the rebuild [because the saved level is different than the one created 
and corrected for use by restore].  An attempt at a preventive fix, 
which actually corrects the level at save time, can actually introduce 
the same condition when restoring over an old restore of those files.

  Note: If a member is empty, the ACCPTH(*YES) is actually not being 
honored, and the access path rebuilds should occur inline to the restore 
request.

  Note: ACCPTH(*YES) also does not ensure that the access paths can be 
restored.  Obviously restoring just LFs is an example, because the 
access paths are saved with the PF, not the LFs.  And restoring just the 
PF over an existing file without restoring those same LFs that exist 
already, that will require all of the access paths of non-restored LFs 
to rebuild.  Also if the file that owns the access path for a scratch 
restore is changed due to creation order [to maximize sharing], an 
access path may need to be rebuilt; dspdbr on the PF can show restore 
order as compared to the same request whence the PF was saved.

Regards, Chuck

rob@xxxxxxxxx wrote:
> Have a process which does a SAVOBJ of some physical files and logical 
> files into a savf file.
>  ACCPTH(*SYSVAL) is being used as the default.
>  QSAVACCPTH is set to 1=Save.
>  PF only has a record or two.
> However not until 30+ seconds after the restore do you see items like
> CPF3145 - Access path built for member ...
> This halts attempts to update the file [ed: due to the subject CPF5090]
> prior to all CPF3145 messages needed by that job step.
> Workaround may involve retrieving the member description and ensuring
> that the file is ready that way.
> Process has been around for quite some time.  Just now halting.
> Checked QAUDJRN and that save file is only updated by the programs
> which save with ACCPTH(*SYSVAL).