Re: RSTOBJ then CPYF CPF5090

CRPence wrote:

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.

Yes. All of them that involve physical/logical files, so far. We have worked a couple of methods to get around it -- neither of them feels wholly satisfactory. I wouldn't normally bring it up in a thread such as this one except that it intersected with the OP issue.

It also has a minor secondary element that touches on another thread. The extra work that is needed to "install a product" on some unknown system with unknown system values and unknown PTFs and unknown lots of other things, there are elements that can be as challenging as creating a "product" in the first place. SAVLICPGM/RSTLICPGM is an area that's pretty shrouded in mystery for those who never worked inside IBM. Maybe someone else will find some interest in simply reading this.

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].

I'd like to believe that, but there is no visibility (for us.) Since the actual saves and restores are buried inside of SAVLICPGM and RSTLICPGM, we have no way of knowing what parameters are involved except by noting the symptoms.

Normally, ALWOBJDIF(*ALL) _cannot_ be specified when also specifying MBROPT(*MATCH). Since MBROPT(*MATCH) is the default for RSTOBJ and there is no direct way to affect it via RSTLICPGM, there is no direct way to get ALWOBJDIF(*ALL). So, it must be done indirectly via exit programming.

At least, so far.

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.

Yes, it is only a "small matter of programming (SMOP)"... :-)

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.

QSAVACCPTH is "1"=Save. Good point, though.

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.

Exit programming has been very important. Depending on some specific circumstances, we either move files to a temporary library or rename members. The post-restore exits handle any data migration, etc., and do the cleanup.

Migration of data from the previous VRM can be absolutely critical for products. Updating configuration files can also be critical. These steps possibly should have menu options or commands that can be run after the "install" finishes. There are times when that's not totally feasible.

When such things must be done before RSTLICPGM returns back to the command line, that's when it gets important to have the access paths fully available for use. A given product might restore a large number of objects, including a boatload of indexed files. Particularly on smaller/slower systems, it can take a long time before everything has settled. Fortunately, OPNDBF/CLOF can be a normally quick way to get to the particular files that might be needed.

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.

Been there, done that. Have scars to show.

I'd love to know what a "properly designed & coded LPP restore" looks like. As mentioned, we have a couple techniques that /work/ for access paths, but that's hardly like saying they're "properly designed & coded".

To me, it just seems that there are too many hoops to jump through. And even that wouldn't be so bad except it mostly has to be done blind-folded.

Granted, there is a lot of 'Software Product' documentation. It just isn't always useful when trying to feel your way through to "properly designed & coded". For example, it's clear that you can have multiple exit programs for each exit point; but it's not clear at all that only the _first_ one gets called. It'll be a while before I forget the restructuring I had to do when that "Duh!" moment dawned on me. And then there's the fact that _only_ exit *PGMs are restore at the pre-restore points -- no *MSGFs, no DSPFs, just the *PGMs. That can really wreak havoc on trying to work out any kind of 'generic' install programming -- hard-code _everything_.

Enough. I can see this will turn into a longer rant if I don't stop.

Anyway, if tips are available, I'll sure appreciate them. I'm sure any other ISV will, too; and maybe that will even lead to a little higher customer satisfaction.

Tom Liotta