We had a similar nagging problem not long ago. We got message IKJ56225I but no indication of what the problem was. It was also fleeting, so D GRS after the fact never showed the culprit. We finally automated on that message to issue D GRS,RES=(*,xxx) where xxx is taken from the IKJ56225I message. That showed the culprit immediately. Once you know who has the resource, you can take action to mitigate.
. . JO.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] From: David Devine <[email protected]> To: [email protected], Date: 03/11/2013 08:45 AM Subject: Re: Enqueue during VSAM REPRO - Who is the culprit Sent by: IBM Mainframe Discussion List <[email protected]> Hi Lizette, I think DanD hit it on the head with his suggestion about using infile & outfile dd statements instead of ids & ods. Ids & Ods use a disp of "old" during dynamic allocation. I have a sneaky feeling that your job is contending with itself because grs or mim can't always see quickly enough that the dataset is free'd after the del/def. As the message is an IKJ its implying that its all done within a TSO rexx routine and rexx is quite well know for erratic behaviour. Do you have explicit close & free's coded in your rexx for the dataset prior to the final repro? In any event, I'd suggest changing your repro to hardcoded infile outfile dd's with a disp of shr. regards, Dave *********************************************************************************************** >Sorry about the delay in responding. I had a network issue that was not resolved until now. >The correct order is >1) Allocate new VSAM Temp file >2) Split off the archive records to a GDG, and the records to be reloaded into the VSAM Temp File. >3) Del/Def the original file name >4) Repro the VSAM Temp back into the Original name >Yes, the original is the one that is enqueued. I should have used the term TEMP rather than NEW in my example. >This is a process that will archive of older records from the vsam dataset to a GDG and also create a temp VSAM data >set that holds the records to get loaded back into the file (don't ask, this is the vendor's process). >The main reason for this posting is to see if this is still annoying. That you can get the message DATA SET IN USE, but >that the process is so quick there is no trail of the holder. And from this discussion it seems this is still an issue. >Thanks for all the good commentary. >Lizette > >Sometimes (not always) when this job runs I get > > > >REPRO IDS(NEW.VSAM.FILE) - > >. ODS(CURRENT.VSAM.FILE) REUSE > >.IKJ56225I DATA SET CURRENT.VSAM.FILE ALREADY IN USE, TRY LATER > >.IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
