Traditional routing of transactions started by ATI

You can use the traditional method of routing transactions that are started by automatic transaction initiation (ATI) for transactions where you cannot use the enhanced method.

This method of routing is superseded by the enhanced method (see Routing transactions invoked by START commands). Use the enhanced method wherever possible. However, for the following transactions, you must use the traditional method:

Transactions invoked by the trigger-level on a transient data queue
Some transactions that are invoked by EXEC CICS START commands

Automatic transaction initiation is the process where an internal transaction request in a CICS® system or systems network leads to the scheduling of the transaction. ATI requests result from the following:

EXEC CICS START commands: A START command causes CICS interval control to initiate a transaction after a specified period of time (which might be zero) has elapsed.
Transient data queues: A transient data queue can be defined so that a transaction is automatically initiated when the number of records on the queue reaches a specified level.

CICS transaction routing allows an ATI request for a transaction owned by a specific CICS system to name a terminal that is owned by another, connected system. For example, in Figure 1, an application in AOR1 issues a START request for transaction TRAA to be attached to terminal PRT1.

Although the original ATI request occurs in the application-owning region (AOR), it is sent by CICS to the TOR for execution. In the example, AOR1 sends the START request to TOR1 to be run. In the TOR, the ATI request causes the relay program to be initiated, in conjunction with the specified terminal (PRT1 in the example).

The user transaction in the AOR is then accessed in the manner described for terminal-initiated transaction routing. Associated with the request is an automatic initiate descriptor (AID) that specifies the names of the remote transaction (TRAA) and system (AOR1).

For static transaction routing, the terminal-owning region (TOR1) must find a transaction definition that specifies REMOTESYSTEM(AOR1) and REMOTENAME(TRAA). If the TOR cannot find the correct definition, the request fails.

For dynamic transaction routing using the traditional method, when DYNAMIC(YES) is coded on the transaction definition, the dynamic routing program is invoked but cannot reroute the request, because the remote system name is taken from the AID. To find out how to use the ROUTABLE option of the transaction definition to specify enhanced routing, see Routing transactions invoked by START commands.

Graphic is described in accompanying text. — Figure 1. ATI-initiated transaction routing

ATI requests are queued in the AOR if the link to the terminal-owning region is not available, and subsequently in the TOR if the terminal is not available.

The overall effect is to create a single-system view of ATI as far as the AOR is concerned; the fact that the terminal is remote does not affect the way in which ATI appears to operate.

In the AOR, the normal rules for ATI apply. The transaction can be initiated from a transient data queue when the trigger level is reached, or on expiry of an interval control start request. For transient data initiation, the transient data queue must be in the same system as the transaction. Transaction routing does not enable transient data queue entries to initiate remote transactions.