The link pack area (LPA) is a read‑only, high‑speed access facility for z/OS programs and modules. It is loaded from the LPA library data sets (SYS1.LPALIB and other libraries specified in the LPALSTxx member of SYS1.PARMLIB) only during an IPL with the CLPA option. You do not need access to any file for this option.
Use the Link Pack Area Analysis option (3.4) to access this information.
Auditor___________________________ Location___________________ Page____of____
Approved__________________________ CPU________________________ Date__________
|
Step |
Description |
W/P Ref |
Finding |
Remarks |
|---|---|---|---|---|
|
1 |
The contents of the z/OS system LPA come from SYS1.LPALIB, a required z/OS system data set, and other libraries specified in the LPALSTxx member of SYS1.PARMLIB. Additionally, an operator or systems programmers can add to or replace modules that were previously linked into LPA with other modules that were found in SYS1.LPALIB, SYS1.SVCLIB, or SYS1.LINKLIB and its extensions. (SYS1.LINKLIB and its extensions are referred to as the linklist.) Note: LPA modules can be loaded into LPA, MLPA, or FLPA from any authorized data set. Use the LPA Library Display (2.4.3) to identify all the LPA libraries. Determine from the display or your access control software if they are protected from unauthorized access and updates. |
|
|
|
|
2 |
Use the File History Search (6.5) to search SMF for updates to the LPA libraries. Verify that any updates agree with change authorization records and procedures. |
|
|
|
|
3 |
Modules resident in LPA are required to be refreshable, which means that they never modify themselves. These modules are often referred to as reentrant, but the refreshable designation has a stricter interpretation. In all z/OS systems, modules resident in the LPA are assumed to be reentrant and refreshable. If these modules are not, program failures can occur. Determine from the LPA display if any modules are shown as nonreentrant. |
|
|
|
|
4 |
LPA can contain locally‑developed programs and modules supplied by IBM and other vendors. Use the Program Origin display (5.1) to identify unknown modules. In many cases, the unknown modules are modules provided by other vendors or by the data center. |
|
|
|
|
5 |
z/OS attempt to satisfy program fetch requests from LPA before it begins a linklist library search. Use the APF Duplicate Program display (2.2.2) to determine if the LPA libraries contain modules that are also found in other libraries. |
|
|
|
|
6 |
If the system runs with a nonauthorized linklist at this data center, you must supplement the above test. Pick a sample of modules from the LPA display. Use the Link List Library Display (2.4.2) to obtain the names of the linklist libraries. Then use the Program Statistics Display (5.2) to search each library. |
|
|
|
|
7 |
From the LPA Library Display (2.4.3), note any modules marked as APF‑authorized. Determine the use, purpose, and function of any data center‑written modules because their presence in LPA makes them available to all z/OS users. |
|
|
|
|
8 |
LPA library‑based security reviews cannot detect all modules in LPA. This is because z/OS load the LPA libraries into virtual storage only during a CLPA‑type IPL. Modules can be removed from the libraries without affecting what is in memory, even over a number of IPLs. Use the Link Pack Area Display (3.4) to examine the link pack area. Select a sample of modules to perform a library search. Determine if any modules in LPA are missing from the link pack libraries (such as SYS1.LPALIB and so on) by selecting them from the LPA display. Verify authorization for deleted modules. |
|
|
|
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |