On Wed, May 24, 2017 at 2:28 PM, Peter Hunkeler <[email protected]> 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. If I get really bored, I may actually write a smallish HLASM program which uses BPX1FRK to fork my process and then do a LINKX in the child for a program in my personal link library (which will be on the parent's STEPLIB) just to make sure that what I have in my mind actually works as I think it does. > > -- > Peter Hunkeler > > -- 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
