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