Dynamic transaction routing

Transaction routing can be either static or dynamic:

With static transaction routing, the transaction is routed to the system that is named with the RemoteSysId attribute in the Transaction Definitions (TD) for that transaction. In this case, the value of the TD Dynamic attribute is no in the local definition for that transaction.
With Dynamic transaction routing, the transaction can be dynamically routed to any available system, either remote or local, when the transaction is started. In this case, the value of the TD Dynamic attribute is yes in the local definition for that transaction.

Dynamic transaction routing enables you to define how a transaction is to be routed depending on such factors as:

Input to the transaction
Available CICS® systems
Relative loading of the available systems

Also, a routing program can perform other functions besides redirecting transaction requests, such as:

Balancing of workload. For example, in a multiple-CICS environment, your program could make intelligent choices between equivalent transactions on parallel systems.
Handling transactions that cannot be routed, such as when no remote CICS regions are available.
Handling abends in the routed-to transaction.
Monitoring the number of requests that are routed to particular systems.

Dynamic transaction routing cannot be used to reroute remote ATI requests.

CICS manages dynamic transaction routing through the use of the CICS-supplied dynamic transaction routing user exit. This user exit is invoked:

Before routing a transaction that is defined as Dynamic=yes
If an error occurs in route selection
At the end of a routed transaction if the initial invocation requests reinvocation at termination
If a routed transaction abends and the initial invocation requests reinvocation at termination

Parameters are passed in a structure between CICS and the dynamic routing program. The program might change some of these parameters to influence subsequent CICS action. The parameters include:

The reason for the current invocation.
Error information.
The name of the target system. Initially, this is the system that is specified with the TD RemoteSysId attribute. If is system is not specified, the name that is passed is that of the local system.
The name of the target transaction. Initially, this is the name that is specified with the RemoteName attribute. If a target transaction is not specified, the name that is passed is the name of the local transaction.
A pointer to the CWA.
A pointer to the TCTUA.
A user area.

A dynamic transaction routing program must follow standard user exit rules.

CICS supplies a sample program that can be invoked by the user exit, but you can replace this with one of your own. To do this, define your program in the PD of the region and set the UserExitNumber attribute to 25.

Although the RemoteSysId and Remotename attributes are used by the dynamic transaction routing user exit for routing the transactions, they are ignored when the transactions are run locally. If you set up the dynamic transaction routing user exit to allow a transaction to run locally, you need to define the local program.

This user exit is not invoked:

When the transaction that is defined as dynamic is started in an intermediate application-owning region. CICS attempts to abend such transactions but cannot detect all attempts to “daisy chain” dynamic transactions. You must ensure that your dynamic transaction routing program does not “daisy chain” dynamic transactions.
When a problem occurs because of lack of storage while the parameter list or standard header for the user exit is being built. This causes the transaction to abend.
When the dynamic transaction is started in a Terminal-Owning Region by a command of the following type that is issued in an Application-Owning Region:
```
EXEC CICS START TERM(yyyy) TRAN(xxxx)
```
In this case, the user exit is not invoked and the transaction is routed back to the system where the request was issued.