Transfer Control (XTC) Parameters and Transfers

The Transfer Control (XTC) parameters for SYSIN01 handle dependencies between multiple interdependent transfers.
xdtz12
The Transfer Control (XTC) parameters for SYSIN01 handle dependencies between multiple interdependent transfers. For example, one transfer must complete in a certain way before another transfer can start. They provide the means by which interdependent transfer requests can be defined and processed as a single group. A transfer request belonging to such a group can cause another transfer request in the same group to be held, purged, or released (either conditionally or unconditionally) from the transfer request queue.
Transfer Control (XTC) Parameters
Several XTC parameters can be assigned up to eight values (typically, transfer request names) simultaneously. When assigning multiple values to a parameter, commas must be used to separate the parameter values:
XTC_PARAMETER=VALUE1,VALUE2,. . .,VALUE8
HOLDCOUNT
This parameter associates a number with a transfer request that is incremented or decremented by the successful or unsuccessful completion of other transfer requests. As long as the number is greater than 0, the transfer is not released.
  • 0 to 255
    Specifies a value that controls the holding/releasing of a transfer request. The transfer is released when the value of the parameter reaches 0.
See the description of the parameters XTCERRDECR, XTCERRINCR, XTCGOODDECR, and XTCGOODINCR, which can decrement and increment the value of the HOLDCOUNT parameter.
Default:
0
XTCERRDECR
This parameter specifies the transfer requests for which the HOLDCOUNT parameter value is decremented when the current transfer completes unsuccessfully.
  • Up to eight transfer request names
    If a transfer completes unsuccessfully, specifies up to eight transfers whose hold counts are to be decremented.
VTAM errors are not considered failed file transfers, because they are retried later.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCERRINCR
If the current file transfer fails, this parameter specifies the transfer requests for which the HOLDCOUNT parameter value is incremented .
  • Up to eight transfer request names
    if the current file transfer fails, specifies up to eight transfers whose hold counts are to be incremented.
A VTAM communications error does not count as a failure.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCERRPURGE
If the transfer concludes unsuccessfully, this parameter specifies the transfer requests to be purged.
  • Up to eight transfer request names
    If the current file transfer concludes unsuccessfully, specifies up to eight transfers to be purged.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCERRREL
If the current transfer completes unsuccessfully, this parameter specifies the transfers to be released.
  • Up to eight transfer request names
    If the current transfer completes unsuccessfully, specifies up to eight transfers to be released.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCGOODDECR
If the file transfer completes successfully, this parameter indicates an XTCNET job whose hold count decrements.
  • Up to eight transfer request names
    Specifies up to eight transfers whose hold counts are to be decremented if the current transfer completes successfully.
If the current file transfer completes successfully, the value of the HOLDCOUNT parameter of the transfers that are assigned to this parameter is reduced by one, unless the next transfer has already started or the HOLDCOUNT value has already reached zero.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCGOODINCR
This parameter indicates the transfer requests whose HOLDCOUNT parameter is incremented when the current file transfer completes successfully.
  • Up to eight transfer request names
    Specifies up to eight transfers whose hold counts are to be incremented if a transfer completes successfully.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCGOODPURGE
This parameter specifies the transfer requests to be purged when the current file transfer completes successfully.
  • Up to eight transfer request names
    If a transfer completes successfully, specifies up to eight jobs to be purged .
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCGOODREL
If the current file transfer concludes successfully, this parameter specifies the transfer requests to be released.
  • Up to eight transfer request names
    If a transfer completes successfully, specifies up to eight jobs to be released.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCJOB
This parameter defines the name of a transfer request belonging to the group of interdependent transfer requests named through the XTCNET parameter.
  • xxxxxxxx
    Specifies the name of a transfer request in a group of interrelated transfer requests.
Default:
z/OS job name of the z/OS job requesting the file transfer
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
XTCNET
This parameter defines the name of a group of interdependent transfer requests.
  • xxxxxxxx
    Specifies up to eight alphanumeric characters representing the name of the XTC network running this transfer.
