On Fri, 13 Jun 2008 14:59:54 +0200, Hunkeler Peter (KIUK 3) wrote: >>[snip]... This is probably since they can't just re-load all >>the modules, since source library info isn't saved. > >fork() processing must not load the modules again, even if it knew >where they've been loaded from. fork(), by definition, creates a >1:1 copy of the process (address space). Programs might have changed >intenal fields and the new process might depend on that very value. > If the module is refreshable, and marked as such (and REFRPROT is enabled), internal fields can't be changed. The original specification of "refreshable".
>(The "1:1 copy" above applies to the UNIX part, only. MVS "things" like >data control blocks are not copied over). > So what happens if a program with a DCB open for INPUT performs a fork()? Does fork() leave a blank space where the DCB was? What happens if the child performs a READ? Something ought to fail because the parent may have scratched the data set and the child would be reading unallocated DASD tracks. Repeat the question with OUTPUT in place of INPUT. If the parent has a descriptor of a UNIX file, the child inherits it with no problem: the disk blocks are not freed until some process unlinks the file and both the parent and child close it. (But what if YA process opens it with O_TRUNC?) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
