XCOM Data Transfer experiencing dataset contention

Recently, we encountered an issue where an XCOM data transfer from a production batch job was failing due to dataset contention. At first glance, this was puzzling—because the dataset involved was used by only this single job. This post walks through the root cause of the problem and the simple yet effective solution, with reference to JCL behavior.
 
Job Overview
 
The batch job in question consisted of the following steps:
 
Step 1 – Delete the dataset TEST.XCOM.FILE
Step 2 – Executes some COBOL program to create TEST.XCOM.FILE
Step 3 – Perform XCOM data transfer using TEST.XCOM.FILE
Step 4 – Send an email with TEST.XCOM.FILE as an attachment
 
Importantly, no other job uses TEST.XCOM.FILE.
 
So the natural question arises:
 
How can an XCOM data transfer run into dataset contention when the job that created the file is the one initiating the transfer?
 
 
The Unexpected Cause of Contention
 
The key lies in how XCOM handles data transfer requests.
 
The XCOM step in the job (Step 3) does not perform the data transfer synchronously. Instead, it submits the transfer request to the XCOM started task and immediately completes. This allows the job to continue executing Step 4 without waiting for the actual data transfer to finish.
 
While Step 4 was running—sending an email and attaching TEST.XCOM.FILE—the XCOM started task attempted to access the same dataset to perform the transfer. At this point, the dataset was still held by the job in exclusive mode, resulting in contention and a failed transfer.
 
Why the Dataset Was Still Locked
 
This behavior is clearly explained in the JCL Language Reference Manual, specifically in Chapter 12.19 (DISP parameter).
 
Key points from the manual:
 

• Before a job starts, the initiator issues an ENQ (enqueue) for every dataset used in the job.

• The highest level of control required by any step determines the ENQ type:

• DISP=SHR → Shared (SHR)

• DISP=NEW, MOD, or OLD → Exclusive (EXCL)

• ENQs cannot be downgraded during job execution.

• The ENQ is released only at the end of the last step that references the dataset.

 
Since the job creates TEST.XCOM.FILE, it had exclusive (EXCL) control over the dataset.  Because Step 4 also references TEST.XCOM.FILE, the ENQ remains held until Step 4 completes.
 
As a result, when the XCOM started task attempted to transfer the file, the dataset was still exclusively locked by the job itself.
 
The Solution
 
The fix was straightforward:
 
✅ Move the XCOM data transfer step to the very end of the job.
 
By doing so:

• When the XCOM started task begins the actual transfer, the dataset is no longer held by the job.

• The transfer proceeds without contention.