Well I'll be darned. I had not looked carefully at OP's message. That is *exactly* the context of the enqueue case I posted generically. SDAA004I is NDM or ConnectDirect depending on your perspective. We seem to have a lot of these self-clashes in our environment. I have not talked with the affected users, but it appears from the NDM control statements echoed in syslog that they are trying to send a data set from SystemX to SystemX with the same name. I suspect that they are requesting exclusive control of the 'target', i.e. OLD. But NDM is already using the data set as 'source', so it cannot obtain an exclusive enqueue for the same name. When the enqueue fails, the NDM process terminates, so a D GRS command a split second later shows no enqueue. That's how our (ancient) version of NDM works.
OP's situation may not be so simple, but I suggest looking the NDM process to see if there's a logic problem. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 18, 2015 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset enqueue, how to find the culprit. So, it will depend on how often the TSO message for enqueue is produced. If it is not frequent, you may have to set slips or live with rerunning the job. Or if it is frequent, you might try adding a first step with DISP=OLD on your file. then you would have a better idea of what is doing it or have the job wait until the file is freed. You did not show what type of process is being used when this occurs. So if this is REXX/CLIST that does LM functions, or an IEBCOPY, or other???? Perhaps if you could describe the process and functions being used that this condition occurred, we might provide better diags or alternatives. Lizette >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >On Behalf Of Toni Cecil >Sent: Friday, September 18, 2015 12:21 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Dataset enqueue, how to find the culprit. > >Hello, >yesterday I got the following dsn enqueue: >IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA >SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES >DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=0000, >REQUESTED DATA SET NOT AVAILABLE. >SDAB005I ALLOCATED TO ANOTHER JOB. > >Is there a way to find today, who was "locking" the pds library ?? I run DAF >tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, >but I didn't find anything, am I doing something wrong ?? Or is there any >other utility that could be more appropriate to check this "problem" ?? > >Many thx, A.Cecilio. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN