Hi, Mike writes: > Stan Sieler ([log in to unmask]) wrote: > : My guess: system() is checking that the process is "clean" for possible > : use of fork() ... which requires (I think) that the process not have > : any resources that wouldn't be forkable: outstanding switches to CM, > : IMAGE databases, and (probably) some CM managed files (CM KSAM, > ^^^^^^^^^^^^^^^ > : or RIO files). > > I was kind of shocked to see IMAGE databases on this list. Could you > explain why? > > Mike "I don't feel like walking the three aisles to find out" P. Why you were shocked? Sure...many lab people forget that IMAGE exists, that's why you were shocked. :) (just kidding...I know Mike is aware of IMAGE) I suspect that IMAGE should be on the list of the non-forkable items because it isn't "thread safe" ... if the fork clones existing open-files, then the forkee (child process) will have the root file and some datasets open. But, if the entire process-private data area is also copied, then the DBU (a one-per-user data structure) might be copied as well (or, at least, pointers to it). However, IMAGE assumes that it has exclusive access to what it thought was process-local data structures ... a valid assumption prior to the introduction of fork (and threads). (The DBU address is stored in the KPO table) (BTW, the DBU is allocated by doing an HPFOPEN of a namless temp file, with short map option) -- Stan Sieler [log in to unmask] http://www.allegro.com/sieler.html