This section describes the "traditional" method of routing transactions that are started by automatic transaction initiation (ATI). Wherever possible, you should use the enhanced method described in Routing transactions invoked by START commands. However, you cannot use the enhanced method to route:
For these cases, you must use the "traditional" method described in this section.
Automatic transaction initiation is the process whereby a transaction request made internally within a CICS system or systems network leads to the scheduling of the transaction. ATI requests result from:
CICS transaction routing allows an ATI request for a transaction owned by a particular CICS system to name a terminal that is owned by another, connected system. For example, in Figure 17, 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 AOR, it is sent by CICS to the TOR for execution. So, in the example, AOR1 sends the START request to TOR1 to be executed. 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 application-owning region 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 it cannot, the request fails. 7
For dynamic transaction routing, 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. 7
ATI requests are queued in the application-owning region if the link to the terminal-owning region is not available, and subsequently in the terminal-owning region if the terminal is not available.
The overall effect is to create a "single-system" view of ATI as far as the application-owning region is concerned; the fact that the terminal is remote does not affect the way in which ATI appears to operate.
In the application-owning region, 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. Note particularly that, 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.
A CICS system, CICA, can cause an ATI request to be executed in another CICS system, CICB, in several ways. For example:
If the ATI request has a terminal associated with it, CICB searches its resources for a definition for that terminal. If it finds that the terminal is remote, it sends the ATI request to the system that is specified in the REMOTESYSTEM option of the terminal definition. Remember that a terminal-related ATI request is executed in the TOR.
The "terminal-not-known condition" frequently occurs, as the example in this section explains, because a terminal-related START command is issued in the terminal-owning region and function-shipped to the application-owning region, where the terminal is not yet defined. If you are able to use the enhanced routing method described in Routing transactions invoked by START commands, a START command issued in a TOR is not function-shipped to the AOR; thus the "terminal-not-known" condition does not occur.
To ensure correct functioning of cross-region ATI, you could define your terminals to all the systems on the network that need to use them. However, you cannot do this if you are using autoinstall. (For information about using autoinstall, see the CICS Resource Definition Guide.) Autoinstalled terminals are unknown to the system until they log on, and you rely on CICS to ship terminal definitions to all the systems where they are needed. (See Shipping terminal and connection definitions.) This works when routing from a terminal to a remote system, but there are cases where a system cannot process an ATI request, because it has not been told the location of the associated terminal.
The example shown in Figure 18 should make this clear:
EXEC CICS START
TRANSID(X1)
TERMID(T1)
and exits.You, as user of the system, know how this routing problem could be solved, and CICS gives you a way of communicating your solution to the system. The two global user exits XICTENF and XALTENF have been provided. XICTENF is driven when interval control processes a START command and discovers the associated termid is not defined to the system. XALTENF is driven from the terminal allocation program also when the termid is not defined.
The terminal allocation program schedules requests resulting both from the eventual execution of a START command and from the transient data queue trigger mechanism. This means that a START command could result in an invocation of both exits.
The program you provide to service one or both of these global user exits has access to a parameter list containing this information:
On exit from the program, you tell CICS whether the terminal exists and, if it does, you supply either the netname or the sysid of the TOR. CICS sends the ATI request to the region you specify. As a result, the terminal definition is shipped from the TOR to the AOR, and transaction routing proceeds normally.
There is therefore a solution to the problem shown in Figure 18. It is necessary only to write a small exit program that returns the CICS-supplied parameters unchanged and sets the return code for ‘netname returned’.
The events that follow are shown in Figure 19:
The example in Figure 19 shows only one of many possible configurations. From this elementary example, you can see how to approach a solution for the more complex situations that can arise in multiregion networks.
You do not have to be using autoinstalled terminals to make use of the exits XICTENF and XALTENF. The technique also works with CEDA-installed terminals, if they are defined with SHIPPABLE(YES) specified.
It is important that, although there is no need to have all terminal definitions in place before you operate your network, all links between systems must be fully defined, and remote transactions must be known to the systems that want to use them.
The XICTENF and XALTENF exits can be used only if there is a direct link between the AOR and the TOR. In other words, the sysid or netname that you pass back to CICS from the exit program must not be for an indirectly connected system.
How your exit program identifies the TOR from the parameters supplied by CICS can only be decided by reference to your system design. In the simplest case, you would hand back to CICS the netname of the system that originated the START request. In a more complex situation, you may decide to give each terminal a name that reflects the system on which it resides.
For programming information about the exit program, see the CICS Customization Guide. A sample program is also available in the DFHXTENF member of library CICSTS31.CICS.SDFHSAMP.
Consider the following network setup:
Now consider the following scenario:
Terminal-owning region TORB issues an EXEC CICS START request for transaction TRANB, which is owned by region AOR1. It is to be run against terminal T1. Meanwhile, terminal T1 on region TORA has been transaction routing to AOR1; a definition of T1 has been shipped to AOR1 from TORA. When the START request arrives at AOR1, it is shipped to TORA, rather than TORB, for transaction routing from terminal T1.
Figure 20 illustrates what happens.
There are two ways to prevent this situation:
Use the enhanced routing method described in Routing transactions invoked by START commands. A terminal-related START command issued in the terminal-owning region is not function-shipped to the AOR; thus it cannot be shipped back to the wrong TOR. Instead, the START executes directly in the TOR, and the transaction is routed as if it had been initiated from a terminal.
A definition of the terminal is shipped to the AOR, and the autoinstall user program is called. Your autoinstall user program can then allocate an alias termid in the AOR, to avoid a conflict with the previously installed remote definition. Terminal aliases are described in topic Terminal aliases. For information about writing an autoinstall program to control the installation of shipped definitions, see the CICS Customization Guide.
Code YES on the FSSTAFF system initialization parameter in the AOR. This ensures that, when a START request is received from a terminal-owning region, and a shipped definition for the terminal named on the request is already installed in the AOR, the request is always shipped back to a TOR, for routing, across the link it was received on, irrespective of the TOR referenced in the remote terminal definition. (The only exception to this is if the START request supplies a TOR_NETNAME and a remote terminal with the correct TOR_NETNAME is located; in which case, the request is shipped to the appropriate TOR.)
If the TOR to which the START request is returned is not the one referenced in the installed remote terminal definition, a definition of the terminal is shipped to the AOR, and the autoinstall user program is called. Your autoinstall user program can then allocate an alias termid in the AOR, to avoid a conflict with the previously installed remote definition.
For full details of the FSSTAFF system initialization parameter, see the CICS System Definition Guide.
An AOR can issue an EXEC CICS START request against a terminal that is owned by a VTAM® generic resource, without knowing the member of the generic resource group to which the terminal is currently logged on. For details of using ATI with generic resources, see Using ATI with generic resources.