On Tue, Sep 12, 2017 at 12:24 PM, Paul Gilmartin <
[email protected]> wrote:
>
> Is it holding an ENQ on the GDG base even after allocating the new
> generation?
>
Yes (and that's what the IKJ56225I indicates). Note that the first job
allocated a +1, but hasn't freed it yet.
>
>
> Why are you doing this? It looks like a race where it doesn't matter who
> wins.
>
Two concurrent non-batch jobs want to create new generations.
In particular, this happens between two file transfer address spaces (one
for each concurrent session), so the data set (generation) is allocated
during transfer.
In my example above, the first job's allocation succeeded and cataloged a
new goovoo (at allocation).
Wouldn't it be nice if the second job's allocation just got the next
goovoo?
Of course, you could end of with a hole in the goovoo sequence if the first
job failed w/ CONDISP=DELETE. Maybe that is what the current GDG design
is trying to protect against against. Gee, thanks. Maybe that will be a
feature in "Extended GDGs(+1)" ;-)
> Does a similar problem exist for generated DDNAMEs ("SYSnnnn") among
> multiple concurrent tasks in a single job?
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
