Is there a specific scenario of SAVLICPGM/RSTLICPGM pairing that is
exhibiting rebuilds? If so, maybe we could review that over email, and
post what we find afterward. Most difficulties with database files and
LPPs are not with access paths, but instead with maintenance activity;
both release upgrades, reinstalls, and PTFs.
The saving and restoring of licensed program products should be
pretty much the same as for savobj and rstobj alwobjdif(*all). Those
commands are what the LPP save & restore commands use [for /qsys.lib
objects].
So basically it is a matter of ensuring that SAVOBJ and RSTOBJ of the
DBF networks [e.g. saved by OBJ(*ALL) OBJTYPE(*FILE) from the LPP
library] can be performed without access path rebuilds, during testing
which mimics both the slip-install of the LPP and the scratch-install of
the LPP. After the restore, verify by DSPFD that there are no /invalid/
access paths, and that DSPLOG QHST MSGID(CPF3100) since the start of the
restore does not have any CPF3145 or CPF3146; and review any others...
those two messages used to be the only two of interest, but I am not
sure nowadays. This testing can be done with the SAVLICPGM & RSTLICPGM
instead of SAVOBJ & RSTOBJ, perhaps only after working past any issues
using SAVOBJ\RSTOBJ requests since that can be limited to testing with
only the database files in the option.
There are a couple concerns for possible differences from SAVOBJ and
RSTOBJ however. First, there is no ACCPTH() parameter on SAVLICPGM. I
do not recall what it uses [though I believe ACCPTH(*YES)], and there is
no doc on the command [reader comment time?]. You would need to confirm
that the SAVLICPGM request explicitly always does ACCPTH(*YES) rather
than defaulting to *SYSVAL, and if the latter, always be sure to set the
system value before any SAVLICPGM request. Second, there is the
possibility of exit programs during RSTLICPGM doing any sorts of things
that could make the /restore/ do something way different than just a
RSTOBJ, in either of the two standard scenarios: restore-over and
scratch-restore of the objects in the LPP. Typically the pre-MRx
restore effects the DLTF of the existing files, so that all restores of
database *FILE will appear\function as a scratch restore; or where those
objects also need to maintain private authorities, then RNMOBJ effected
in pre-MRx restore and then GRTOBJAUT REFOBJ() in the post-MRx restore.
Note: A scratch install of the LPP means that the LPP does not exist
when RSTLICPGM is performed; no relationship, necessarily, to an OS
scratch install. I add this note because of the numerous times that the
terminology has been misunderstood. Similarly when I say scratch
restore, that has nothing to do with either scratch install, it refers
to any restore where the object from media does not currently exist on
the disk; such that the private authorities are also not restored
[regardless that 6.1 changes the capabilities on that front, but not for
xxxLICPGM].
Note: The alwobjdif should have since been changed in RSTLICPGM to
name each allowed difference [i.e. name each special value separately,
versus the single value *ALL], and then updated each release where
another special value is added. However the parameter value almost
surely remains *ALL, which is the worst option for database files. An
improperly designed & coded LPP restore will often manifest increasing
members and file objects as a result of cpi320a and cpi320b.
Regards, Chuck
Tom Liotta wrote:
CRPence wrote:
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.
Chuck:
When the save is via SAVLICPGM and the restore is via RSTLICPGM, can you
suggest a good way of "...ensuring that the saving and restoring of the
access paths is the outcome as a normal course"?
Tom Liotta
midrange.com
