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:
- A transaction (TRAA) is initiated on CICSA; for example, by a
terminal operator who is keying in a transaction ID and initial data.
- 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.
- Without ending, program X asks CICSA to establish a conversation
with another CICS system, CICSB. CICSA responds to the request.
- 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.
- 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:
- 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.
- 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.
- 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;