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