When the Initiator frees a dataset and no subsequent step has a DD for it, the Initiator does a DEQ. If there is a subsequent dynamic allocation, then the Initiator does a new ENQ; there's always a possibility that some other job will get there first.
BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC 99) as any other allocation. GRS maintains a global reference count for any resource, not just SYSDSN. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 _______________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, February 11, 2019 11:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DEQ dynamically On Mon, 11 Feb 2019 06:43:14 -0600, John McKown wrote: > >One thing that I sometimes do is include a FREE=CLOSE on a DD if I am >certain that the application will only read if once, say at start up, for >configuration information. > How does that work if a subsequent job step contains a DD statement for the same DSN? I would guess that the control blocks for the job step (TIOT? JFCB?) are cleaned up but the initiator continues to hold the ENQ. Or just a JCL error? And something similar should apply to a BPXWDYN('free') of a DSN allocated by JCL. And if a program redundantly ALLOCATEs then FREEs a DSN allocated in JCL? Does GRS maintain a reference count of the ENQ QHAME/RNAME? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
