Defining indirect links for transaction routing

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.

Figure 49. Indirect links for transaction routing
 The picture shows a chain of four CICS regions, connected by MRO or APPC links. There is a TOR (A), two intermediate regions (B and C), and a back-end AOR (D). On the TOR, A, a transaction is defined as owned by intermediate region B. On B, it is defined as owned by the next intermediate region in the chain, C. On C, it is defined as owned by the AOR, D. On AOR D, it is defined as a local transaction. On TOR A, a terminal or connection is defined as local. On all the other regions, it is defined as remote, owned by TOR A. There are direct links between A and B, B and C, and C and D. On AOR D, there is an indirect link to A, by way of C. On C, there is an indirect link to A, by way of B.

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.

Why you may want to define indirect links in CICS Transaction Server for z/OS

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:

  1. Supplied the netname of the terminal-owning region.
  2. Identified the direct link that was the start of the path to the terminal-owning region.

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.

Shippable terminals
Indirect links are not necessary to allow terminal definitions to be shipped to an AOR across intermediate systems. Each shipped definition contains a pointer to the previous system in the transaction routing path (or to an indirect connection to the TOR, if one exists). This allows routed transactions to be attached, by identifying the netname of the TOR and the path from the AOR to the TOR.

If several paths are available, you can use indirect links to specify the preferred path to the TOR.

Note:
Non-VTAM terminals are not shippable.
Hard-coded terminals
If you are using VTAM terminals exclusively, indirect links are not required. You use the REMOTESYSNET option of the TERMINAL definition (or the CONNECTION definition, if the "terminal" is an APPC device) to specify the netname of the TOR; and the REMOTESYSTEM option to specify the next system in the path to the TOR. If several paths are available, use REMOTESYSTEM to specify the next system in the preferred path.

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:

Resource definition for transaction routing using 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.

Note:
For clarity, the figure shows hard-coded remote terminal definitions that do not use the REMOTESYSNET option (if REMOTESYSNET had been used, indirect links would not be required). Shippable terminals could equally well have been used.
Figure 50. Defining indirect links for transaction routing. Because the remote terminal definitions in SYS04 and SYS03 do not specify the REMOTESYSNET option, indirect links are required.
 The picture shows a chain of four CICS regions, connected by MRO or APPC links. There is a TOR (SYS01), two intermediate regions (SYS02 and SYS03), and a back-end AOR (SYS04). There are direct links between SYS01 and SYS02, SYS02 and SYS03, and SYS03 and SYS04. On the AOR (SYS04), there is an indirect link to the TOR (SYS01), by way of SYS03. On SYS03, there is an indirect link to the TOR by way of SYS02. On the TOR, a terminal is defined as local. On all the other regions, it is defined as remote, owned by the TOR.

Defining the direct links

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.

Defining the indirect links

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:

Defining the terminal

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:

Defining the transaction

The definition of remote transactions is described in Defining remote resources.

Related concepts
Introduction to link definition
Related tasks
Identifying remote systems
Defining links for multiregion operation
Defining APPC links
Defining logical unit type 6.1 links
[[ Contents Previous Page | Next Page Index ]]