Distributed transaction processing (DTP)

DTP is one of the five ways that CICS® allows processing to be split between intercommunicating systems. Only DTP allows two or more communicating application programs to run simultaneously in different systems and to pass data backward and forward between themselves; that is, to perform a synchronous conversation.

Of the five intercommunication facilities that CICS offers, DTP is the most flexible and powerful, but also the most complex.

The CICS family TCP/IP network protocol does not support DTP.

DTP allows two or more partner programs that are in different systems to interact with each other. DTP enables a CICS transaction to communicate with one or more transactions that are running in different systems. A group of such connected transactions is called a distributed process.

The process can best be shown by discussing the operation of DTP between two CICS systems, CICSA and CICSB, where:
  1. A transaction (TRAA) is initiated on CICSA; for example, by a terminal operator who is keying in a transaction ID and initial data.
  2. To fulfill the request, the processing program X begins to execute on CICSA, probably reading initial data from files, perhaps updating other files and writing to print queues.
  3. Without ending, program X asks CICSA to establish a conversation with another CICS system, CICSB. CICSA responds to the request.
  4. Also without ending, program X sends a message across the conversation and asks CICSB to start a new transaction, TRBB. CICSB initiates transaction TRBB by invoking program Y.
  5. Program X now sends and receives messages, including data, to and from program Y. Between sending and receiving messages, both program X and program Y continue normal processing completely independently. When the two programs communicate, their messages can consist of:
    1. Agreements about how to proceed with conversation or how to end it. For example, program X can tell program Y when it can transmit messages across the session. At any time, both programs must know the state of their conversation, and therefore, what actions are allowed. At any time, either system might have actual control of the conversation.
    2. Agreements to make permanent all changes that have made up to that point. This allows the two programs to synchronize changes. For example, a dispatch billing program on CICSA might want to commit delivery and charging for a stock item, but only when a warehouse program in CICSB confirms that it has successfully allocated the stock item and adjusted the inventory file accordingly.
    3. Agreements between CICSA and CICSB to cancel, rather than to make permanent, changes to data that have been made since a given point. Canceling (or rollback) might occur when customers change their minds, for example. Alternatively, it might occur because of uncertainty that has been caused by failure of the application, the system, the communication path, or the data source.

Although the two programs X and Y exist as independent units, it is clear that they are designed to work as one. Of course, DTP is not limited to pairs of programs. You can chain many programs together to distribute processing more widely.

In the overview of the process that is given above, the location of program Y has not been specified. Program X is a CICS program, but program Y need not be, because CICS can establish conversations with non-CICS partners. This is discussed in Designing distributed processes.
Note: You cannot use both the DTP and DTR protocols together on TXSeries. For example, if you are planning to use DTP for communicating between transactions T1 and T2 located at the regions REG1 and REG2, TXSeries requires T1 and T2 to be defined locally in REG1 and REG2. T1 or T2 should not be defined as a remote transaction to different region in TD.stanza.
For more information about distributed transaction processing, see the following topics;