Re: Library Authority

[CRPence <CRPbottle@xxxxxxxxx>]

  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?