Allocation of remote APPC connections

A transaction running in the application-owning region can issue an ALLOCATE command, to obtain a session to an APPC terminal or connection that is owned by another system.

A relay program is started in the terminal-owning region to convey requests between the transaction and the remote APPC system or terminal.

Transaction routing with APPC devices

An APPC device presents a data interface to CICS® that is an implementation of the APPC architecture. The APPC session linking it to a transaction represents the principal facility of the transaction rather than the device itself. The transaction converses across the link with a transaction program within the device, which may be a hard-coded terminal device, a programmable system, or even another CICS system.

There is no essential difference between transaction routing with APPC devices and transaction routing with any other terminals. However, remember these points:

You use the APPC application program interface to communicate with APPC devices. For relevant introductory information, see Distributed transaction processing.

Allocating an alternate facility

One of the design criteria in transaction routing is that, if a transaction running in a single-CICS environment is transferred to an alternative, linked system, there should be no loss of function if the transaction now has to be routed to the original terminal.

Because an APPC device can have more than one session, it is possible, in the single-CICS case, for a transaction to acquire further sessions to the same device (but to different tasks) by using the ALLOCATE command. Each session thus acquired becomes an alternate facility to the transaction. Sessions can also be established to other terminals or systems.

Similarly, transaction routing allows any transaction to acquire an alternate facility to an APPC device by using ALLOCATE, even though there are intermediate systems between the APPC device and the AOR. For this, the AOR needs a remote version of the APPC link definition that is installed in the TOR. Perhaps you can rely on this having been shipped to the AOR by a transaction routing operation. If not, you will have to install it expressly. You cannot use the user exits XICTENF and XALTENF as an aid to routing the alternate facility.

The system as a terminal

Because the resource definitions for APPC devices can take the CONNECTION and SESSIONS form, it is easy to confuse them with the definitions for the intersystem links. It is important to remember that definitions for the intersystem links are either direct or indirect, while those for APPC devices are direct in the TOR and remote in the AOR and any intermediate systems. Note also that remote CONNECTION definitions do not need corresponding SESSIONS definitions.

Figure 25 shows a network of three CICS systems chained together, of which the first is linked to an APPC terminal.

Figure 25. Transaction routing to an APPC terminal across daisy-chained systems
 The picture shows an APPC terminal or system, A, and three CICS regions, B, C, and D. B is a TOR, C an intermediate system, and D an AOR. There is a direct link between A and B, between B and C, and between C and D. B has defined an indirect link to D via C. D has defined an indirect link to B via C. C and D both have a remote definition for A. On the AOR, D, a transaction is defined as local . On the intermediate region, C, the same transaction is defined as owned by D. On the TOR, B, it is defined as owned by C.

Notes:
  1. The remote link definitions for A could either be defined by the user or be shipped from system B during transaction routing.
  2. The indirect links are not necessary to this example, but are included to complete all possible linkage combinations. See Defining indirect links for transaction routing.
  3. The links B-C and C-D may be either MRO or APPC.

System A (or any one of the four systems) can take on the role of a terminal. This is a technique that allows a pair of transactions to converse across intermediate systems. Consider this sequence of events:

  1. A transaction running in A allocates a session on the link to B and makes an attach request for a particular transaction.
  2. B sees that the transaction is on C, and initiates the relay program in conjunction with the principal facility represented by the link definition to A.
  3. The attach request arrives at C together with details of the terminal; that is, B’s link to A. C builds a remote definition of the terminal and goes to attach the transaction.
  4. C also finds the transaction remote and defined as owned by D. C initiates the relay program, which tries to attach the transaction in D.
  5. D also builds a remote definition of B’s link to A, and attaches the local transaction.
  6. The transaction in A that originated the attach request can now communicate with the target transaction through the transaction routing mechanism.

Note these points:

Related concepts
Introduction to CICS dynamic routing
Overview of transaction routing
Terminal-initiated transaction routing
Traditional routing of transactions started by ATI
The relay program
Basic mapping support (BMS)
Defining indirect links for transaction routing
Related tasks
Routing transactions invoked by START commands
Using the routing transaction (CRTE)
System programming for transaction routing
Defining remote resources for transaction routing
Application programming for CICS transaction routing
Related reference
Appendix A. Intercommunication rules and restrictions checklist
[[ Contents Previous Page | Next Page Index ]]