Document ID : KB000056208
Last Modified Date : 08/10/2018
Show Technical Document Details

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.



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 KB000027731 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

Parallel sessionsSingle session
History fileOutput is in the JES job log
Transfer is done in server address spaceAll done in the same address space
Multiple transfers simultaneouslySingle threaded
Trace is turned on with Modify commandTrace is turned on with PARM=
Trace is written to serverTrace is written to the job log
TID is taken care of by the serverTID is written to XCOMGLOB DD
Recorded in the history fileNot recorded in the history file
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