Paul Gilmartin said; > In a recent note, Craddock, Chris said: > > A TSO address space is just an address space and in general there is one > > TIOT per address space, but that's only because in general there is only > > one real job step task. If you're privileged and you attach (and set up) > > more concurrent job steps, then you can have more TIOTs. Their behavior > > is not all sweetness and light, but it's doable. > > > I don't believe you need any special privilege to use BPX1FRK, and each > child then has its own TIOT. Is each child then a job step task? > With privilege, can multiple job step tasks operate in a single > address space? (It was possible with MVT; why not z/OS?)
I am by no means an expert on USS, but I believe when you fork() the spawned process runs in one of those handy BPXAS address spaces that the system keeps around specifically so fork() can run fast-ish by avoiding the ASCRE and related overhead. I don't know anything about the state of the TIOT in the forked address space (whether it contains any pre-defined allocations) but since it really is an address space with a job step and a TIOT, presumably it can do normal allocation and for the most part life goes on as expected. Lightweight threads, pthreads (or whatever they are called on any given day) probably run as subtasks, but again, I don't know for sure since I have never paid attention to such things in detail. My only close brush with USS has been related to porting APACHE, GCC and related stuff. That was quite a few years ago now and I coerced it to run in a set of normal subtasks designed to accomplish the goals we had for it. In other words, the ported code did not do any native fork() or thread management of its own. You DO need to be privileged to attach a job step task and there are a number of significant quirks that crawl from the woodwork if you're man enough to attach more than one. Allocation is tightly woven with ENQ serialization, so while it is possible to compose applications that understand and co-operate in such an environment most just won't work. If you threw in two applications that assumed they were the only camper in the place there's a very good chance they would cause havoc with each other. There are just too many deep seated job-step related assumptions within z/OS and its ancestors. CC ---------------------------------------------------------------------- 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
