The way I read this, z/UNIX is enqueing on the GDG base while it
does its work. And I can't tell from what is provided how long it
holds that before it frees it.
Regards,
Steve Thompson
On 09/12/2017 01:24 PM, Paul Gilmartin wrote:
On Tue, 12 Sep 2017 11:54:04 -0500, Kirk Wolf wrote:
Is there a way around this?
Even with SMS-managed GDGs, where the generation is cataloged at
allocation, two jobs that dynamically allocate +1 generations (with GDGNT)
will collide.
For example, from two different jobs:
(job 1)
./bpxwdyn.rexx "alloc fi(mydd) da('managed.test.gdg(+1)') recfm(v,b) new
catalog gdgnt lrecl(1028)"
BPXWDYN RC= 0 (0x0)
(job 2)
./bpxwdyn.rexx "alloc fi(mydd) da('managed.test.gdg(+1)') recfm(v,b) new
catalog gdgnt lrecl(1028)"
BPXWDYN RC= 34603008 (0x2100000)
IKJ56225I DATA SET MANAGED.TEST.GDG ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IEFA110I DATA SET CONTENTION
It feels as if Allocation fails to perform some needed serialization.
Might this be APARable?
How large is the hazard window? Does it extend beyond the activity of SVC 99?
Is it holding an ENQ on the GDG base even after allocating the new generation?
Do batch job behave similarly? I suppose one might wait for initiation until
the earlier one DEQs.
Why are you doing this? It looks like a race where it doesn't matter who wins.
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
