Access paths are saved with the PF, with the data, not with the LF. When the PF is restored and the LF is not restored at the same time on the same restore request, then the access path of the LF will not be restored. Thus when an\the LF is restored later, for example in a separate RSTLIB request [regardless of from which library it was saved], the access path will be built asynchronous to the restore; i.e. no access path is restored, just the definition of the LF from which the defined index is created. If not planned as part of DR, the creation is done at run priority of 52, which means even compiles and other assorted non-critical /batch/ tasks will take precedence. If planned rebuilds are part of DR, then they would typically be done ordered according to some application priority, and submitted under well-planned work management configurations for perhaps aggressive rebuilds, rather than the defaulted low-impact rebuild activity that is established as part of the QDBSRV## RUNPTY-52 jobs.

Regards, Chuck

rob@xxxxxxxxx wrote:
Are you saying that even if you save access paths when you save LF's
that if the LF is not in the same library when you do a RSTLIB
*NONSYS it will rebuild the access path?

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2020 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].