Defining indirect links in CICS Transaction Server for z/OS

CICS® systems reference remote terminals using a unique identifier that is formed from the applid (netname) of the terminal-owning region (TOR) and the identifier by which the terminal is known on the terminal-owning region.

For more information on remote resource definition, see Defining remote resources.

CICS must have access to the netname of the TOR to be able to form the fully-qualified terminal identifier. 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 1, 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-z/OS Communications Server 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-z/OS Communications Server terminals are not shippable.
Hard-coded terminals
If you are using z/OS Communications Server terminals exclusively, indirect links are not required. You use the REMOTESYSNET attribute 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 attribute 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-z/OS Communications Server terminals, indirect links are required. This is because must use the DFHTCT TYPE=REMOTE or TYPE=REGION macros to define non-z/OS Communications Server terminals, and these do not include an equivalent of the REMOTESYSNET attribute.

Therefore, in CICS Transaction Server for z/OS, you might decide to define indirect links:
  • To specify the preferred path to the TOR, if more than one exists, and you are using shippable terminals.
  • If you are using non-z/OS Communications Server terminals for transaction routing across intermediate systems.
  • To enable you to use existing remote terminal definitions that do not specify the REMOTESYSNET attribute. For example, you might have hundreds of remote z/OS Communications Server terminals defined to a back-level system. If you introduce a new CICS Transaction Server for z/OS back-end system into your network, you might want to copy the existing definitions to the CSD of the new system. If the structure of your network means that there is no direct link to the TOR, it might be quicker to define a single indirect link, rather than change all the copied definitions to include the REMOTESYSNET attribute.