I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems.
But (as usual) that might just be my wrong-headed view of the situation. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Wednesday, January 08, 2014 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Spawned Address Space Control in tcsh shell Is there a specific reason (other than it being goofy) that the child could just become the parent? Some sort of percolation upward? Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Tue, Dec 31, 2013 at 2:18 PM, Tony Harminc <t...@harminc.net> wrote: > On 31 December 2013 13:23, Paul Gilmartin <paulgboul...@aim.com> wrote: > > Most (?) of the complaints about (non-)shared areas stem from the > > non-propagation of DDNAMEs through fork(). Ain't gonna get better > > (NVFL, anyway). Because of ENQ conflicts between parent and child. > > Extend the ENQ scope to job rather than address space? NVFL, again. > > > > I could imagine: > > > > o A scheme where an allocation could be transferred from parent to > > child, freeing the ENQ in parent. > > > > o A server-client model in which the actual I/O is performed by the > > parent that performs the allocation, and the data passed to the > > child via sockets or POSIX pipes. Sort of like NFS, but it needs to > > be better than NFS. > > The likely problem is that - unlike the MVS subtasking model - in UNIX > the parent process can go away leaving the child running. Would you > leave the parent running just to handle the I/O work, or clean it up > and transfer the ENQs and/or allocations to the child at that point, > or just say Don't Do That, or...? > > Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
