On 8/22/07, Chase, John <[EMAIL PROTECTED]> wrote: > > > Regardless, unless I misunderstand "authorization", if an authorized > caller were to invoke that module after it was loaded into the LPA, the > module would be able to perform functions requiring authorization, even > lacking AC(1).
Interesting. From my little knowledge, there are (only?) two places where AC(1) matters: 1. EXEC PGM=XXX If the module is from a APF lib and with AC(1), JSCBAUTH will be set on which means the whole job step will run in APF-authorization status. 2. ATTACH RSAPF=YES The same logic is used to reset JSCBAUTH. Before doing this, JSCBAUTH needs to be set off if it's already on. And the caller must be in supervisor state or system key. As for the above example, since the module is in LPA which means it'll be treated as having been loaded from an APF lib, it can be invoked by an APF-authorized job step. Unless it's invoked via ATTACH RSAPF=YES, AC code doesn't matter. However, is the module in LPA also treated as having AC(1)? I'm not sure. And it makes me think of another question: After a module is loaded into JPA, is the information of this copy (whether it's from an APF lib and its AC code) stored in some system control blocks? My guess is yes. If the module is RENT, the same copy will be reused. So the info must be stored somewhere. -- Best Regards, Johnny Luo ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
