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