RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is to allow the system to support unauthorized tasks and jobs, and is used only with the creation of a new job-step task. And there is no communication between the initiator task and the user task.
Authorized programs aren't allowed to invoke unauthorized code for a very good reason. Trying to circumvent that in any way compromises your system integrity. That said, running bad authorized code does as well, so caveat emptor. sas On Mon, May 15, 2017 at 10:16 AM, Walt Farrell <walt.farr...@gmail.com> wrote: > On Mon, 15 May 2017 15:18:38 +0700, Robin Atwood <abend...@gmail.com> > wrote: > > >We have a requirement to attach user modules from an unauthorised library > >and execute them from an STC which > > > >runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly > what > >I want ... > > It _can_ do what you want, Robin, but as others have said it is very risky > to do this, and very complex to do it safely. Basically, what you're trying > will only work safely if your STC is designed properly to allow it. At a > minimum, I believe that means making sure that none of your STC code runs > in key 8 or uses key 8 storage. It would need to start from the beginning > in a system key, specified by the Program Properties Table in PARMLIB. You > could then, possibly, invoke the non-APF code safely as long as you run it > in key 8. > > But the question then becomes what do you expect the non-APF code to do, > and how do you expect to communicate with it. > > It really would be better and safer, in my opinion, to find another > solution. This might possibly involve using multiple address spaces (via > UNIX fork()) as John McKown suggested. But we would really need to know a > lot more information about your STC, and the non-APF code, to be able to > provide the best advice. > > (It is very unlikely, in my experience, that your current STC is designed > to allow you to do this safely. A major redesign and reimplementation of > the STC would probably be required if you haven't been thinking about this > from the very beginning of its development.) > > -- > Walt > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
