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 has PARM='TYPE=SCHEDULE' which means it queues the file transfer request and ends the job step when the transfer request is queued. So, 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.

 

From the JCL Language Reference Manual, Chapter 12.19 (DISP parameter):

DISP and ENQ: Before starting the first step of a job, the initiator requests control of all of the data sets in that job by issuing an ENQ for each of them, using the value specified for DISP to determine the kind of ENQ issued. The initiator issues the ENQ for each data set at the highest level required for that data set by any step of the job. For example, if all steps of the job request shared control of a specific data set (DISP=SHR) then the ENQ for that data set is requested as SHR. If, on the other hand, any step of the job requests exclusive control of a specific data set (DISP=NEW, DISP=MOD, or DISP=OLD), then the ENQ for that data set is requested EXCL.

The ENQ for each dataset is released at the end of the last step of the job referencing it. Since ENQs cannot be downgraded from EXCL to SHR, if one step needs the ENQ EXCL and a following step only needs it SHR, the ENQ is still issued as EXCL and held until the end of the last step which references that data set, at which point the ENQ is released entirely.