Re: RSTOBJ then CPYF CPF5090

Chuck,
Thank you for the response! First, I would like to apologize for any
misunderstanding of my statement about not seeing a "good" answer about a
previous post. I had not realized Rob posted about this shortly before
myself and you already responded to him. Rob and I had been working on
troubleshooting this. At the time, I just saw answers about ways to trap
the CPYF like MONMSG, looping on QUSRMBRD. The one post I saw which was
exactly my situation said they tried a RGZPFM on the file to fix it but
they were looking for a more general method as there were more files.
There was no response. I didn't give many details trying not to waste
people's time expecting no response. I think I should be courteous enough
to give those details now below. I also feel a little embarrassed that I
am not very active on this list and people help me more than I help others.
I'm sure everyone active on this list would say that is what they are here
for and I appreciate that.

Details:
I had decided to see if it happened again this morning and it did. All 4
(yes, 4 not 3) logicals took about 10 seconds (instead of 34 previously) to
have access paths rebuillt. I think I now see a pattern. Whenever the
files are empty, an access path rebuild is submitted. I did a test and
added a record to a physical file and resaved all to my own save file then
restored. All logicals rebuilt except the logical over the physical I
added a record to. Your response below helped me realize what I could do
to "fix" the access paths before saving them. I did a RGZPFM on one of the
empty physical files (11 seconds) then resaved everything from QTEMP and
restored. This time there was no rebuild. The joblog showed one message
about access path restoration on the physical with data. The DSPLOG showed
the rebuilds on the other 2 logicals. The "fixed" access path probably
didn't give messages anywhere since it was "fixed" AND empty?
As far as the practicality of restoring files to QTEMP then copying more
data, I could probably have these files in a permanant library that I
temporarily add to the library list. I'm guessing the person who deisgned
this program still had leftover from when EDI was on a separate system and
was too scared to change.

Here is the current process in the program:
/* Restore the orders that are cycling to QTEMP then copy to */
/* the files received from EDI */
RSTOBJ OBJ(KL850*) SAVLIB(QTEMP) DEV(*SAVF) +
SAVF(*LIBL/KLSAVF) RSTLIB(QTEMP)

CPYF FROMFILE(&EDIWRKLIB/KL850H01) +
TOFILE(QTEMP/KL850H01) MBROPT(*ADD)
MONMSG MSGID(CPC2957)
......
at this point we run some programs and leave any error records for trying
again....
SAVOBJ OBJ(KL850*) LIB(QTEMP) DEV(*SAVF) +
OBJTYPE(*FILE) SAVF(*LIBL/KLSAVF) CLEAR(*ALL)
.......
These files involve 4 physicals and 4 logicals. I think I just need to add
a RGZPFM to each of the 4 physicals right before the SAVOBJ to fix the
access paths of the empty files. Or, better yet in this case, use a
permanent library containing these files and add it temporarily to the
libl. The help on RGZPFM talks about synchronous access path rebuild for
default *YES. I think this means the rebuild occurs within the RGZPFM, not
the QDBSRVxx jobs submitting. Is this right? Do these RGZPFM's make sense
and I shouldn't have to worry about the rebuilds occurring during the
SAVOBJ?
Thank you again for your help!

Craig

--- Chuck wrote:
I think it would be best to try to determine why the access paths rebuild
and make the rebuilds become an unexpected outcome. Polling for the
condition of validity diagnosed either by failure of CPYF or by QUSRMBRD
should not be generally necessary; nor is it desirable. This is because
given a simple save/restore scenario, it is probable there is a way to get
the access paths to save and restore versus rebuild; that is the normal
behavior, where no special conditions nor defects exist. An attempt to
allocate the physical to prevent the accpth rebuilds is not generally
possible unless the file exists before the restore; normally the library
would be locked to effect that, but IIRC the QTEMP can not be locked.

However stating that a "RSTOBJ physical and logical files from a save file"
is somewhat limited in defining what is really done. Not knowing most of
the process and the definitions of the files\keys prohibits giving a /good/
response to the problem scenario. Although there is mention of QTEMP, there
is no explicit mention if the library is empty before the restore, nor that
exactly one RSTOBJ is issued versus possibly one for each or... Words
versus scripted actions do not do well to define the problem clearly.

The scenario of one versus three accpth rebuilds may be explained by one of
the three not having been built at the time of the save, taken since the
prior restore. In fact if the save had ever taken place immediately after
the failed copy, that save may even include an invalid unique access path.
Unique or not, invalid access paths are not saved, and thus must be rebuilt
upon restore. If this is the origin, the QUSRMBRD before the save is a
better place, but if the CPYF works, it can be inferred that at least the
unique access path is valid.

For not knowing the files and keys, I can only offer that possibly if the
unique could be moved to the physical, at least the CPF5090 would never be
an issue [except as defect].

Is it ever true that the FROMMBR of the FROMFILE will ever be empty, or
that any selection on the CPYF might effect an empty result for copy? If so
I believe the CPYF may not even open the target TOMBR and thus a completion
message would allow flowing in the CLP directly to the later save,
increasing the opportunity to save while invalid; i.e. save without any
access paths that were invalid due to the earlier restore.

An inline request to RGZPFM [with exclusive with rebuild] of the PF member
which has the unique LF access path defined can ensure valid access paths
for the SAVOBJ that follows.

Regards, Chuck