On Tue, 5 Jun 2007 11:56:45 -0500, Tony Harminc wrote:
>
>>Ouch! Dynamically creating job steps seems utterly contrary to the
>>JCL paradigm.
>
>Indeed. One of several cases where the z/OS UNIX implementation has
>unnecessarily broken existing paradigms. The surprise factor is often high.
>
"unnecessarily" indeed. I would be overjoyed if exec() retained the
DDNAME allocations. It would be immensely useful to be able to do
fork(), then in the child a bunch of DYNALLOCs then an exec(), or
especially an execmvs(). I recognize fork() is a horse of a different
color: it creates a new address space which had better not have any
SYSDSN ENQs in common with the parent address space.
>What happens ENQ-wise if you have two "classic" job steps where the ENQ is
>expected to last until the second one, and the *OMVSEX step is inserted in
>between? I imagine that won't have any surprises. I suppose this bahaviour
>can be explained by saying that the inserted job step provides no user
>interface to its JCL, and that therefore there is no possibility of
>affecting dataset ENQs.
>
I think we agree. By experiment, the inserted job step is
autonomous; it shares no ENQs with the explicit job steps,
but it can suffer an ENQ conflict with a later step in the
same job, or with its parent BPXBATCH step itself.
Hmmm. I get the ENQ conflict even if I use "//STDOUT DD SYSOUT..."
but no inserted job steps appear in the job log.
>> 3 //PAUSE1 EXEC PGM=BPXBATCH,PARM='sh exec /bin/true '
>>
>>... shows 3 generated "*OMVSEX" steps. Hmmm. One to exec() sh,
>>a second to exec() /bin/true. What's the third one? In fact, the
>>minimal:
>>
>> 3 //PAUSE1 EXEC PGM=BPXBATCH,PARM='sh exit'
>>
>>Shows 2 "*OMVSEX" steps. Why? But:
>>
>> 3 //PAUSE1 EXEC PGM=BPXBATCH,PARM='pgm /bin/sh -c exit'
>>
>>shows only one. Why should 'sh ...' take one more exec() than
>>'pgm /bin/sh -c ...'?
>
>Um, I think because it implicitly runs the shell (process 1) since you
>didn't use the pgm option, then the first shell command is "sh" (process 2),
>and then under that second shell you run "/bin/true" (process 3).
>
There appears to be no implicit shell. Unless the first argument
is either SH or PGM, I get:
BPXM010I BPXBATCH FAILED BECAUSE THE PARAMETERS DID NOT
START WITH SH OR PGM.
I suspect the extra exec() is coming out of /etc/profile. At
least that's sufficient excuse not to investigate further.
-- gil
----------------------------------------------------------------------
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
