The write-up for OA11699 says:
"BPXBATCH has logic in it to detect when it is running from JCL.
By default, BPXBATCH sets up the stdin, stdout, and stderr file
descriptors and then calls the exec callable service to run the
requested program. The exec service ends the current job step
and creates a new job step to run the target program. Therefore,
the target program does not run in the same job step as the BPXBATCH
program; it runs in the new job step created by the exec service."
Since the current job step is ended, any held DSNAME ENQs are released.
BPXBATSL may behave differently; I haven't tried that experiment.
Bill
On Mon, 28 May 2007 10:55:22 -0600, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
>(Cross-posting to IBM-MAIN and MVS-OE)
>
>Motivated by recent ENQ discussions on IBM-MAIN, I used the job
>step in an experiment:
>
>//PAUSE1 EXEC PGM=BPXBATCH,PARM='pgm /bin/sleep 120'
>//SYSUT1 DD DISP=OLD,DSN=&SYSUID..FOO.BAR,
>// UNIT=SYSALLDA,VOL=REF=SYS1.SAMPLIB
>
>The job log, shows, peculiarly:
>
> 10.46.12 JOB05157 -
--TIMINGS (MIN
> 10.46.12 JOB05157 -STEPNAME PROCSTEP RC EXCP CONN TCB SRB
CLOCK
> 10.46.12 JOB05157 -PAUSE1 00 39 4 .00 .00
.3
> 10.48.12 JOB05157 -*OMVSEX 00 12 4 .00 .00
2.0
>
>... one entry for the completion of BPXBATCH, and another two minutes later for
>the child process doing the sleep. What astonished me is that during the
>itervening two minutes I could allocate the '&SYSUID..FOO.BAR' data set with
>another job. Apparently, the initiator DEQs the data set name when the
BPXBATCH
>process completes, not when all its children have been collected. This may be
>WAD, but it feels wrong to me. Any comments?
>
>-- gil
>--
>StorageTek
>INFORMATION made POWERFUL
>
----------------------------------------------------------------------
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
