Contention/allocation abend with MIM processing a jobs JCLLIB in the converter/interpreter.
search cancel

Contention/allocation abend with MIM processing a jobs JCLLIB in the converter/interpreter.

book

Article ID: 221502

calendar_today

Updated On:

Products

MIM Resource Sharing (MIM) MIM Data Sharing (MII)

Issue/Introduction

Encountering a problem with one job being submitted by scheduler product that abends with an allocation error while going through the converter/interpreter (CI) just as it's predecessor job ends on a local system.
 
System messages (IKJ56225I & IEFA110I) indicate MIM is holding the dataset. This seems to occur in CI on the "GLOBAL" LPAR while on a data set [that is part of a JCLLIB], while the predecessor job is just completing its execution on a "LOCAL" LPAR . However, this predecessor job is using the data set as output to a SYNCSORT step .
 
This appears to be a timing issue where JES has not yet cleaned up the allocation resources for the data set MOD'ed on by the predecessor job that the next job was trying to allocate via JCLLIB.
 
A rerun of the job runs fine.
 
 
JOB#2 problematic execution
STMT NO. MESSAGE
3 IEFC003I ALLOCATION ERROR IN PROCESSING A JCLLIB STATEMENT
IKJ56225I DATA SET AAAA.BBBB.PDS ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IEFA110I DATA SET CONTENTION
DATA SET AAAA.BBBB.PDS IN USE BY
SYSNAME JOBNAME ASID
SY2 MIM 0014
5 IEFC001I PROCEDURE IKJBATCH WAS EXPANDED USING SYSTEM LIBRARY SYSTEM.PROCLIB
27 IEFC017I INCLUDE GDG225 WAS NOT FOUND
30 IEFC612I PROCEDURE WINJ2250 WAS NOT FOUND
30 IEFC657I THE SYMBOL CLIB01 WAS NOT USED
 
JOB#2 normal execution
 
STMT NO. MESSAGE
5 IEFC001I PROCEDURE IKJBATCH WAS EXPANDED USING SYSTEM LIBRARY SYSTEM.PROCLIB
27 IEFC002I INCLUDE GROUP GDG225 WAS EXPANDED USING PRIVATE LIBRARY AAAA.BBBB.PDS
31 IEFC001I PROCEDURE WINJ2250 WAS EXPANDED USING PRIVATE LIBRARY AAAA.BBBB.PROCLIB
 
 
JOB#1 predecessor holding the JCLLIB on "LOCAL" LPAR.
 
//STEP006 EXEC PGM=LINKABND,
// PARM='SYNCSORT,0'
//SORTIN DD DSN=AAAA.BBBB.INPUT.DD04O,
// DISP=SHR
//SORTOUT DD DSN=AAAA.BBBB.PDS(GDG230),
// DISP=(MOD,PASS),
// UNIT=PRD,
// SPACE=(TRK,(30,1,150)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SORTWK01 DD UNIT=PRD,
// SPACE=(0,(200,500),RLSE)
//SORTWK02 DD UNIT=PRD,
// SPACE=(0,(200,500),RLSE)
//SYSOUT DD SYSOUT=(,),OUTPUT=*.ONLJCL
:
:

Environment

Release : 12.5
Component : MII

GDIF DEQPOST=AUTO

Cause

Likely a timing issue whereas the MII control file is not getting updated fast enough to reflect the ENQ on the file being released from the initial job, before the ENQ request for the next job

Resolution

Set the GDIF DEQPOST value to ALWAYS rather than AUTO.

This command is local in scope and can be done one system at a time.

SETOPTION GDIF DEQPOST=ALWAYS

Additional Information

Not aware what is actually holding the resource....See KB Article: 101873