Technical Information › Link Pack Area Analysis › Authorization for LPA

Authorization for LPA

All modules are APF‑authorized when executed in LPA (though only those link edited with the proper AC‑CODE can be named on a JCL EXEC statement to start a job step).

Before MVS/XA, early z/OS releases only used SYS1.LPALIB to create the link pack area at IPL time. Regardless of whether SYS1.LPALIB was listed in the IEAAPFxx or PROGxx logical Parmlib members to specify it should be APF‑authorized, the system would automatically consider it APF‑authorized only at CLPA IPL time when it created LPA, so that the loaded LPA modules are marked as APF authorized.

Even though SYS1.LPALIB is automatically considered APF‑authorized during CLPA, other libraries specified in LPALSTxx in parmlib need to be specified in IEAAPFxx or PROGxx. When building LPA, the system creates the LPALST concatenation to load the LPA modules from. Like any other concatenation, if the data sets concatenated contained authorized and non‑authorized data sets, the entire concatenation is considered not authorized.

Because the system does not automatically consider libraries other than SYS1.LPALIB authorized at CLPA IPL time, an unauthorized library in LPALSTxx causes all the libraries in the LPALST concatenation to be unauthorized, which z/OS does not allow. If LPALSTxx contains any libraries not in IEAAPFxx or in PROGxx, then at CLPA IPL time z/OS recreates the LPALST concatenation loading modules from only SYS1.LPALST. All modules are APF‑authorized when executed in LPA (though only those link edited with the proper AC‑CODE can be named on a JCL EXEC statement to start a job step). See APF Authorization of LPA Modules in the APF‑Authorized Libraries section the “System Installation Choices” chapter for more information.