Thanks, John. I have constructed a bare-bones testbed in HLASM and called BPX1FRK and it "Just Worked". :) The cool thing is the child process is created in a BPXAS address space that is just lying around and doesn't need to be created. And, according to the doc, in the real case where the STC is multi-TCB only the TCB issuing the fork gets cloned in the new ASID, exactly what I want.
-- Robin -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: 23 May 2017 19:41 To: [email protected] Subject: Re: ATTACH with RSAPF=YES On Tue, May 23, 2017 at 2:43 AM, Robin Atwood <[email protected]> wrote: > Yes, the point was taken. I am now investigating using fork() to > spin-off another address space. > ​From my vague monitoring of this thread, I think that is a wonderful idea. I don't know how much you're "in to" what can be done, but there are some nice(!) facilities that fork() can leverage. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm You can use the C language setenv() to set a number of UNIX environment variables with can affect the results of fork() if you have the right RACF authorities set up. _BPX_JOB NAME can set the name of the fork'd address space (such as to the user's name) _B PX_USERID can set the RACF owner for the fork'd address space. The address space doing the fork() needs some "heavy" RACF authorities for this. > > Thanks > Robin > > -- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
