The LLACOPY system initialization parameter specifies the
situations where CICS uses either the LLACOPY macro or the BLDL macro
when locating modules in the DFHRPL or dynamic LIBRARY concatenation.
- LLACOPY={YES|NO|NEWCOPY}
- Valid values are as follows:
- YES
- CICS always uses the LLACOPY macro when locating modules in the DFHRPL or dynamic LIBRARY
concatenation.
- NO
- CICS always uses the BLDL macro when locating modules in the DFHRPL or dynamic LIBRARY
concatenation.
- NEWCOPY
- CICS uses the LLACOPY only when a NEWCOPY or a PHASEIN is being performed. At all other times,
CICS uses the BLDL macro when locating modules in the DFHRPL or dynamic LIBRARY concatenation.
You can improve the performance of module fetching on your system by allowing library
lookaside (LLA) to manage your production load libraries. LLA reduces the amount of I/O needed to
locate and fetch modules from DASD storage. For more information about this, refer to Improving module fetch performance with LLA.
Note: - If you code LLACOPY=NO or LLACOPY=NEWCOPY you can still benefit from having LLA managed data
sets within your DFHRPL or dynamic LIBRARY concatenation. Modules will continue to be loaded from
the virtual lookaside facility (VLF) if appropriate. For more information about VLF and LLA refer to
Controlling LLA and VLF through operator commands.
- If an LLA managed module has been altered, a BLDL macro may not return the new information and a
subsequent load will still return the old copy of the module. To load the new module, an LLACOPY
must be issued against that module or a MODIFY LLA,REFRESH command must be issued on a system
console.
- If you set LLACOPY to anything other than NO, ensure that the proper RACF security permissions
have been set up first. For more information about this refer to Resources protected by
the FACILITY general resource class.
- If an LLACOPY is issued against an LLA managed module, it creates a BLDL macro to interact with
the specified DCB. If the directory information does not match the information stored in LLA, the
LLA tables are updated to keep both subsystems synchronized. Whilst the LLA tables are being
updated, SYSZLLA1.update has an enqueue (lock) held against it until LLA is stopped or the library
is removed from LLA management.