On Mon, 17 Nov 2014 21:11:30 -0500, Farley, Peter x23353 <[email protected]> wrote:
>But then one is constrained to the semantics of fork() and the Unix >multi-process philosophy. If a non-authorized program >could create its own >address spaces at the z/OS level, then the answers to your questions would be: > >1. Only the AS's created by the originating program or created by those >created AS's. >2. Synchronization to be sure the AS is there and running the program you >expect is your responsibility, though this may >require other, >yet-to-be-invented methods (homework for the reader. . .); >3. If the original AS dies then all AS's it created die as a result, and all >AS's created by the created AS's as well (akin to TCB >termination); if one of >those created AS's dies, it is your responsibility to detect it (via an AS >termination exit akin to ESTAI >but at the AS level, I would presume) and >react accordingly. > >But all of that is a pipe dream, I know. We have what we have - >authorization is required, and cannot be avoided - and >that's the end of it. Other than all the address spaces going away if the original dies, how is that any different from what fork() allows today? And you already have it without need for system-level authorization for the original address space. In any case, besides your 3 points, the system would also need a mechanism to limit how many address spaces you could create, and some communication methods, so there's some added complexity for the supposedly "simple" new service. But again, the UNIX methodology (which can be used by non-UNIX programs, don't forget) already provides that, too. -- Walt
