Coding XTC Transfers Using the XCOMPLEX
Article ID: 56351
Updated On:
Products
Issue/Introduction
This document explains how Interdependent transfers (XTC transfers) should be coded in an XCOMPLEX environment and how the XCOMPLEX Admin server handles them. All the information in the following paragraphs is specific to XTC transfers in the XCOMPLEX environment.
Environment
Release: 12.0
Component: XCMVS
Resolution
All XTC transfers in the same SYSIN01 input will be routed and scheduled to the same server. Users who submit TYPE=SCHEDULE XTC transfers using the XCOMPLEX Admin must make sure that the XTCJOB name(s) and XTCNET name(s) they select are unique to the XCOMJOB that's being submitted. A suggestion would be to use an individual's z/OS TSO signon id as the XTCNET name to make sure it is unique for that user.
All transfers within each SYSIN01 must be executed, released or purged and may not be extended into subsequent SYSIN01s because new transfers may be scheduled by the Admin to a server other than the one chosen for the initial SYSIN01. Users who need to submit multiple jobs or jobsteps using XTC with the same XTCNET and XTCJOB names can do so by submitting them directly to the CA-XCOM server of their choice thereby ensuring that they all go to the same CA-XCOM SERVER.
It is the user's responsibility to make sure no XTC transfers are left in HOLD status at the end of each XTC run. Users should cleanup any XTC transfer left in HOLD status (either due to coding or logic errors) by using the CA-XCOM DELETE or RELEASE operator commands as documented in Chapter 6 Operation and Control of the CA-XCOM Data Transport for z/OS User Guide.
If it is necessary to resubmit the same XTC transfer job due to errors or because it is run on a periodic basis, it is always a good practice to go into the appropriate servers and use the CA-XCOM SHOW command to check for any left over XTC transfers and use the above procedure to clean them up first.
Feedback
