|
|
|
The fixed link pack area (FLPA) stores programs or routines that benefit from not being paged. Because modules in the FLPA can be quickly accessed when needed, it is common for data centers to place other modules in the FLPA for system performance and tuning purposes.
Modules in the modified link pack area (MLPA) generally temporarily add or replace SVC routines and test replacement PLPA modules that an IBM program temporary fix (PTF) modified. The MLPA acts as an extension to the PLPA, but is not saved from one IPL to another as the PLPA is.
Programs in the FLPA and MLPA are selected from system or user libraries and are accessible by all tasks on the system concurrently; although reentrancy is not enforced if the NOPROT parameter of the IEASYSxx members named IEAFIXxx or IEALPAxx, which can override this reentrancy restriction, is specified.
Once resident in the system, z/OS considers programs in PLPA, MLPA, and FLPA to be APF-authorized, even though the programs can originate in non-APF libraries before they become resident in system storage.
The system builds FLPA before it builds MLPA. If a module resides in FLPA, it cannot also become resident in MLPA. Therefore, if an identical module name is specified in both IEAFIXxx and IEALPAxx, only the FLPA version is resident and available for processing.
The MLPA, FLPA, PLPA Analysis option shows you the names of all MLPA and FLPA modules and their aliases, where they reside, and comments about the modules. CA Auditor obtains the information for this display from the active link pack area queue (ALPAQ).
To use this function
The z/OS Technical Information screen is displayed.
The modules that reside in the FLPA and MLPA are displayed.
The detailed information screen is displayed.
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |