On Tue, 29 May 2007 10:50:23 -0500, Paul Gilmartin 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. 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. > 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). Tony H. ---------------------------------------------------------------------- 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
