Page 1 of 1

Job fails due to contention

PostPosted: Tue May 02, 2023 1:47 pm
by Misha786
Hello -
we have a JCL (created from a skel) that has two steps.
First step : check if the dataset is catalogued or not. If, yes it gives a RC=0 and if not, it gived RC=04
second step : it runs only If first step gives RC = 04 (i.e. if the dataset is not found in catalogue). It runs IEFBR14 to allocate the given dataset.

Now, we have come across a situation where the dataset is catalogued and was being used/referred by some other jobs when our job was submitted to run.
So, as soon as we submited the job, it gets dataset contention error due to the 2nd steps code. and do not run the first step at all. It means irrespective of first steps outcome, JCL validation of 2nd step is happening the moment job gets submitted.

Please let me know how to tackle this so that job does not get the contention and 2nd step's validation happens only at the basis of first steps RC=04 as per the IF condition.

Here is the JCL
//LOCN1  EXEC PGM=SULOCATE,              
//      PARM='/GW.CAP1.CATS.LOAD,RC=04'  
//SYSPRINT  DD SYSOUT=*                  
//NWLOC  IF LOCN1.RC = 4 THEN            
//ALLOC1 EXEC  PGM=IEFBR14              
//FILE1  DD  DSN=GW.CAP1.CATS.LOAD,      
//          DISP=(NEW,CATLG),            
//          UNIT=DISK,                  
//          LIKE=GW.CAP1.CATS.PROD.LOAD,
//          DSNTYPE=LIBRARY              
//NWLOC ENDIF                            


Here is the error
IEF677I WARNING MESSAGE(S) FOR JOB P53DS  ISSUED          
 $HASP373 P53DS  STARTED - INIT 25   - CLASS M        - SYS
 ACF9CCCD USERID GBQW     IS ASSIGNED TO THIS JOB - AB35DEM  
*MIM1040I P53DS WAITING FOR RESOURCES                      
 MIM1038I P53DS JOB00543 A=008E T=7F8058 contention with BCI
 MIM1039I P53DS JOB00543 A=008E T=7F8058 needs EXCL SYSDSN J
 MIM1038I P53DS JOB00543 A=008E T=7F8058 contention with BCI
 MIM1039I P53DS JOB00543 A=008E T=7F8058 needs EXCL SYSDSN J
*MIM1040I P53DS WAITING FOR RESOURCES FOR .7 MINUTES        
 $HJOB00543                                                  
 $EJOB00543                                                  
 $CJOB00543                                                  
 IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO GBQW
 IEF863I DSN = GW.CAP1.CATS.LOAD P53DS RC = 04 RSN =
*IEF099I JOB P53DS  WAITING FOR DATA SETS  

Re: Job fails due to contention

PostPosted: Tue May 02, 2023 6:37 pm
by Robert Sample
IEFBR14 does not open a data set, so it cannot ever have contention. You need to use a program that does open the data set.

Re: Job fails due to contention

PostPosted: Tue May 02, 2023 7:04 pm
by Misha786
Hi Robert :
I did not understand what do you mean by "IEFBR14 does not open a data set, so it cannot ever have contention". Sorry about it.
But, We had a pgm before to perform this operation. Our team replaced it with IEFBR14 in mid of last month. And, now after 16 days customer has come across this situation. Backing out the changes after 16 days of implementation would cost us huge. So, trying to find something in the JCL itself to address this issue.
Any help would be highly appreciated.
See what we had before
//LOCN1 EXEC PGM=SULOCATE,
// PARM='/TUTEST.R123V050.MIN.LOAD,RC=04'
//SYSPRINT DD SYSOUT=*
//NWLOC IF LOCN1.RC = 4 THEN
//ALLOC1 EXEC PGM=TUALLOC,
// PARM=('TU.C11T.PDSE.LOAD','TUTEST.R123V050.MIN.LOAD')
//STEPLIB DD DISP=SHR,DSN=TU.C11P.LOAD
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//NWLOC ENDIF
**************************** Bottom of Data

Re: Job fails due to contention

PostPosted: Tue May 02, 2023 7:21 pm
by enrico-sorichetti
IEFBR14 does not open a data set, so it cannot ever have contention.


the contention is not due to the program being run...

see the reply You gave some time ago
https://ibmmainframes.com/about53352.html

Re: Job fails due to contention

PostPosted: Wed May 03, 2023 12:58 pm
by willy jensen
The problem is that you have DISP=NEW in the second step. This has nothing to do with IEFBR14 or opening a dataset. 2 solutions that I can see, first one is going back to allocating the dataset in program, TSO batch could be used, or secondly accept that your job must wait till the other job has finished. You write "do not run the first step at all" - are you sure about that? That is not my experience.

Re: Job fails due to contention

PostPosted: Wed May 03, 2023 10:28 pm
by Misha786
yes Willy, None of the step runs !! job direct encounter the contention issue the moment it gets submitted because the file exists and it is in use by other job. See the error log screen(2nd screen in my first post).
Had the first step run, 2nd step would have bypassed due to the IF condition because 1st step would give RC=0 not 4 as the given file does exist. This would have avoided the contention issue altogether.

Assume, a pds file (GW.CAP1.CATS.LOAD in this scenrio) exists and you keep one of it's member open in 3.4. Then in another window, you try submitting the above job. it will directly hit the Contention without running any step.

Re: Job fails due to contention

PostPosted: Wed May 03, 2023 10:52 pm
by willy jensen
Glad we agree that this is the way it works and is supposed to work. So as I said, you now have 2 choices - go back to allocating the dataset in a program, or wait till the other job has finished.

Re: Job fails due to contention

PostPosted: Thu May 04, 2023 8:21 am
by Misha786
Thanks Willy !! we have temporarily backout our last month's change and working on building a new program (a clone of old pgm but with some changes to cater our specific requirement).
Thanks to Robert and Enrico as well for sharing their ideas !!
Regards,
Misha