Initiating transaction routing

Transaction routing can be initiated in the following three ways:

  1. A terminal sends a request to the CICS® terminal-owning system to start a transaction. On the basis of an installed resource definition for the transaction (and possibly, in CICS on System/390® and CICS Transaction Server for Windows, on decisions made by a user-written dynamic routing program) the request is routed to an appropriate transaction-owning system, and the transaction runs as if the terminal were attached to the transaction-owning system.
  2. A transaction started by automatic transaction initiation (ATI) acquires a terminal that is owned by another CICS system.
  3. A CICS on System/390 transaction issues an ALLOCATE command for a session to an APPC terminal or connection that is owned by another CICS system.
  4. The CICS-supplied transaction CRTE is used to invoke transactions in other systems. See The routing transaction (CRTE).

Terminal-initiated transaction routing

When a terminal requests transaction initiation, CICS examines the installed transaction definition. If the transaction is defined with a remote system named in the REMOTESYSTEM option (or REMOTESYSID in CICS on Open Systems), CICS initiates the relay transaction, which passes control to the relay program to drive transaction routing.

Static transaction routing

Static transaction routing is a term used to distinguish standard transaction routing from dynamic transaction routing. In CICS/400, all transaction routing is static. In CICS on System/390 and CICS on Open Systems, static transaction routing occurs when DYNAMIC(NO) is specified in the transaction definition.

In static transaction routing, the request is routed to the system named in the REMOTESYSTEM option. If REMOTESYSTEM is unspecified, or if it names the local CICS system, the transaction is a local transaction, and transaction routing is not involved.

Dynamic transaction routing

Dynamic transaction routing allows a user-written program to select the system to which a transaction routing request is to be directed. Dynamic transaction routing is provided by CICS on System/390, CICS on Open Systems, and CICS Transaction Server for Windows. The implementations are different (see following descriptions). CICS/400 does not support dynamic transaction routing.

CICS on System/390 and CICS on Open Systems

In a CICS on System/390 or CICS on Open Systems system, you can use the DYNAMIC option when defining a transaction. This includes a remote definition of a CICS Transaction Server for Windows or CICS/400 transaction.

Specifying DYNAMIC(YES) means that you want the opportunity to route the terminal data to an alternative transaction at the time the defined transaction is invoked. CICS enables this by allowing a user-supplied program, called the dynamic transaction routing program, to examine the terminal input data and redirect it to any transaction and system it chooses. In CICS on System/390, this program has the default name of DFHDYP, but an alternative name may be defined by using the DTRPGM system initialization parameter.

Parameters are passed in a communications area between CICS and the routing program. The program may change some of these to influence subsequent CICS action. For example, in CICS on System/390, some of the parameters are:

The dynamic transaction routing program can issue most EXEC CICS commands.

Dynamic transaction routing enables you to make transaction routing decisions based on such factors as input to the transaction, available CICS systems, relative loading of the available systems, and so on.

CICS Transaction Server for Windows

CICS Transaction Server for Windows provides a user exit in which a user program can change the target system of a transaction routing request. This exit can also change the target system for any shipped function request and provide a target system for a transaction not defined in the local system.

The exit, if defined, is called before processing any of the following:

Shipping terminal definitions

Terminals defined as shippable do not need a definition in the transaction-owning system. If necessary to support transaction routing, the terminal-owning system sends the terminal definition to the transaction-owning system.

Automatic transaction initiation

Automatic transaction initiation (ATI) is the process whereby a transaction request made internally within a CICS system or systems network leads to the scheduling of the transaction.

An ATI request can cause the initiation of a transaction in a remote system (see Figure 7).

ATI also allows a request for a transaction owned by a particular CICS system to name a terminal that is owned by another, connected system (see Figure 7). Although the original ATI request occurs in the application-owning system, it is sent by CICS to the terminal-owning system, where it causes the relay transaction to be initiated in conjunction with the specified terminal.

The user transaction in the application-owning system is then initiated as described on page Terminal-initiated transaction routing for terminal-initiated transaction routing, with one important difference. The extra factor in this case is the AID (automatic initiate descriptor) associated with an ATI request. The AID specifies the names of the remote transaction and system, (P1 and S1 in Figure 7). In Figure 7, the terminal-owning system (S2) must find a transaction definition that specifies REMOTENAME (P1) and REMOTESYSTEM (S1) (or REMOTESYSID on CICS on Open Systems).

In a CICS on System/390 system, an alternative to REMOTESYSTEM is DYNAMIC(YES). In CICS/VSE and CICS Transaction Server for VSE/ESA, if DYNAMIC(YES) is coded, the dynamic routing program is not driven and the remote system name is taken from the AID. In CICS Transaction Server for OS/390® and CICS Transaction Server for z/OS®, if DYNAMIC(YES) is coded, the dynamic routing program is driven, but the remote system name is still taken from the AID; the routing program can do other things--for example, update counts of requests routed to various remote systems.

In summary, if S2 finds a transaction definition that specifies REMOTENAME (P1) and either REMOTESYSTEM (S1) or DYNAMIC(YES), the START command is routed back to S1; otherwise the START command is rejected.

ATI requests are queued:

The overall effect is to create a "single-system" view of ATI as far as the application-owning system is concerned; the fact that the terminal is remote does not affect the way in which ATI appears to operate.

In the transaction-owning system, 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.

Figure 7 shows an example of ATI involving three systems:

S0
The initiating system
S1
The transaction-owning system
S2
The terminal-owning system.

Figure 7. Automatic transaction initiation involving three CICS systems
 The picture shows three CICS systems, the Initiating system (S0), the Transaction-owning system (S1), and the Terminal-owning system (S2). In the Initiating system (S0), a program issues a START TRANSID(P1) SYSID(S1) TERMID(T2) request. The asynchronous processing request (labeled intersystem flow 1) is sent to the Transaction-owning system (S1). S1 determines that the terminal (T2) is owned by system S2, so the request is function-shipped to S2. (This intersystem flow is labeled 2.) The Terminal-owning system (S2) checks for a transaction defined with REMOTENAME(P1) and initiates the relay program. It then sends a transaction routing request (labeled intersystem flow 3) to the Transaction-owning system (S1). On S1, transaction P1 is started.

Terminal definitions not shipped with ATI requests

As mentioned in Shipping terminal definitions, CICS ships a copy of the terminal definition to the transaction-owning system when necessary to support transaction routing. This definition is available for use with ATI requests received subsequently by the transaction-owning system.

However, terminal definitions are not shipped at the time an ATI request is received. If an ATI request names a terminal not already known in the transaction-owning system, the terminal-not-known condition occurs.

User exits for terminal-not-known condition

In CICS on System/390 systems only, two global user exits, XALTENF and XICTENF, help you to deal with the terminal-not-known condition.

Related concepts
Introduction to transaction routing
The relay program
Basic mapping support
The routing transaction (CRTE)
Related reference
CICS product communication support
[[ Contents Previous Page | Next Page Index ]]