Start a task at a specified time.
START >>-START--TRANSID(name)-----------------------------------------> .-INTERVAL(0)------------------------. >--+------------------------------------+--+-------------+------> +-INTERVAL(hhmmss)-------------------+ '-REQID(name)-' +-TIME(hhmmss)-----------------------+ | .-------------------------. | | V | | +-AFTER----+-HOURS(data-value)---+-+-+ | +-MINUTES(data-value)-+ | | '-SECONDS(data-value)-' | | .-------------------------. | | V | | '-AT----+-HOURS(data-value)---+-+----' +-MINUTES(data-value)-+ '-SECONDS(data-value)-' >--+----------------------------------------------+-------------> '-FROM(data-area)--LENGTH(data-value)--+-----+-' '-FMH-' >--+--------------------+--+-------------------+----------------> +-TERMID(name)-------+ '-SYSID(systemname)-' '-USERID(data-value)-' >--+----------------+--+---------------+--+-------------+-------> '-RTRANSID(name)-' '-RTERMID(name)-' '-QUEUE(name)-' >--+---------+--+---------+------------------------------------>< '-NOCHECK-' '-PROTECT-'
Conditions: INVREQ, IOERR, ISCINVREQ, LENGERR, NOTAUTH, RESUNAVAIL, SYSIDERR, TERMIDERR, TRANSIDERR, USERIDERR
Note for dynamic transaction routing: If a START is later canceled by another task, or if the started transaction uses RETRIEVE WAIT, intertransaction affinities might be created that adversely affect the use of dynamic transaction routing. For more information, see Affinity.
START starts a task, on a local or remote system, at a specified time. The time is specified by INTERVAL, AFTER, AT, or TIME. See the section about expiration times in Interval control.
The starting task can pass data to the started task. The starting task can also specify a terminal to be used by the started task as its principal facility.
The default is INTERVAL(0), but for C the default is AFTER HOURS(0) MINUTES(0) SECONDS(0).
CEDF is an exception to the START command and is not valid as a TRANSID name. Therefore, do not attempt to start CEDF in this way.
You can use the RTRANSID, RTERMID, and QUEUE options to pass further data to the started task. These options can contain arbitrary data values with meanings that depend on what is specified in the started and starting tasks. One possible way of using them is in the following situation. One task can start a second task, passing it a transaction name and a terminal name to be used when the second task starts a third task. The first task can also pass the name of a queue to be accessed by the second task.
If you are using an IPIC connection, the maximum length for the FROM data area is 32,500 bytes. This limit allows for the 32,500 byte FROM data area and space for headers.
START with TERMID specified does not propagate the origin data record (ODR), so tasks are always started at a new point of origin.
Running a START command that names a transaction in the local system cancels any outstanding POST commands run by the starting task.
You can queue START commands by specifying the LOCALQ option on the RDO TRANSACTION resource definition, as described in TRANSACTION attributes.
If data is to be passed by interval control (by using the FROM option), it is queued on a temporary storage queue. Use the REQID option to specify the name of the temporary storage queue to be used. This identifier might be recoverable (in temporary storage terms) or unrecoverable. For more information on how to define recoverable temporary storage queues, see TSMODEL resources.
If you also specify the PROTECT option, you must define the temporary storage queue identified by the REQID option as recoverable. If you do not specify the PROTECT option, do not define the temporary storage queue as recoverable. Unpredictable results can occur if you do not follow these rules. See START requests .
If you specify the FROM and not the REQID option, a default 'DF' prefix temporary storage queue is used. The same rules apply as previously listed; specify the PROTECT option only if you define the 'DF' prefix temporary storage queues as recoverable.
A START command with REQID, issued from a task that was itself initiated by a START with the same REQID, returns an AEIQ abend (IOERR condition) if the FROM data for the task has not been read by a RETRIEVE.
You also receive this error if more than one START command with the same REQID is issued by a task or tasks in the same CICS system. CICS TS regions always reject with an IOERR any START commands that specify a duplicate REQID.
Started tasks without data run without a facility address. Started tasks with data run with a facility address of an ICE until the data is retrieved.
If an ICRX is used, it is saved across restarts. If the start request is subsequently cancelled, the ICRX is deleted.
The NOCHECK option specifies that no response (to running of the START command) is expected by the starting transaction. For START commands that name tasks to be started on a local system, error conditions are returned; error conditions are not returned for tasks to be started on a remote system. The NOCHECK option allows CICS to improve performance when the START command must be shipped to a remote system; it is also a prerequisite if the shipping of the START command is queued pending the establishing of links to the remote system.
EXEC CICS START
TRANSID('TRNL')
INTERVAL(10000)
REQID('NONGL')
⋮
EXEC CICS START
TRANSID('TRNL')
AFTER HOURS(1)
REQID('NONGL')
⋮
Only one task is started if several START commands, each specifying the same transaction and terminal, expire at the same time or before the terminal is available.
EXEC CICS START
TRANSID('TRN1')
TIME(185000)
TERMID('STA5')
⋮
EXEC CICS START
TRANSID('TRN1')
AT HOURS(18) MINUTES(50)
TERMID('STA5')
⋮
Data is passed to a started task if one or more of the FROM, RTRANSID, RTERMID, and QUEUE options is specified. Such data is accessed by the started task by using a RETRIEVE command.
It is possible to pass many data records to a new task by issuing several START commands, each specifying the same transaction, and terminal.
Running of the first START command ultimately causes the new task to be started and allows it to retrieve the data specified on the command. The new task is also able to retrieve data specified on subsequent START commands that expire before the new task is ended. If the transaction has been defined as restartable (by defining the transaction as using the RDO option RESTART(YES)) and such data has not been retrieved before the new task is ended, another new task is started and can retrieve the outstanding data.
If the transaction abends and has not been defined as restartable, no new task is initiated and the data is discarded.
EXEC CICS START
TRANSID('TRN2')
TIME(173000)
TERMID('STA3')
REQID(DATAREC)
FROM(DATAFLD)
LENGTH(100)
⋮
EXEC CICS START
TRANSID('TRN2')
AT HOURS(17) MINUTES(30)
TERMID('STA3')
REQID(DATAREC)
FROM(DATAFLD)
LENGTH(100)
⋮
When you use the C language, use the AFTER/AT HOURS, MINUTES, and SECONDS options because C does not provide a packed decimal data type. You can use INTERVAL or TIME, but if the value specified is not an integer constant, the application is responsible for ensuring that the value passed to CICS is in packed decimal format.
Some transactions started by a subset of START commands can be dynamically routed to a remote region. For general information about dynamic transaction routing, and specific information about which transactions started by START commands are eligible for dynamic routing, see Routing transactions invoked by START commands.
These exposures result from the delay between the running of the START command and the time of task creation. Even when the START is immediate, CICS can delay creating the task, either because the required terminal is not free or because of other system constraints.
You can use INQUIRE commands to ensure that the transaction and program are enabled at the time of the START command, but either might become unavailable before task creation.
You get a TERMIDERR condition if the requested terminal does not exist at the time of the START, but if it is deleted later, as occurs if the user logs off, your START request is discarded with the terminal definition.
Application context propagation is a process that passes application context data from a task that issues a START command to a task that runs the started transaction. The data is used for monitoring and measuring application resource usage. Application context data is not propagated with the following START commands:
For more information, see Application context and Scenarios that do not support application context propagation.
If you are also specifying REQID, make sure that the name of the REQID and the name of the QUEUE are not the same.
If you omit this option, CICS generates a unique request identifier in the EIBREQID field of the EXEC interface block, unless you specify the NOCHECK option, in which case field EIBREQID is set to nulls and cannot be used later to cancel the START command.
If you include any of the data options (FROM, RTERMID, RTRANSID, or QUEUE), the data is stored in a TS queue by using the REQID name specified (or CICS generated) as the identifier. The queue record thus identified must be local to the CICS system where the START command is processed. The START command is processed on the system identified by the SYSID option or, if the SYSID option is omitted, on the system associated with the TRANSID option.
When retrieved, the value can be used in the TERMID option of a subsequent START command.
When retrieved, the value can be used in the TRANSID option of a subsequent START command.
Define the terminal identifier as either a local or a remote terminal on the system in which the START command is run when the start of the transaction takes effect.
The TERMID option is used in previous hop data that is collected. For more information about using the TERMID option with previous hop data, see Previous hop data characteristics.
Do not use the TERMID option if you are using identity propagation.
When using the C language, use the AFTER/AT HOURS, MINUTES, and SECONDS options because C does not provide a packed decimal data type. You can use TIME, but if the value specified is not an integer constant, the application is responsible for ensuring that the value passed to CICS is in packed decimal format.
If you specify SYSID and name a remote system, the transaction is assumed to be on that system whether the transaction is defined as remote. Otherwise, the transaction resource definition is used to find out whether the transaction is on a local or a remote system.
The TRANSID option is used in previous hop data that is collected. For more information, see Previous hop data characteristics.
If you omit both TERMID and USERID, CICS uses instead the user ID under which the transaction that issues the START command is running. This user ID is referred to as userid2.
By using either userid1 or userid2, CICS ensures that a started transaction always runs under a valid user ID, which must be authorized to all the resources referenced by the started transaction.
CICS performs a surrogate security check against userid2 to verify that this user is authorized to userid1. If userid2 is not authorized, CICS returns a NOTAUTH condition.
If you are using identity propagation, and your task has a distributed user ID associated with its security context, this information is not propagated to tasks that are started with the USERID option.
Default action: end the task abnormally.
Default action: end the task abnormally.
Default action: end the task abnormally.
Default action: end the task abnormally.
The security access capabilities of the transaction that issued the command do not allow the command to be performed with the value specified in the USERID option. The security access capabilities of the transaction have been established by the external security manager according to user security, and whether link security or the execution diagnostic facility (EDF) have been in use.
Default action: end the task abnormally.
RESUNAVAIL is returned on the EXEC CICS START command run by the mirror in the target region, if an XICERES global user exit program indicates that a required resource is unavailable on the target region. It is not returned to the application.
Default action: reinvoke the distributed routing program for route selection failure.
Default action: end the task abnormally.
Default action: end the task abnormally.
Default action: end the task abnormally.
Default action: end the task abnormally.