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



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

craigs@xxxxxxxxx wrote:
I know when I RSTOBJ physical and logical files from a save file to QTEMP, the QDBSRVxx jobs kick off to rebuild access paths.

The next statement is CPYF with *ADD to QTEMP and blows with a CPF5090 - Unique access path problems prevent updates... I understand this is because the access paths are still being rebuilt and I have seen someone else post about this with no "good" answer. I
can see the 3 messages about access paths rebuilt for the 3 logicals
doing the DSPLOG and see some after the CPYF's. The one blowing up took 34 seconds even though there was just one record.

The last part of the program resaves those files back to the save
file for recycling errors such as bad part numbers. I am trying to
debug this and try looking for locks. So, I RSTOBJ to QTEMP like the
job and I only see one access path rebuilt message for just one
logical doing the DSPLOG and it was lightning quick. This has been
happening sporadically but always first thing in the morning even
though it runs throughout the day. This happened two days in a row.
This makes it seem like rebuilding the access paths then resaving
makes things happy until the next day. It's almost like there is
caching going on. Monitoring and retrying should be easy. I would
just like to stop the long waiting if possible. My main question is:
Why would it rebuild 3 access paths for a long time then after
resaving and restoring, only rebuilding one quickly?

As far as options for delaying and retyring if anyone is interested, I have the following which should work:

1. MONMSG(CPF2972) the CPYF's then DLYJOB(3) in a loop 20 times.

2. Write an RPG program before the CPYF's looping on QUSRMBRD and checking the access path validity and state.

3. ALCOBJ *EXCL on the physical.

Obviously, I don't know if this would work or if there are locks because I cannot debug. If I knew this would work, this would be #1.


Any thoughts?

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.