On Thu, May 25, 2017 at 1:50 PM, Walt Farrell <[email protected]> wrote:
> On Thu, 25 May 2017 11:46:20 -0500, John McKown < > [email protected]> wrote: > > >On Thu, May 25, 2017 at 10:44 AM, Walt Farrell <[email protected]> > >wrote: > >> execmvs() would be better than LINKX or ATTACHX for this scenario, in > >> general, as it handles all the environmental cleanup and handles any > >> necessary authorization issues. > >> > > > >I was looking at both execmvs() and attach_execmvs(). execmvs() says that > >it "replaces the previous process image". IIRC, that means that the child > >process no longer has access to the point-in-time-of-original-fork copy of > >the parent's key 8 storage. So, no passing "read only" type data in > memory. > >Which is possibly a good thing. UNIX likes to pass data using something > >like environment variables or "shared memory" (which is what I'd likely > use > >if the child needs to update the original program's memory). > >attach_execmvs() starts a new process __in the same address space__ and so > >has the "plus" of retaining all the parent's memory. That is, the new > >process which runs the requested child program will still have the copy of > >the original parent's (grandparent's) key 8 storage. > > I don't know for sure, but I see issues with considering attach_execmvs() > in this scenario. You can't end up with two processes in the same address > space without dealing with authorization issues. > > For example, how will attach_execmvs() deal with an APF-authorized parent > process trying to attach a non-authorized child process? I think that's a > guaranteed S306 abend (or some equivalent UNIX error code). > > Therefor, I think the existing (parent) APF-authorized process would have > to give up APF authorization before it could safely use attach_execmvs() in > this scenario. > > However, once it's done that, what happens if attach_execmvs() determines > that the new process needs to run APF-authorized? It could not do that in > the same address space as the (now) unauthorized parent. Therefore, another > failure. > Well, from what I vaguely gather, this entire thread started off with the question of "how does an APF authorized program run a non-APF authorized program from a library not on the APF list?". Apparently the OP was trying this and got a S306-C. Or maybe he just want something like the TSO TMP does to "safely" (FSVO safely) invoke a program as a subroutine without APF authorization. My solution for the above was to architect do a fork() to create a new ,non-APF authorized, address space. The child would be running the same program at the same point in the 2nd address space (and with a different PID). And if I'm reading the documentation correctly, the new address space is _NOT_ running APF authorized. So the program, in the child, would set things up to invoke the desired program. That background is why I was thinking LINK instead of execmvs(). Also LINK does not replace the process image, so the copy of parent's key 8 storage is still accessible. If the child needs to update the parent's memory, then said memory needs to be set up as "shared" in both processes (address spaces). > > -- > Walt > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
