On Thu, May 25, 2017 at 10:44 AM, Walt Farrell <[email protected]> wrote:
> <snip> > > >a UNIX directory. So I was not envisioning him using a UNIX exec() > function > >to run the non-APF program in the child. I was thinking the "historic" use > >of LINKX or maybe ATTACHX. The mention of a TASKLIB for a dynamically > >allocated was just in the case that the OP's design called for the > >specification of a user designed set of libraries as well as just a > program > >name. > > 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. > > -- > Walt > > -- 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
