XCOMJOB DD Statements

Explains the DD statements used in XCOMJOB JCL
xdtzos
This section explains the DD statements used in XCOMJOB JCL.
LCLDS01
Defines the local data set available for the transfer request.
The preferred alternative to using the LCLDS01 DD statement is to define the data set using the LFILE parameter in the SYSIN01 DD statement (see below). If you enter both the LCLDS01 DD statement and the SYSIN01 LFILE parameter, the LFILE parameter takes precedence.
You should use the LFILE SYSIN01 keyword parameter to specify the local file name for TYPE=SCHEDULE transfers. While you can specify the local file name using the LCLDS01 DD statement even for TYPE=SCHEDULE transfers, there are several potential complications to consider:
  • When LCLDS01 is used to reference a local file for a transfer, the z/OS JCL processor is involved in the data set allocation process for the transfer. It is possible to encounter problems with data set enqueues being held by z/OS allocation routines while the transfers are being scheduled.
  • If the transfer begins to run on the started task before the job scheduling transfer ends, the data set may not be available for exclusive use by the CA XCOM Data Transport started task. This may cause the transfer to fail due to an unavailable exclusive enqueue.
  • Using LCLDS01 to reference a local file for a transfer may also lead to the creation of dummy GDGs.
    If the LCLDS01 DD is used to create a +1 GDG version for a TYPE=SCHEDULE transfer there are additional potential problems:
    • When the z/OS JCL performs the allocation of the LCLDS01 DD, it allocates and potentially catalogs the new version, depending on the value of the DISP parameter in the JCL. This new version does not have an end-of-file mark because it has not yet been opened and closed by a program.
    • When the transfer begins on the CA XCOM Data Transport started task, it allocates a new +1 version of the GDG. In cases where the transfer is successful, this results in the creation of two new generations of the GDG. The first version contains garbage because it was allocated by the z/OS JCL processor and was never opened or closed by a program to write an end-of-file mark. If the transfer fails, under certain conditions the version allocated by the CA XCOM Data Transport started task may be deleted. This leaves the version of the GDG allocated by the z/OS JCL processor as the current version.
All of these potential problems can be avoided if the LOCAL FILE name is specified on the LFILE SYSIN01 parameter, rather than with the LCLDS01 DD statement for TYPE=SCHEDULE transfers.
The LCLDS01 DD statement permits sequential data sets to be concatenated for TYPE=EXECUTE requests. Other types of data sets cannot be concatenated.
If it is necessary to send more than one data set to the same remote file using non-sequential data sets or if the transfer is a TYPE=SCHEDULE request, the CA XCOM Data Transport Transfer Control (XTC) facility should be used (see the sections SYSIN01 Transfer Control (XTC) Parameters and Coding Interdependent Transfers).
The SYSOUT keyword cannot be used in this DD statement.
JOBLIB or STEPLIB
Defines the library containing CA XCOM Data Transport load modules and, if CA XCOM Data Transport is used with the TCP/IP option, the Language Environment libraries.
A JOBLIB or STEPLIB statement should be included to identify the CA XCOM Data Transport load library. If you are using CA XCOM Data Transport with the TCP/IP option, the Language Environment libraries must be concatenated next.
This DD statement is not required if CA XCOM Data Transport is in the LNKLST concatenation.
SYSIN01
Defines all of the CA XCOM Data Transport parameters associated with a file transfer request. Required.
SYSPRINT
Identifies the data sets used for TCP/IP messages.
SYSTCPD
Provides information about the configuration of the TCP/IP protocol. This information is used by TCP/IP to define parameters such as DNS server resolution.
XCOMGLOB
Records the current request number of an immediate transfer (that is, TYPE=EXECUTE). When the XCOMGLOB DD statement for a TYPE=EXECUTE transfer is missing, the request number always defaults to 2000. Sites can share this data set between jobs to ensure that all TYPE=EXECUTE transfers are assigned a unique request number. To update the request number for immediate transfers from TSO/ISPF, the XCOMGLOB and XCOMREST allocated files must be in the user's TSO logon procedure. CA XCOM Data Transport ignores the XCOMGLOB DD statement when queued transfers (TYPE=SCHEDULE) are initiated.
To use this facility, create a fixed-block sequential data set containing an 80-byte record. It is recommended that this file be included when running TYPE=EXECUTE transfers utilizing the checkpoint/restart feature, to ensure that the request number is unique. This allows the session partner to correctly identify the checkpoint data when an interrupted transfer is restarted.
The same global data set should be used for all TYPE=EXECUTE job streams that run under the same ACBNAME.
XCOMHOUT
Records the History records retrieved by a TYPE=HISTORY job stream.
If requested by use of the HISTORY_WRITE parameter in the default options table, XCOMHOUT also records the transfer requests for TYPE=INQUIRE jobs. You can share this data set between TYPE=INQUIRE jobs for your site to ensure that all transfer requests from individual TYPE=INQUIRE jobs are recorded in a common XCOMHOUT to be used to generate a report.
To use this facility, create a fixed block sequential data set containing an 8080-byte record. For more information, see the sample TYPE=HISTORY JCL in the appendix Sample Files.
You can change the XCOMHOUT DD name by specifying an alternate DD name, using the HISTORY_OUT_DD parameter in the default option table.
XCOMHOVR
Records the History DDL statements needed to update the ODBC history database in the event the database is unavailable.
The records in this data set can be used with SPUFI or another DB2 utility to insert history data into the history database.
XCOMINIT
XCOMINIT is a dynamically allocated sysout dataset that provides the Default Options and EXEC override parameters being used by the XCOM task or by XCOMJOB. XCOMINIT is dynamically allocated during the initialization of the XCOM task and it is closed once the initialization is complete.
XCOMINQ
Records the request numbers for TYPE=SCHEDULE transfers.
XCOMLOG
Records all pertinent activity that takes place in the server or batch job.
This data set is created dynamically by CA XCOM Data Transport as a SYSOUT data set, using the output class as specified by the LOGCL configuration parameter. Specifying a DD statement for XCOMLOG in the server or batch job requires that a DCB or BLKSIZE be specified. The LRECL and/or BLKSIZE value must be a minimum of 133 to prevent truncation of data.
XCOMPRNT
Records the IEBCOPY output when doing PDSE (PROGLIB=YES) transfers.
XCOMREST
Records the restart information for TYPE=EXECUTE file transfers. If a file transfer fails due to a restartable condition, the XCOMREST file holds the information to restart the file transfer request from the last checkpoint. If you enter the XCOMREST DD statement in the JCL, CA XCOM Data Transport supports the restart of the TYPE=EXECUTE request.
The XCOMREST DD statement is not used with TYPE=EXECUTE transfers that have specified CONTINUE=YES. In the PARM statement, with one or more NEWXFER statements in the SYSIN01 data set. Such requests cannot be restarted in a reliable manner.
This data set is one record, a sequential file, and must not be a member of a PDS. A unique XCOMREST data set is required for each transfer. See CAI.CBXGJCL(DEFQSAM) for the sample.