On Thu, 25 May 2017 08:11:31 -0500, John McKown <john.archie.mck...@gmail.com> wrote:
>On Wed, May 24, 2017 at 2:28 PM, Peter Hunkeler <p...@gmx.ch> wrote: > >> > The above is why I really "push" the UNIX fork() alternative. >> [snip] >> >> >If a "steplib" is needed, the initial child program can simply DYNALLOC >> the DSNs and then use an ATTACHX with a TASKLIB. >> >> Assuming there will be an exec() in the forked process, a steplib can be >> setup simply by setting the STEPLIB environment variable, and passing that >> to exec(). >> > >That is true. As I read the doc on fork(), the parent's >TASKLIB/STEPLIB/JOBLIB is propagated to the child. As best as I can tell, >the OP's program is _not_ really designed as a UNIX program, per se. That >is, I am assuming that his programs (and specifically the non-APF program >to be invoked for some purpose) reside in a _library_ (PDS or PDSE) and not >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. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
