LLA and VLF
Modules loaded by CICS from the DFHRPL (or dynamic LIBRARY concatenation) 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.
The use of LLA to manage a very busy DFHRPL or dynamic LIBRARY concatenation can show two distinct benefits:
- Improved transaction response time
- Better DASD utilization.
It is possible, as throughput increases, that DASD utilization actually decreases. This is due to LLA's 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 or dynamic LIBRARY concatenation, 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.
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.
RACF and LLACOPY
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)
Keep the number of libraries defined by DFHRPL to a minimum. One large library requires less time to perform the LLACOPY than many smaller libraries. Similar consideration should be applied to any dynamic LIBRARY resources installed at startup.
0 comments on LLACOPY= (SIT parameter)