Defining transactions for transaction routing
The way in which a transaction is selected for local or remote execution is determined by the remote attributes that are specified in the transaction definition.
- When an EXEC CICS START command uses the SYSID option to name the remote region on which the transaction is to run, a remote region named explicitly on in the SYSID option takes precedence over one named on the transaction definition.
- The remote attributes specify DYNAMIC(NO), and the REMOTESYSTEM name is either
blank or the sysid of the local system.
In this case, the transaction is executed locally, and transaction routing is not involved.
- The remote attributes specify DYNAMIC(NO), and the REMOTESYSTEM name differs
from the sysid of the local system.
In this case, the transaction is routed to the system named in the REMOTESYSTEM option. This is known as static transaction routing. The REMOTESYSTEM option must name a direct link to another system (not an indirect link nor a remote APPC connection).
- The remote attributes specify DYNAMIC(YES).
In this case, the decision about where to execute the transaction is taken by your dynamic or distributed routing program. See Two routing programs.
Note: Exceptions to this rule are transactions initiated by EXEC CICS START commands that are ineligible for enhanced routing. For example, if one of these transactions is defined as DYNAMIC(YES), your dynamic routing program is invoked but cannot route the transaction. See Routing transactions invoked by START commands.
The name in the TRANSACTION option is the name by which the transaction is invoked in the local region. TASKREQ can be specified if special inputs, such as a program attention (PA) key, program function (PF) key, light pen, magnetic slot reader, or operator ID card reader, are used.
If there is a possibility that the transaction will be executed locally, the definition must follow the normal rules for the definition of a local transaction. In particular, the PROGRAM option must name a user program that will be installed in the local system. When the transaction is routed to another system, the program associated with it is always the relay program DFHAPRT, irrespective of the name specified in the PROGRAM option.
The PROFILE option names the profile that is to be used for communication between the terminal and the relay transaction (or the user transaction if the transaction is executed locally). For remote execution, the TRPROF option names the profile that is to be used for communication on the session between the relay transaction and the remote transaction-owning system. Information about profiles is given under Defining communication profiles.
- You can set or default TWASIZE to zero, because the relay transaction does not require a TWA.
- You should specify transaction security for routed transactions that are operator initiated. You do not need to specify resource security checking, because the relay transaction does not access resources. See Transaction security for information on security.
- For transaction routing on mapped APPC connections or MRO sessions, you should
code the RTIMOUT option on the communication profile named on the TRPROF option
of the transaction definition. This causes the relay transaction to be timed out
if the system to which a transaction is routed does not respond within a
reasonable time.
Deadlock timeout (specified on the DTIMOUT option of the transaction definition) is not triggered for terminal I/O waits. Because the relay transaction does not access resources after obtaining a session, it has little need for DTIMOUT except to trap suspended ALLOCATE requests. (Methods for specifying whether, if there are no free sessions to a remote system, ALLOCATE requests should be queued or rejected, are described in Intersystem session queue management.)
The method you use to define transactions for routing may differ, depending on whether the transactions are to be statically or dynamically routed.