IEFA110I DATA SET CONTENTION with MIM causes batch job abend

Products

• MIM Resource Sharing (MIM)
• MIM Data Sharing (MII)
• MIM Tape Sharing (MIA)
• MIM Message Sharing (MIC)

Issue/Introduction

A batch job ABEND occurs pointing to MIM as the reason. The JOB may use IDCAMS or other processing for the dataset but during processing it fails with these messages

IKJ56225I DATA SET USER.DATE.USERDATA ALREADY IN USE, TRY LATER 
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER 
IEFA110I DATA SET CONTENTION 
DATA SET USER.DATE.USERDATA IN USE BY 
SYSNAME JOBNAME ASID 
1234    MIM     0019 

Resolution

The only reason MIM would see the IKJ56225I / IEFA110I messages would be due to a global enq conflict. 
MIM raises a blocking ENQ locally when an external system own the ENQ. 

the display 
F MIM,D ENQR=(SYSDSN,data_set_name) 

will show you which external system truly owns the ENQ. 
The command may need to be entered on multiple systems to find the true non-MIM owner.

Additional Information

A rare timing problem has been found that may cause false global ENQ contention. CA MII's ENQ control block may represent a global ENQ as EXCL but it is really owned as SHR.
To correct this and prevent such occurrences in future, apply r12.5 PTF RO94832 

In 12.5, activating the ISGQUERY feature would return the system and jobname of the actual ENQ instead of just MIM, that holds only the local ENQ. 

Fix SO00533 should be applied to prevent any problems with the use of ISGQUERY. 
PRE's: RO90796, RO90884, RO92025, RO92131, RO93172, RO93204, RO94446, RO95874, RO96602, RO97771, RO97898, RO99744 and SO00406

IBM fix OA52423  handles a situation in which GRS does not free up a VSAM resource as it should.