> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Patrick Roehl > Sent: Thursday, April 21, 2011 2:57 PM > To: [email protected] > Subject: Mixing Auth and Non-Auth Modules > > I have a situation where APF-authorization is needed by a new > subprogram > that performs RACF functions. This was working fine until it > came time to call > the new subprogram from the main program, which does not need to be > authorized. Making the whole process authorized seems silly > (or worse), in > addition to being inconvenient as there are many STEPLIB > entries involved. > > I tried running the main program from an authorized LNKLST > library, but quickly > ran into S306-12 when trying to load a program from the STEPLIB. > > Is the best option to handle this setting up a separate > region to handle the > authorized calls and communicating via a PC? It looks like a > PC client would > have to be authorized, which defeats the purpose. > > How has this been solved in the past? > > Thanks for any suggestions and/or examples.
APF is generally an "all or nothing" affair. z/OS, and MVS before it, was not designed to swap between APF and non-APF authorized states. You can do the APF to non-APF switch relatively easily. But it is generally a one way street. TSO does it by having two TCB trees. TSO starts up APF authorized, but resets the APF when the TMP does an ATTACH. But before that it creates an APF authorized subtree. When you run an APF authorized TSO program, it is run on the APF subtree and not the normal subtree. The normal subtree is "frozen" via the STATUS STOP operation during APF authorized function to decrease the likelihood of "cracking" the APF code. CICS switched back and forth using its SVC somehow (I don't know the internals). Now, being the weirdo that I am, I'd likely do my APF authorized work by using the UNIX fork() and exec(), where I exec() a module which is in the UNIX filesystem marked as APF authorized. Depending on what I need to do, I would either use shared memory (shmat) or set up a UNIX bidirectional unnamed PIPE if the APF task worked more like a "server" and would be invoked multiple times. It's just seems easier to me. Or use UNIX message queues for communications. I have a better understanding of using pipes. The plus of the UNIX solution is that the invoker does not need to be APF authorized at all. It just needs to be able to do the UNIX fork() and exec() of the APF authorized "service" program. I'd likely secure the service program by having the appropriate UNIX security on the executable file in the UNIX filesystem (using ACLs if necessary). An alternative / enhancement would be to have the UNIX program do a RACF security call of some sort to see if the invoker is authorized. This latter would be better if the routine is multifunction where the sub functions need to be individually authorized, perhaps with differing access lists. Like what ISMF does. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- 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
