> Date: Fri, 18 Jun 2010 13:48:19 -0600
> From: Paul Gilmartin <[email protected]>
> Subject: Re: ATTACH Macro with DCB=
>
> The deficiency in execmvs() is that it discards the caller's DD
> allocations. Being unfamiliar with the internals, I can easily
> say, this is very stupid. Someone familiar with the internals
> might argue it's impossible to do it any other way. Yet the
> initiator (an authorized program) can ATTACH the program
> named in the PGM= option (whether authorized or unauthorized)
> without discarding the allocations. Why can't execmvs(), at
> least optionally, do likewise, duplicating the logic in the
> initiator between ALLOCATE and ATTACH? Perhaps it
> could even reuse the initiator's code.
>
execmvs() is designed to be the functional equivalent of terminating the
current Job Step and beginning a new Job Step (device allocations do not
persist across Job Step boundaries). Quoting from topic "execmvs
(BPX1EXM, BPX4EXM) -- Run an MVS program" within "z/OS UNIX System
Services Programming: Assembler Callable Services Reference"
(SA22-7803-11):
"Because the service must create a new process image for the
specified program to run within, the prior process image is
completely cleaned up. In MVS terms, the system ends a step
within a job and then inserts a new step for the specified program
to run in. Any MVS task-related resources that existed in the old
job step are cleaned up. The new job step that is created has no
allocations associated with it, with the exception of the MVS data
sets that may be built into the STEPLIB environment for the new
process image. When the newly created job step ends, the flow of
the job continues, as it normally does, to the next sequential
step in the job, depending on the completion code of the ending
step."
With respect to functions performed by the MVS Initiator:
The MVS Initiator executes in Supervisor State with a System Key.
APF Authorization is tracked at the JobStep level via the JSCB
(mapping macro IEZJSCB).
Device Allocation is tracked at the JobStep level.
Structurally, the Initiator executes as a JobStep TCB (with its
own JSCB) which is separate and distinct from the JobStep environment
for the target program ATTACHed by the initiator. Among other things,
this means that the Initiator JobStep has its own, separate and distinct,
set of device allocations.
Because of the execution characteristics of the Initiator, it is
permitted to ATTACH as a new JobStep TCB a target program which
may or may not possess the APF Authorized attribute. The APF
Authorization state of the newly created JobStep is tracked in the
JSCB for that JobStep.
If I understood the query from the original poster, he wanted to be able
to create a new TCB (via ATTACH) where the attaching program is
executing in Problem State without APF Authorization, and have the
ATTACHed program begin execution in an Authorized state (this might mean
execution in Supervisor State, or, causing the current JobStep to
transition to APF Authorized at the JSCB level). As others have stated,
this is not generally permissible.
MVS intends to provide strong security boundaries. Facilities exist
which permit suitably authorized users and/or programs to compromise
these boundaries (such as the creation of "magic" SVC routines, etc.).
MVS itself offers some facilities (such as the TSO scheme mentioned by
Walt Farrell) which allow some of these boundaries to be weakened, but
exploitation of these facilities requires the explicit cooperation of
the people who manage the system itself -- caveat emptor.
I think I understand what you're saying about having a facility which
captures the information for the current set of device allocations for
the current Job Step and then effectively constructs the equivalent of
executing a new Job Step, specifying those allocations. There certainly
are access rights considerations (as well as other challenges, such as
Disposition processing) for such a facility. The design and
implementation of such a facility would require very careful thought.
Maybe you should submit a new function request to IBM.
Bob Raicer
