On a completely different tack:
What if you defined the VSAM file as ESDS, and used an AIX and PATH?
Would you still need to sort the data? Would this give you the
speed and efficiency you need and possibly solve this issue?
The only splits you would get would be in the AIX. And you could
do the whole process of repro, delete, define, repro in a single
JOB where you could do a RESTART= should it fail.
Just wondering if this would make for a single JOB to do it all
and provide other efficiencies.
Regards,
Steve Thompson
On 02/15/2016 12:42 PM, Lizette Koehler wrote:
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
