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
