Distributed transaction processing
Distributed transaction processing (DTP) enables a CICS® transaction to communicate with a transaction running in another system. The transactions are designed and coded explicitly to communicate with each other, and thereby to use the intersystem link with maximum efficiency.
The communication in distributed transaction processing is, from the CICS side, synchronous, which means that it occurs during a single invocation of the CICS transaction and that requests and replies between two transactions can be directly correlated.
For more information, see Multiregion operation, ISC and IPIC intercommunication facilities, and Distributed transaction processing overview.
Design overview
CICS handles session failures and systems failures for distributed transaction processing in the same way as for CICS function shipping. See the relevant sections in Function shipping for further information.
- Distributed transaction processing with MRO and LU6.1
-
Figure 1 gives an overview of the modules involved with distributed transaction processing for MRO and LU6.1 ISC.
Figure 1. Distributed transaction processing for MRO and LU6.1 The DFHEIP module is described in EXEC interface. This routes all terminal control requests to DFHETC. DFHETC handles BUILD_ATTACH, EXTRACT, and POINT_TC requests itself. It routes all other requests (SEND, WAIT, CONVERSE, RECEIVE (with journal)), to DFHZARQ, except for FREE_TC and ALLOCATE_TC requests, which are routed to DFHZISP. If the request requires that the user conversation state be returned, DFHETC calls DFHZSTAP.
- Mapped conversations (LU6.2)
-
In mapped conversations, the data passed to and received from the LU6.2 application programming interface (API) is user data. Mapped conversations use the normal CICS API. Application programs and function shipping requests written for LU6.1 operate using mapped conversations when transferred to LU6.2.
Figure 2 gives an overview of the modules involved with the processing of mapped conversations in LU6.2.Figure 2. Distributed transaction processing for mapped conversations in LU6.2 The DFHEIP module is described in EXEC interface. This routes all terminal control requests to DFHETC. DFHETC routes all requests relating to an LU6.2 session to DFHETL except for ALLOCATE_TC requests, which are routed to DFHZISP.
In turn, DFHETL calls DFHZARL to process most requests; it calls DFHZISP to handle FREE_TC requests, and DFHZARM to handle the receipt of unrecognized or unsupported IDs. If the request requires that the user conversation state be returned, DFHETL calls DFHZSTAP.
DFHZARL’s processing depends on the type of request; for example, it calls DFHZISP to allocate a TCTTE, DFHZARR to receive data, and DFHZERH for outbound or inbound FMH7 processing. If the request needs to be transaction routed, DFHZARL calls DFHZXRL to route the request to the terminal-owning region (see Transaction routing).
- Unmapped conversations (LU6.2)
-
Unmapped conversations, also known as basic conversations, are used principally for communication with device-level products that do not support mapped conversations, and which possibly do not have an API open to the user. In unmapped conversations, the data passed to and received from the LU6.2 API contains GDS headers.
Figure 3 gives an overview of the modules involved with the processing of unmapped conversations in LU6.2 ISC.Figure 3. Distributed transaction processing for unmapped conversations in LU6.2 The DFHEIP module is described in EXEC interface. This passes control to DFHEGL to process GDS commands. DFHEGL routes all GDS conversation-related commands directly to DFHZARL. Some validation of application-provided parameters is performed, and errors are reflected back to the application. If the request requires that the user conversation state be returned, DFHEGL calls DFHZSTAP.
DFHZARL’s processing depends on the type of request; for example, it calls DFHZISP to allocate a TCTTE, DFHZARR to receive data, and DFHZERH for outbound or inbound FMH7 processing. If the request needs to be transaction routed, DFHZARL calls DFHZXRL to route the request to the terminal-owning region (see Transaction routing).
Modules
| Module | Description |
|---|---|
| DFHEGL | DFHEGL is an EXEC interface processor module that processes GDS commands. It receives
control directly from DFHEIP or DFHEIG. The TCTTE for the session is located and checked for validity. All GDS conversation-related commands are mapped into a DFHLUC macro call and routed directly to DFHZARL. There is no mapping or unmapping of data, state indicators are not maintained, and there are no FMHs to process. |
| DFHETC | The EXEC interface processor for terminal control. |
| DFHETL | The EXEC interface processor for mapped LU6.2 commands. |
| DFHZARL | |
| DFHZARM | DFHZARM translates the data stream to and from a format suitable for invoking DFHZARL. |
| DFHZARQ | The application request interface module. |
| DFHZARR | DFHZARR handles RECEIVE requests. |
| DFHZERH | DFHZERH handles error information. |
| DFHZISP | DFHZISP handles ALLOCATE_TC requests and FREE_TC requests. DFHZISP is called by DFHETC to perform ALLOCATE_TC requests. (ALLOCATE commands are passed to DFHZISP because DFHETC cannot check the session type until the session is allocated.) DFHZISP is also called to perform FREE_TC requests. |
| DFHZSTAP | DFHZSTAP is used to determine the conversation state of an MRO or LU6.2 session from the application side. |
Exits
No global user exit points are provided for this function.
Trace
- AP FDxx, for which the trace level is TC 1.
- AP FExx (LU6.2 application receive requests), for which the trace levels are TC 2 and Exc.