As others have pointed out, enqueue is often a fleeting problem. By the time you get around to looking into it, it's long gone. After experiencing this problem a while back, we instructed our automation product to issue a D GRS command at the time of the conflict based on msgid IKJ56225I.
IKJ56225I DATA SET already-in-use-dataset ALREADY IN USE, TRY LATER+ IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER D GRS,RES=(*, already-in-use-dataset) If you decide to implement a similar process, be aware of some gotchas. (1) The msgid appears twice. If you're not careful, you'll be issuing D GRS for dataset 'IS'. Not a big deal, but it looks squirrelly. (2) The command itself might be issued too late to capture the contention. It can happen, for instance, that a task is actually enqueuing on itself (!). If the task terminates upon the enqueue, D GRS will find no contention. As odd as this sounds, we have seen cases like this. . . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steely, Mark Sent: Friday, September 18, 2015 9:47 AM To: [email protected] Subject: Re: Dataset enqueue, how to find the culprit. I created a REXX called WHI (who has it). Here is the code: PROC 1 DSN /* CLRSCRN */ ISRDDN E &DSN Then in 3.4 enter WHI and it will display any enqueue. Thanks -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jousma, David Sent: Friday, September 18, 2015 11:25 AM To: [email protected] Subject: Re: Dataset enqueue, how to find the culprit. Sorry, you have to hit PF1 twice to get the display I mentioned. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jousma, David Sent: Friday, September 18, 2015 12:23 PM To: [email protected] Subject: Re: Dataset enqueue, how to find the culprit. One of the quickest ways, is to go to ISPF option 3.4, and pull up that dataset, and do a "R" to rename it(don’t really rename it though). When it says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on it. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Toni Cecil Sent: Friday, September 18, 2015 12:21 PM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
