FLPA /PLPA /MLP

System libraries for the link pack area (LPA) The LPA is part of an address space's common area storage, and is divided into pageable, fixed, and modified sections: Libraries specified in SYS1.LPALIB, the LPALSTxx, or PROGxx parmlib members are loaded into pageable LPA (PLPA). These libraries contain modules for read-only system programs, along with any read-only reenterable user programs selected by an installation that can be shared among users of the system. IEAFIXxx members specify the modules loaded into fixed LPA (FLPA). This area should be used only for modules that significantly increase performance when they are fixed rather than pageable. The best candidates for the FLPA are modules that are infrequently used, but are needed for fast response. Modules placed in FLPA are always in central storage. IEALPAxx members specify the modules loaded into modified LPA (MLPA). The MLPA is used to contain reenterable routines from APF-authorized libraries that are to be part of the pageable extension to the link pack area during the current IPL. Note that the MLPA exists only for the duration of an IPL.

Link pack area (LPA) modules are loaded in common storage, and shared by all address spaces in the system. Because these modules are reentrant and are not selfmodifying, each can be used by a number of tasks in any number of address spaces at the same time. Modules placed anywhere in the LPA are always in virtual storage. To prevent their pages from being stolen, LPA modules must be referenced very often. When a page in LPA (other than in FLPA) is not continually referenced by multiple address spaces, it tends to be stolen.

LLA / VLF

Authorizing access with the MVS library lookaside (LLA) facility

If you are using the library lookaside (LLA) facility of MVS, you can control a program's ability to use the LLACOPY macro. Authorize the CICS region's userid in one of the following ways: It must have UPDATE authority to the data set that contains the LLA module. It must have UPDATE authority in the FACILITY class to the resource CSVLLA. datasetname, where datasetname is the name of the library that contains the LLA module. For example: RDEFINE FACILITY CSVLLA.datasetname UACC(NONE) NOTIFY PERMIT CSVLLA.datasetname CLASS(FACILITY) ID(....) ACCESS(UPDATE) Modules loaded by CICS from the DFHRPL libraries may be managed by the MVS LLA (library lookaside) facility. LLA is designed to minimize disk I/O by keeping load modules in a VLF (virtual lookaside facility) dataspace and keeping a version of the library directory in its own address space.

LLA manages modules (system or application) whose library names you have put in the appropriate CSVLLA member in SYS1.PARMLIB. There are two optional parameters in this member that affect the management of specified libraries: FREEZE Tells the system always to use the copy of the directory that is maintained in the LLA address space. NOFREEZE Tells the system always to search the directory that resides in DASD storage. However, FREEZE and NOFREEZE are only relevant when LLACOPY is not used. When CICS issues a LOAD and specifies the directory entry (DE), it bypasses the LLA directory processing, but determines from LLA whether the program is already in VLF or must be fetched from DASD. For more information about the FREEZE and NOFREEZE options, see the z/OS MVS Initialization and Tuning Guide. The use of LLA to manage a very busy DFHRPL library can show two distinct benefits: 1. 2. Improved transaction response time Better DASD utilization.

It is possible, as throughput increases, that DASD utilization actually decreases. This is due to LLAs observation of the load activity and its decisions about which modules to stage (keep) in the VLF dataspace. LLA does not automatically stage all members that are fetched. LLA attempts to select those modules whose staging gives the best reductions in response time, contentions, storage cost, and an optional user-defined quantity. In addition to any USER-defined CICS DFHRPL libraries, LLA also manages the system LNKLST. It is likely that staging some modules from the LNKLST could have more effect than staging modules from the CICS libraries. LLA makes decisions on what is staged to VLF only after observing the fetch activity in the system for a certain period. For this reason it is possible to see I/O against a program library even when it is managed by LLA. Another contributing factor for continued I/O is the system becoming "MAXVIRT constrained", that is, the sum of bytes from the working set of modules is greater than the MAXVIRT parameter for the LLA class of VLF objects. You can increase this value by changing it in the COFVLF member in SYS1.PARMLIB. A value too small can cause excessive movement of that VLF object class; a value too large can cause excessive paging; both may increase the DASD activity significantly. See the z/OS MVS Initialization and Tuning Guide manual for information on LLA and VLF parameters. Effects of LLACOPY CICS can use one of two methods for locating modules in the DFHRPL concatenation. Either a build linklist (BLDL) macro or a LLACOPY macro is issued to return the directory information to pass to the load request. Which macro is issued is dependant upon the LLACOPY system initialization parameter and the reason for the locate of the module. The LLACOPY macro is used to update the LLA-managed directory entry for a module or a list of modules. If a module which is LLA managed has an LLACOPY issued against it, it results in a BLDL with physical I/O against the DCB specified. If the directory information does not match that which is stored within LLA, the LLA tables are then updated, keeping both subsystems synchronized. While this activity

takes place an ENQ for the resource SYSZLLA1.update is held. This is then unavailable to any other LLACOPY request on the same MVS system and therefore another LLACOPY request is delayed until the ENQ is released. The BLDL macro also returns the directory information. When a BLDL is issued against an LLA managed module, the information returned will be from the LLA copy of the directory, if one exists. It will not necessarily result in physical I/O to the data set and may therefore be out of step with the actual data set. BLDL does not require the SYSZLLA1.update ENQ and is therefore less prone to being delayed by BLDLs on the same MVS system. Note that it is not advisable to use a NOCONNECT option when invoking the BLDL macro because the DFHRPL concatenated data set may contain partitioned data set extended (PDSE) data sets. PDSE can contain more function than PDS, but CICS may not recognise some of this function. PDSE also use more virtual storage . ### The SIT Parameter LLACOPY # If you code LLACOPY=YES, the default, CICS issues a LLACOPY macro each #time a module is located from the RPL data set. This is done either on the #first ACQUIRE or on any subsequent NEWCOPY or PHASEIN requests. This ensures #that CICS always obtains the latest copy of any LLA-managed modules. There #is a small chance of delay because of a failure to obtain an ENQ while another #LLACOPY completes and there is some extra pathlength involved in maintaining #the LLA tables. # If you code LLACOPY=NO, CICS never issues an LLACOPY macro. Instead, each #time the RPL data set is searched for a module, a BLDL is issued. # If #you code LLACOPY=NEWCOPY, CICS issues the LLACOPY macro when loading a module #as a result of a NEWCOPY or PHASEIN request. A BLDL macro is issued at all #other times. This could mean an out of date version of a module is loaded #upon its first use, but the latest version would be used after a NEWCOPY or #PHASEIN. # For more information about the LLACOPY system initialization parameter, #see the CICS System

APF
Debug Tool for z/OS, Version 7.1, Customization Guide

Setting up the APF-authorized non-link list data sets This section describes where to place certain Coverage Utility load modules so that the correct people have access to them.

Placing Coverage Utility load modules in an APF-authorized data set accessible to all users

Certain Coverage Utility load modules must be placed in an APF-authorized data set that is accessible to all your users. The APF-authorized data set does not need to be in the link list.

1. Make the load modules in hlq.SEQAMOD accessible to all users by using one of the following
alternatives: o Mark the hlq.SEQAMOD data set as APF-authorized1 and make it accessible to all users by creating a Resource Access Control Facility (RACF(R)) profile. o Do not mark the hlq.SEQAMOD data set as APF-authorized. Copy4 the following load modules to an APF-authorized data set that all users can access. EQACUOCM (monitor interface) EQACU9M0 (monitor messages) EQACU9M1 (monitor messages) EQACU9M2 (monitor messages and only if the Japanese feature is installed) EQACU9M3 (monitor messages and only if the Korean feature is installed) 2. Add the EQACUOCM program to the AUTHPGM entry in the member IKJTSOxx of the SYS1.PARMLIB data set. 3. Issue the PARMLIB UPDATE(xx) command from TSO or IPL your system. 4. Edit the EQASTART member of the hlq.SEQAEXEC data set and set the INST_Auth_SEQAMOD variable to the name of the data set from step 1 that contains EQACUOCM.
Placing Coverage Utility load modules in an APF-authorized data set not accessible to general users

Certain Coverage Utility load modules must be placed in an APF-authorized data set that is accessible only to system programmers. The APF-authorized data set must not be in the link list. To place the load modules in an APF-authorized data set, do one of the following alternatives:

Mark the hlq.SEQAAUTH data set as APF-authorized1 and do one of the following: o Limit access to only system programmers. o Create Resource Access Control Facility (RACF) profiles to restrict access to these load modules. Do not mark the hlq.SEQAAUTH data set as APF-authorized. Copy4 the following load modules into an APF-authorized data set that only system programmers can access: o EQACUOIN (SVC installer) o EQACUOSV (SVCs)

Creating RACF profiles

If you place Coverage Utility load modules that must not be accessible to all users in an APF-authorized data set that is accessible to all users, you must create RACF profiles to prevent access to these load modules. You can add the code in the following example to the RACF profile:

RDEFINE PROGRAM(EQACUOIN) NOTIFY(notify) UACC(NONE) + DATA('RACF profile for Coverage Utility monitor') + ADDMEM('authlib'/'volser'/PADCHK) OWNER(owner)) RDEFINE PROGRAM(EQACUOSV) NOTIFY(notify) UACC(NONE) + DATA('RACF profile for Coverage Utility monitor') + ADDMEM('authlib'/'volser'/PADCHK) OWNER(owner) SETROPTS WHEN(PROGRAM) REFRESH

PERMIT EQACUOIN CLASS(PROGRAM) ID(id) ACCESS(READ) PERMIT EQACUOSV CLASS(PROGRAM) ID(id) ACCESS(READ) SETROPTS WHEN(PROGRAM) REFRESH
The above code restricts access to EQACUOIN and EQACUOSV by granting read access to only id. The following list describes the operands used in this example: notify TSO user ID of the person who is notified of a RACF access failure. authlib Name of the APF-authorized data set that contains volser Volume serial of authlib data set or owner TSO user ID or RACF group name of the person or persons that own this profile. id TSO user ID or RACF group name of the person or persons who have the ability to install the SVCs.

EQACUOIN and EQACUOSV.

****** to specify the current SYSRES volume.