|
|
|
Although we commonly speak of LPA, there are actually three distinct LPA areas in z/OS, each serving a different purpose:
The MLPA and the FLPA are described later in this chapter. Each LPA area has a corresponding ‘E’ area that exists above the virtual 16 MB line, where LPA modules link edited RMODE=31 or RMODE=ANY are placed.
The PLPA is a range of virtual storage addresses that is set aside for special use at IPL. It contains SVC routines, access methods, other system programs, and selected user programs. As its name implies, PLPA is pageable. However, no physical page‑outs are performed once the IPL process has completed. Any changes made to modules residing in PLPA are lost when the next page‑in operation occurs. Because all users share the modules in PLPA, all program modules in PLPA must be reentrant and read‑only.
The PLPA is what is usually meant when people refer to LPA. PLPA has hundreds or even thousands of modules in it. z/OS usually searches the PLPA before it searches the system linklist for a program module. If a module is found in LPA, the system uses that version without consulting SYS1.LINKLIB or its concatenations. This means that you might not be executing the version of a program that you think you are if you have not checked LPA.
Fortunately, z/OS requires programs in LPA to be reentrant. You can use the Program Statistics Display (5.2) to determine which programs are candidates for LPA. It is possible for programs to be placed in LPA and not be reentrant. In older z/OS releases, z/OS does not enforce reentrancy. However, any program that modifies itself during execution can get overlaid in memory if z/OS is forced to page a copy from disk. More recent z/OS releases can enforce the reentrancy requirement using the dynamic address translation (DAT) hardware.
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |