Using a single transaction definition in the TOR

This is the recommended method for terminal-initiated transactions.

Using it, in the TOR (and in any intermediate systems) you install only one transaction definition that specifies DYNAMIC(YES). This single definition provides a set of default attributes for all transactions that are dynamically routed. The name of the common definition is that specified on the DTRTRAN system initialization parameter. The default name is CRTX, which is the name of a CICS-supplied transaction definition that is included in the CSD group DFHISC.

If, at transaction attach, CICS cannot find an installed resource definition for a user transaction identifier (transid), it attaches a transaction built from the user transaction identifier and the set of attributes taken from the common transaction definition. (If the transaction definition specified on the DTRTRAN parameter is not installed, CICS attaches the CICS-supplied transaction CSAC. This sends message DFHAC2001—“Transaction 'tranid' is unrecognized”—to the user's terminal.) Because the common transaction definition specifies DYNAMIC(YES), CICS invokes the dynamic transaction routing program to select a target application-owning region and, if necessary, name the remote transaction.

In the target AOR, you install a local definition for each dynamically-routed transaction.

If you use this method for all your terminal-initiated transactions:
  • Dynamically-routed transactions should be installed in the terminal-owning region (if local to the TOR), or the application-owning region (if local to the AOR), but not both.
  • The only terminal-initiated transaction you should define as dynamic is the dynamic transaction routing definition specified on the DTRTRAN parameter.
  • The only terminal-initiated transactions you should define as remote are those that are to be statically routed.

This greatly simplifies the task of managing resource definitions.

It is recommended that you create your own common transaction definition for dynamic routing, using CRTX as a model. The definition is supplied in RDO group DFHISC, with the following attributes:
DTIMOUT(NO)
DYNAMIC(YES)
This is required for a dynamic transaction routing definition that is specified on the DTRTRAN system initialization parameter. You can change the other parameters when creating your own definition, but must specify DYNAMIC(YES).
INDOUBT(BACKOUT)
PROFILE(DFHCICST)
PROGRAM(########)
The CICS-supplied default transaction specifies a dummy program name, ########. If your dynamic transaction routing program allows a transaction to run in the local region, and its definition specifies the dummy program name, CICS is unlikely to find such a program, causing a program-not-found condition.
You are recommended to specify the name of a program that you want CICS to invoke whenever the transaction:
  • Is not routed to a remote system, and
  • Is not rejected by the dynamic transaction routing program by means of the DYRDTRRJ parameter, and
  • Is run in the local region.

You can use the local program to issue a suitable response to a user's terminal if the dynamic routing program decides it cannot route the transaction to a remote system.

REMOTENAME()
SPURGE(YES)
STATUS(ENABLED)
TASKDATALOC(ANY)
TASKDATAKEY(CICS)
TPURGE(YES)
TRANSACTION(CRTX)
The name of the CICS-supplied dynamic transaction routing definition. Change this to specify your own transaction identifier.
TRPROF(DFHCICSS)
TWASIZE(00000)
RESTART(NO)
This attribute is forced for a routed transaction.
REMOTESYSTEM
You can code this to specify a default AOR for transactions that are to be dynamically routed.
ROUTABLE(NO)
This attribute relates to the enhanced routing of transactions initiated by EXEC CICS START commands.
Specifying ROUTABLE(YES) means that, if the transaction is the subject of an eligible START command, it will be routed using the enhanced routing method described in Routing transactions invoked by START commands. You are recommended to:
  • Specify ROUTABLE(NO) on the common transaction definition
  • Install individual definitions of transactions that may be initiated by START commands.

By reserving the common definition for use with transactions that are started from user-terminals, you prevent transactions that are initiated by terminal-related START commands from being dynamically routed “by accident”.