CA XCOM was designed with two ways to initiate transfers: TYPE=SCHEDULE for scheduled production jobs and TYPE=EXECUTE for one-of-a-kind transfers. With TYPE=SCHEDULE transfers, the job is scheduled to the XCOM server and the server takes care of scheduling the job and retries if needed. With TYPE=EXECUTE transfers, the user schedules the transfer which is run immediately and the user is responsible for any retries. On the ISPF panels, TYPE=SCHEDULE transfers are equivalent to queued transfers and TYPE=EXECUTE transfers are equivalent to non-queued transfers.

Release: 12.0
Component: CA XCOM Data Transport for z/OS

How does TYPE=SCHEDULE work?
When a transfer is initiated with TYPE=SCHEDULE, the transfer is scheduled to the XCOM server.

When should I use TYPE=SCHEDULE?
TYPE=SCHEDULE should be used for production jobs. It is required for any transfers where SNA parallel sessions are specified. It handles simultaneous transfer of files and the XCOM server handles any necessary retries.

I'd like to use TYPE=SCHEDULE, but we need to get back a return code.
Use TYPE=INQUIRE to get back a return code for the transfer. Refer to Determining the Return Code for TYPE=SCHEDULE Transfers Using TYPE=INQUIRE for information about how to use TYPE=INQUIRE.

How does TYPE=EXECUTE work?
The type=execute batch job performs the transfer, not the XCOM server. With few exceptions, all restart and recovery is left up to the user. The job saves information about the transfer in the XCOMGLOB DD and XCOMREST DD if they are specified, so that it can be restarted manually. TYPE=EXECUTE transfers are single-threaded and single session. The results of the transfer are in the output of the job and not recorded in the history file on the initiating side.

When should I use TYPE=EXECUTE?
TYPE=EXECUTE is best used for single transfers and for jobs that are not part of regular production runs.

Summary of differences between TYPE=SCHEDULE and TYPE=EXECUTE

TYPE=SCHEDULE	TYPE=EXECUTE
Parallel sessions	Single session
History file	Output is in the JES job log
Transfer is done in server address space	All done in the same address space
Multiple transfers simultaneously	Single threaded
Trace is turned on with Modify command	Trace is turned on with PARM=
Trace is written to server	Trace is written to the job log
TID is taken care of by the server	TID is written to XCOMGLOB DD
Recorded in the history file	Not recorded in the history file, unless a history database is used with XCOM.
Retries retryable* errors according to parameters set in the default table.	Extremely limited automatic retries

* Retryable errors are identified in the xcomlog with a # preceding the error message