Re: Access Path questions

On 24-Mar-2016 09:31 -0600, Mark S Waterbury wrote:

On 3/24/2016 11:08 AM, Steinmetz, Paul wrote:

I'm saving access paths.
I'm restoring PF and LF to a different LPAR, RSTLIBBRM.
In the joblog, states access path restored, CPF3292.
In the HST log, I see a message that the access path is rebuilt,
CPF3145.
1) Why is this occurring?
2) Not occurring for all access paths, only some, why?

CPF3292 Information 10 03/23/16 00:31:06.684098
QDBRSPST QSYS 0818
QDBRSPST QSYS 0818
Message . . . . : File CBBXCPL2 in library CABLEFILES restored.
Cause . . . . . : File CBBXCPL2 in library CABLEFILES was restored
with 1 members added, 0 members replaced, 0 members not changed,
and 0 members damaged.


Message ID . . . . . . : CPF3145 Severity . . . . . . . : 00
Message type . . . . . : Information
Date sent . . . . . . : 03/23/16 Time sent . . . . . . : 00:31:08
Message . . . . : Access path built for member CBBXCPL2 file
CBBXCPL2 library CABLEFILES in 00:00:01.
Cause . . . . . : The access path was built for member CBBXCPL2
file CBBXCPL2 in library CABLEFILES in 00:00:01
(hours,minutes,seconds).

There are several situations or circumstances where SAVOBJ or SAVLIB
do not save the access path, and so it must be rebuilt upon restore.

Prompt the SAVOBJ or SAVLIB command (you did not say which one you
used), and press F10=Additional parameters, then page down until you
see:

Save access paths . . . . . . . _*SYSVAL_ *SYSVAL, *NO, *YES

Put the cursor in that input field and press F1=Help, then press
F20=Enlarge, and read all of the help text for this parameter.

The late Al Barsa Jr. used to like to say that this parameter should
have been:

Save access paths . . . . . . . _*SYSVAL_ *SYSVAL, *NO, *MAYBE

Hope that helps,

The Access Paths are not saved only when one of the following is true:
• The (dataspace of the) member being saved is empty
• The Access Path is /damaged/; noting, IIRC, that either of member or dataspace damage would prevent the save of the member, but AccPth damage can be ignored because the restore will effect the rebuild
• The resolved-to or explicitly specified special value is *NO

The definition of *YES for the ACCPTH() parameter was vitiated when a change was made to no longer save /empty/ access paths; i.e. *YES was no longer meaning Yes, and henceforth meant Yes-when-not-empty :-( The change was made to minimize the amount of objects required to be saved on a save\LD-descriptor with a positive side-effect on the performance [and likely infinitesimal storage savings] for the save, but with the negative side-effect of [and I believe synchronous vs asynchronous] access-path-rebuilds upon restore.

The more important (and likely relevant) perspective is the restore activity [rather than the save activity]; i.e. likely the OP is already aware that *YES was specified or that was the resolved-to setting for ACCPTH(), but either there was no saved access path to restore [see above bullet-list], the owning logical member (of the access path) was not both saved and restored in the same save\restore requests as the physical data member(s), or the access path [level] identifier did not match that of the existing access path when the restore was a restore-over [vs a scratch restore of the objects].