When using the XCOMPLEX, all transfers with the same XTCNET value are distributed to the same XCOMPLEX Worker Server.
When using the PLEXQ, all transfers with the same XTCNET value are distributed to the same worker server within the PLEXQ group.
You can use symbolic variables with this parameter in batch SYSIN01. For more information, see Symbolic Parameters.
Coding Interdependent Transfers
This section explains how to code a set of interdependent transfers in the SYSIN01 DD statement.
  • The SYSIN01 parameter NEWXFER is used at the beginning of each of the multiple transfer requests as shown in the following diagram:
    JOBNAME . . . //STEP1. . . PGM=XCOM,PARM=('parm=parm_value') . . . //SYSIN01 DD * transfer request 1 parameters NEWXFER XCOMJOB JCL SYSIN01 transfer request 2 parameters The NEWXFER parameter is used in the SYSIN01 DD statement to signal the beginning of each new transfer request 1,2,...i. NEWXFER transfer request i parameters /* //
  • The parameter XTCNET is used to indicate which transfer requests belong to the same group (are dependent on each other). Suppose, for example, that the transfers XFER1, XFER2 and XFER3 are grouped together. Accomplished this by simply assigning the name of the group (say, GROUP1) to XTCNET and including XTCNET=GROUP1 in the definition of each of the three transfer requests. If XTC transfers are requested using the XCOMPLEX, the XCOMPLEX Admin Server distributes all transfers with the same value for XTCNET to the same XCOMPLEX Worker Server. If XTC transfers are requested using the PLEXQ, all transfers with the same value for XTCNET are distributed to the same server within the PLEXQ group.
  • Each interdependent transfer request must have a unique name, which is assigned to the XTCJOB parameter. Thus, if XFER1, XFER2 and XFER3 are the names of three interdependent transfer requests, their definitions in SYSIN01 must contain the parameter XTCJOB=XFER1, XTCJOB=XFER2, and XTCJOB=XFER3, respectively.
  • XTC parameters other than XTCNET and XTCJOB are used to indicate the dependencies obtaining between the transfer requests. The outcome of a transfer request can affect as many as eight other transfer requests. In addition to the XTC parameters, other SYSIN01 parameters can (and some, for example, the local file name or LFILE, must) be used when defining interdependent transfer requests.
  • HOLD=YES must be coded in each transfer request that is dependent on the successful/unsuccessful completion of another transfer request. However, HOLD=YES do not need to be coded if the holding/releasing of the transfer request is controlled by the HOLDCOUNT parameter - shown following.
Example
The following sample definition contains three interdependent transfer requests:
//SYSIN01 DD * NEWXFER /*Transfer request 1 follows*/ TYPE=SEND FILE=A.B.C LFILE=MY.FILE1 XTCNET=METS XTCJOB=PAYROLL HOLD=YES NEWXFER /*Transfer request 2 follows*/ TYPE=RECEIVE FILE=YOUR.FILE LFILE=MY.FILE2 XTCNET=METS XTCJOB=PAYME HOLD=YES NEWXFER /*Transfer request 3 follows*/ TYPE=SEND FILE=PC.FILE LFILE=MY.PC.FILE1 XTCNET=METS XTCJOB=GETDATA XTCGOODREL=PAYROLL XTCGOODPURGE=PAYME XTCERRPURGE=PAYROLL XTCERRREL=PAYME /* //
In this example, the three transfer requests are identified as GETDATA, PAYME, and PAYROLL, and they belong to the group METS. Of these, GETDATA is the parent transfer request, that is, the request that tries to execute first and the execution of which controls the subsequent execution of the other two (dependent) transfer requests. Four XTC parameters (other than XTCNET and XTCJOB) are associated with the transfer request GETDATA. XTCGOODREL=PAYROLL means that the PAYROLL transfer belonging to the same group (METS) as GETDATA is to start if GETDATA completes successfully.
At the same time, the PAYME transfer is to be purged from the transfer request queue (XTCGOODPURGE=PAYME). However, if GETDATA does not complete successfully, then the PAYROLL transfer is to be purged (XTCERRPURGE=PAYROLL) and the PAYME transfer is to start (XTCERRREL=PAYME).
TYPE=SCHEDULE is required for XTC transfer requests.
Coding XTC Transfers in an XCOMPLEX Environment
When submitted to the Admin server or PLEXQ group, all XTC transfers within an SYSIN01 input are routed and scheduled to the same server. This server is selected for the first XTC transfer in this group.
TYPE=SCHEDULE XTC transfers submitted through the XCOMPLEX Admin or PLEXQ Group must have XTCJOB and XTCNET names that are unique to the submitted XCOMJOB.
Use an individual's z/OS TSO log in ID as the XTCNET name to verify that it is unique.
All transfers within each SYSIN01 are executed, released, or purged, and cannot be extended into subsequent SYSIN01s. The transfers cannot be extended because new transfers may be scheduled by the Admin to a server other than the one chosen for the initial SYSIN01.
When using XTC to submit multiple jobs or job steps with the same XTCNET and XTCJOB names, submit directly to the CA XCOM server. Submitting directly ensures that they go to the same CA XCOM Server.
At the end of each XTC run, ensure that there are no XTC transfers left in HOLD status. Use the CA XCOM Data Transport DELETE or RELEASE operator commands to do this. For more information, see the Operation and Control section.
Go into the appropriate servers and use the CA XCOM Data Transport SHOW command to check for any left over XTC transfers before resubmitting an XTC transfer job. Use this procedure to clean up any transfers in HOLD status.