<snip> We have a requirement to attach user modules from an unauthorised library and execute them from an STC which runs APF authorised. </snip>
You need to reject that requirement. It cannot be accomplished while maintaining system integrity. Use of something like "fork" can perhaps accomplish the goal without meeting the letter of the requirement. <snip> Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. </snip> And if you do that, you must *never* turn the bit back on. Turning of JSCBAUTH is a fairly common approach, once the "authorized stuff" has been done. But you must then leave it off in order to maintain system integrity. In all likelihood you should NEVER use RSAPF=YES. It is provided so that the initiator can attach the jobstep program task. I have no idea why it was documented. Way back when, even internal things were documented. Maybe when internal-only things were being removed from the books, no one realized how internal this one was. The only z/OS-supported mechanism for authority-decreasing is SYNCH(X). And I do intentionally exclude authority-decreasing PC's (e.g., a PC that gets control in problem state when the invoker was supervisor state) from what is supported by z/OS. You can't be stopped from doing so, but things likely won't behave the way you need if there was a (E)SPIE present. There might be cases other than (E)SPIE that similarly would cause anomalous behavior. I have no idea if this is documented explicitly. It's just something I remember being told long long ago. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
