The rule is simple. I do not understand why this topic continues to come up. It has been discussed many times.
AC(1) is relevant for the EXEC PGM= Attach only. Otherwise it is ignored. And it applies when the concatenation is APF-authorized only. A concatenation is APF-authorized when all of the data sets in the concatenation are APF-authorized. Otherwise it is not APF-authorized. The LNKLST is treated specially. It can either be treated as entirely APF authorized (the system parameter LNKAUTH=LNKLST) or individual data sets can be analyzed (LNKAUTH=APFTAB). This applies to fetches that are accomplished from the LNKLST, not from a fetch from a concatenation that just happens to include a data set that is in the LNKLST. Chis B wrote <snip> If you LINK/LOAD/ATTACH a program from a library in the LNKLIST and you have only authorized individual libraries in the list, rather than the whole list, and you are calling a module in one of those unauthorized libraries, then your job (and I can't remember which) either becomes unauthorized or it fails with an abend. </snip> I'm not sure what Chris is referring to here. A job step never becomes unauthorized due to a module fetch. The rules from above apply to the EXEC PGM= Attach. In almost all cases, a fetch by an authorized caller (APF or supervisor state or system key) is expected to be satisfied by a module from an APF-authorized concatenation (or, when using the LNKLST, a LNKLST data set that is APF-authorized when LNKAUTH=APFTAB). If there is no success in finding a suitable module, then the fetch fails (usually with an abend). The concatenation could be defined via LNKLST, JOBLIB, STEPLIB, a tasklib, or any random DCB provided on the fetch request. There are z/OS Unix analogs of AC(1).. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
