On Tue, 17 Mar 2015 13:28:29 -0500, John McKown <[email protected]> wrote:
>On Tue, Mar 17, 2015 at 10:43 AM, John McKown ><[email protected]> wrote: >> >> Being a paranoid heretic, I would go the UNIX route and figure out a >> way to run the untrusted code in a child process in another address >> space by using fork() and, likely, attach_execmvs(). And I again >> acknowledge the problems associated with DD statements in this >> environment. > >Talking to myself again. But I had another take on the above, for shop >which despise UNIX. Use ASCRE to create the new address space. One >problem is that this uses an INIT routine to initialize the address >space. The documentation for ASCRE does not say anything about >propagating the STEPLIB/JOBLIB, I assume this INIT routine needs to be >in LPA, or dynamically added to LPA. The INIT routine would be passed >the DSNs which make up the STEPLIB/JOBLIB for the task, do DYNALLOC >on them, OPEN the DD, and use the TASKLIB= option of ATTACHX. It would >also receive the equivalent of the PARM= from a batch job, which it >might need to reformat and pass to the user program. > >If some data needs to be shared, put all of it in a single, large, >page boundary GETMAIN'd area and use IAZVSERV to map that between the >two address spaces. Sure, go ahead and reinvent fork(). Then try to figure out what parts of it you got wrong. Or, guess what: it's a lot easier to simply use fork(), which after all is a native z/OS service. You don't _have_ to think of it as being UNIX. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
