×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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).
midrange.com
