Ok, so you are doing a REPRO ODS, not OFILE, like you had stated, I would try 
to have the VSAM file allocated with DISP=OLD and doing the repro OFILE, I 
believe that should guarantee you don't get the "DATASET IN USE BY ANOTHER 
TASK" message.

Considering you free the dataset from the CICS region, you should be able to 
DISP=OLD it.

Regards,
Leo

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Lizette Koehler
Sent: Monday, February 15, 2016 12:42 PM
To: [email protected]
Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

So, the step previous is a DFSORT Step.  Then the IDCAMS REPRO step

The SYSS.HISTTEMP.BKUP is the data that will be reloaded back into the 
SYSS.HISTFILE.  The sort step is just to put the records in correct sequence 
before reloading.

                   
//STEP1G   EXEC PGM=SORT,COND=(0,LT)                              
//SORTIN   DD   DSN=SYSS.HISTTEMP.BACKUP,DISP=SHR         
//SORTOUT  DD   DSN=SYSS.HISTTEMP.BKUP,DISP=SHR         
//SYSOUT   DD   SYSOUT=*  
  (sort statements removed)
/*                                        
//STEP1H   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
REPRO IDS(SYSS.HISTTEMP.BKUP)        -            
      ODS(SYSS.HISTFILE) REUSE


As I stated, this runs 99% successfully.  Just one or two times a year does it 
get the message in use by another task.


Lizette



> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] 
> On Behalf Of Leonardo Vaz
> Sent: Monday, February 15, 2016 10:05 AM
> To: [email protected]
> Subject: Re: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR?
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] 
> On Behalf Of Lizette Koehler
> Sent: Monday, February 15, 2016 11:53 AM
> To: [email protected]
> Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS
> 
> I have an issue where an STC holds a VSAM Dataset.  The STC is a 
> scheduling software that writes all of the info on jobs 
> running/completed/failed and so forth, to this file.
> 
> Once per day we close and free the VSAM file from the STC, run an 
> archive process and then re-open then file to the STC.
> 
> This works nearly all of the time.  However, on occasion (a couple 
> times a
> year) the job will fail in the IDCAMS Step with DATASET IN USE BY 
> ANOTHER TASK message.  The enq is so fast, I do not have any 
> indication of what was holding it.
> The IDCAMS Step reloads the history file with the last 3 days' worth 
> of information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)
> 
> 
> I opened an SR to IBM DFSMS and asked if they could add some checks in 
> IDCAMS for the nonzero return code from the enq and let me know what job is 
> using it.
> They indicated that extra code path to do that would not help.  They 
> felt that the enq is released so soon the extra test for the enqueue 
> would not provide the name of the task.
> 
> I have looked at RMF reports - I could see nothing.
> I have looked at DAF reports for the 5 min time frame - I could see nothing.
> When the step fails with RC12, I do the D GRS,C and nothing shows up.
> I am tempted to start the ISG Monitor for Enqueues for the 15 minute 
> window when this job runs.
> 
> If we rerun the job it is successful.
> 
> Anyone have any other ideas to try and trap this rascally rabbit?
> 
> 
> 
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth 
> inaccurately

----------------------------------------------------------------------
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

Reply via email to