Not if thre is a dd for it in the second step.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Saturday, November 2, 2019 11:45 PM To: [email protected] Subject: Re: Clist dataset On Sat, 2 Nov 2019 22:30:47 -0500, Tim Hare wrote: >We submit a batch job with two steps: first step IEFBR14 with the dataset >name allocated DISP=OLD, second step IDCAMS to do ALTER dsname >NEWNAME(newdsname). The job ENQs on the dataset name so new TSO allocations >for it fail, and the job waits until all TSO users using it have freed it or >logged off. Once it has the dataset it finishes very quickly. > As soon as that step terminates, the ENQ will be DEQed and any batch jobs waiting for the DSN will grab it. That may not be what you want. >I think we tried having some 'dummy' DD in the IDCAMS step with the dataset >name and DISP=OLD (eliminating the IEFBR14) but I can't remember if that >worked or not > I'll suggest not a dummy first step, but an added last step: //ENQ EXEC PGM=IEFBR14,COND=(0,LE) * ENQs but never executes or allocates. //OLD DD DISP=MOD,DSN=old.dsn * (MOD avoids JES3 setup problems.) //NEW DD DISP=MOD,DSN=new.dsn But this might be disruptive in the OP's situation where the DSN is almost always in use. -- 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
