Technical Information › Link Pack Area Analysis

Link Pack Area Analysis

The z/OS link pack area (LPA), option 3.4, is primarily a performance tool to speed up z/OS operation. Frequently used modules are loaded into virtual storage for fast access. Alternatively, z/OS would have to search its libraries each time a module is needed. Because library directory block sizes are small and the loading process is slow, the system could waste a lot of time in loading modules.

The solution to this problem was to use the link pack area as a kind of memory‑resident library, much like the RAM disks of microprocessors. z/OS loads LPA only at system IPL, and even then, only by request. At that time, LPA is built in virtual storage and is immediately paged out to disk. A directory is built as an index to the contents of LPA. Whenever z/OS needs a module, it consults the LPA directory, and the module is paged in from disk, if necessary.

By making LPA read‑only, z/OS can limit its paging operations to one way only, speeding things up because updated pages do not need to be saved on disk. Because virtual storage is managed on a demand basis, modules that are frequently referred to tend to be kept in real storage while infrequently used ones require paging operations when referenced. Because all LPA modules are kept in page data sets on disk, LPA is saved from one IPL to another. LPA is reloaded only during a cold start IPL. A cold start IPL is performed with the Create LPA (CLPA) command. The load modules in libraries listed in the LPALSTxx member are loaded in addition to the load modules from SYS1.LPALIB, whose modules are always loaded. Thus, the count of LPA libraries that CA Auditor gives is not the same as the count in LPALSTxx members.

If you look at the console operator’s log sheet, you can determine if LPA was reloaded by the operator’s response to the IEA101A SPECIFY SYSTEM PARAMETERS prompt. The reply R 00,CLPA means that LPA is rebuilt from the LPA libraries. This can also be specified in the IEASYSxx member of the logical Parmlib, although this is rarely done.

LPA is built from the LPA library list provided by the data center. You can find the list in the logical Parmlib. Use the Parmlib IPL Map Function to identify and browse the LPALSTxx member to obtain the library names. See the description of the system parameter library in the “System Installation Choices” chapter for more information about parmlib. Also, see the initialization and tuning manual for your level of z/OS.

z/OS creates two copies of the virtual storage LPA on disk if the DUPLEX= parameter is specified in the IEASYSxx member. If z/OS encounters an I/O error, it uses a backup copy and continues to operate. In theory, LPA is vulnerable to attacks on the page data sets. Many security experts do not see this as a credible threat due to the complexity of the page data sets’ internal structure. However, the page data sets should be protected from unauthorized access at all times.