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 <[email protected]> wrote: > On 31 December 2013 13:23, Paul Gilmartin <[email protected]> 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. > > ---------------------------------------------------------------------- > 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
