II14026: PERFORMANCE DEGRADATION AFTER CONVERTING LLA MANAGED PDS TO LLA MANAGED PDSE
Closed as canceled.
Note: The text of this APAR was updated on 04/09/2012 and again on 02/25/2015 to clarify the effect that page fault loading has upon LLA and VLF caching, to provide a better explanation for how the Binder FETCHOPT parameter affects this processing, and to remove incorrect and/or extraneous information. This update supersedes and corrects the related discussion in Redbook SG24-6106, the Partitioned Data Set Extended Usage Guide, which contained information based upon the original text in this APAR. ****************************************************** Some customers have reported higher I/O rates or performance issues after migrating modules from a PDS to a PDSE, because the modules were no longer being cached in VLF by LLA even though the PDSE library was LLA managed. It was determined that the reason that the PDSE program objects (modules) were not cached was that the use of page fault loading caused LLA to decide that they were not good candidates for the VLF cache. - Page fault loading is a method chosen by the Loader for large modules, where only part of the program is loaded into storage initially and the rest is brought in as needed via paging operations. Since only part of the program is loaded into storage initially, LLA's staging algorithm may decide that the program would not benefit from being cached in VLF. Avoiding page fault loading will help LLA to make the best decision about whether a module should be cached in VLF. - The Loader selects which loading method to use based upon the the characteristics of the program object to be loaded. Page fault mode may be chosen by the Loader for large program objects when *none* of the following conditions exist: . the program object is to be fetched from the LNKLST . the program object is to be fetched from an HFS . the program object is to be loaded to Global (common storage) . the program object is to be loaded to a user-supplied address . the program object is less than 96k in size . the program object was bound with FETCHOPT=(NOPACK,PRIME) or FETCHOPT=(PACK,PRIME) - Binder option FETCHOPT=(NOPACK,PRIME) causes the Loader to bring the entire module into storage immediately, and is a recommended way of ensuring that the program is not loaded in page fault mode if none of the other conditions listed above are fulfilled. This option does not guarantee that a program will be cached in VLF. It only helps LLA to make the best determination as to whether caching the program object in VLF is appropriate. Binder option FETCHOPT=(PACK,PRIME) also will ensure that page fault loading is not used, but NOPACK should provide better performance when PACK is not otherwise required. - The CSVLLIX1 and CSVLLIX2 exits can be used to tell LLA to cache individual modules or modules from specific libraries. - Note that when a program object resides in a library that is not LLA managed, the default Binder option of FETCHOPT=(NOPACK,NOPRIME) may provide better performance.
Reported component name
V2 LIB INFO ITE
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Applicable component levels
More support for:
Software version: 001
Operating system(s): MVS, OS/390, z/OS
Reference #: II14026
Modified date: 25 February 2015