In some older releases of CICS (no longer supported), indirect links between CICS® regions were required for transaction routing across intermediate regions. In a network consisting solely of currently-available CICS systems, indirect links are only required if you are using non-VTAM® terminals. Optionally, you can define them for use with VTAM terminals. Indirect links are never used for function shipping, distributed program link, asynchronous processing, or distributed transaction processing.
The following figure shows the concept of an indirect link.
This figure illustrates a chain of systems (A, B, C, D) linked by MRO or APPC links (you cannot do transaction routing over LUTYPE6.1 links).
It is assumed that you want to establish a transaction-routing path between a terminal-owning region A and an application-owning region D. There is no direct link available between system A and system D, but a path is available via the intermediate systems B and C.
To enable transaction-routing requests to pass along the path, resource definitions for both the terminal (which may be an APPC connection) and the transaction must be available in all four systems. The terminal is a local resource in the terminal-owning system A, and a remote resource in systems B, C, and D. Similarly, the transaction is a local resource in the transaction-owning system D, and a remote resource in the systems A, B, and C.
As explained in Defining remote resources, CICS systems reference remote terminals by means of a unique identifier that is formed from:
For CICS to form the fully-qualified terminal identifier, it must have access to the netname of the TOR. In old releases of CICS (no longer supported), an indirect link definition had two purposes. Where there was no direct link to the TOR, it:
Thus, in Figure 49, the indirect link definition in system D provides the netname of system A and identifies system C as the next system in the path. Similarly, the indirect link definition in system C provides the netname of system A and identifies system B as the next system in the path. System B has a direct link to system A, and therefore does not require an indirect link.
In CICS Transaction Server for z/OS®, unless you are using non-VTAM terminals, indirect links are optional. Different considerations apply, depending on whether you are using shippable or hard-coded terminal definitions.
If several paths are available, you can use indirect links to specify the preferred path to the TOR.
If you are using non-VTAM terminals, indirect links are required. This is because you cannot use RDO to define non-VTAM terminals; the DFHTCT TYPE=REMOTE or TYPE=REGION macros used to create the remote definitions do not include an equivalent of the REMOTESYSNET option of CEDA DEFINE TERMINAL.
Thus, in CICS Transaction Server for z/OS, you may decide to define indirect links:
This section outlines the resource definitions required to establish a transaction-routing path between a terminal-owning region SYS01 and an application-owning region SYS04 via two intermediate systems SYS02 and SYS03, using indirect links.
The resource definitions required are shown in Figure 50.
The direct links between SYS01 and SYS02, SYS02 and SYS03, and SYS03 and SYS04 are MRO or APPC links defined as described earlier in this section.
Indirect links to the TOR can be defined to some systems in a transaction-routing path and not to others, depending on the structure of your network and how you have coded your remote terminal definitions. For example, if one of the intermediate systems uses hard-coded terminal definitions that do not specify REMOTESYSNET and the system does not have a direct link to the TOR, an indirect link will be required. Indirect links are never required in the system to which the terminal-owning region has a direct link.
In the current example, indirect links are defined in SYS04 and SYS03. The following rules apply to the definition of an indirect link:
The recommended methods for defining remote terminals and connections to a CICS Transaction Server for z/OS system are described in Defining remote resources.
If shippable terminals are used, no remote terminal definitions are required.
Figure 50 shows hard-coded remote terminal definitions that do not specify the REMOTESYSNET option. If you use these:
The definition of remote transactions is described in Defining remote resources.