What is DTP?

DTP is one of the ways in which 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 back and forth between themselves--that is, to carry on a conversation.

Of the intercommunication facilities offered by CICS, DTP is the most flexible and powerful, but also the most complex. This section introduces you to the basic concepts involved in creating DTP applications. For a broad discussion of intercommunication concepts, see CICS Intercommunication Guide.

DTP allows two or more partner programs in different systems to interact with each other for some purpose. DTP enables a CICS transaction to communicate with one or more transactions 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. The configuration is shown in Figure 1.

Figure 1. DTP between two CICS transactions
 This figure shows a configuration of two interconnected CICS systems, which is described in the text.
  1. A transaction (TRAA) is initiated on CICSA, for example, by a terminal operator 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 communication session with another CICS system, CICSB. CICSA responds to the request.
  4. Also without ending, program X sends a message across the communication session, asking 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:

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. This is discussed later in the book.

In the overview of the process 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 sessions with non-CICS, LUTYPE6.1, MRO, or APPC partners. This is discussed in Designing distributed processes.

The rest of this book considers the cases of CICS DTP with the following protocols:

Conversations

Although several programs can be involved in a single distributed process, information transfer within the process is always between self-contained communication pairs. The exchange of information between a pair of programs is called a conversation. During a conversation, both programs are active; they send data to and receive data from each other. The conversation is two-sided but at any moment, each partner in the conversation has more or less control than the other. According to its level of control (known as its conversation state), a program has more or less choice in the commands that it can issue.

Conversation states

Thirteen conversation states have been defined for CICS DTP. The set of states possible for a particular conversation depends on the protocol and synchronization level used. (The concepts of protocol and synchronization level are explained in Selecting the protocol and Maintaining data integrity respectively.) Table 1 shows which conversation states are defined for which protocols and synchronization levels.

Table 1. The conversation states defined for different protocols Yes and no indicate whether the state is defined.
State number State name APPC sync level 0 APPC sync level 1 APPC sync level 2 MRO LUTYPE6.1 normal mode LUTYPE6.1 migration mode
1 Allocated Yes Yes Yes Yes Yes Yes
2 Send Yes Yes Yes Yes Yes Yes
3 Pendreceive Yes Yes Yes No Yes Yes
4 Pendfree Yes Yes Yes Yes Yes Yes
5 Receive Yes Yes Yes Yes Yes Yes
6 Confreceive No Yes Yes No No Yes
7 Confsend No Yes Yes No No Yes
8 Conffree No Yes Yes No No Yes
9 Syncreceive No No Yes Yes Yes Yes
10 Syncsend No No Yes No Yes Yes
11 Syncfree No No Yes Yes Yes Yes
12 Free Yes Yes Yes Yes Yes Yes
13 Rollback No No Yes Yes No Yes

By using a special CICS command (EXTRACT ATTRIBUTES STATE), or the STATE option on a conversation command, a program can obtain a value that indicates its own conversation state. CICS places such a value in a variable named by the program; the variable is sometimes referred to as a state variable. Knowing the current conversation state, the program then knows which commands are allowed. If, for example, a conversation is in send state, the transaction can send data to the partner. (The transaction can take other actions instead, as indicated in the relevant state table.)

When a transaction issues a DTP command, this can cause the conversation state to change. For example, a transaction can deliberately switch the conversation from send state to receive state by issuing a command that invites the partner to send data. When a conversation changes from one state to another, it is said to undergo a state transition. The state tables in later sections show how these transitions take place.

Not only does the conversation state determine what commands are allowed, but the state on one side of the conversation reflects the state on the other side. For example, if one side is in send state, the other side is in either receive state, confreceive state, or syncreceive state.

Sessions

A conversation takes place across a CICS resource called a session. One transaction (known as the front-end transaction) asks CICS to allocate a session, and then uses this session to request that the remote transaction (known as the back-end transaction) be initiated. Then the two transactions, which can be thought of as partners in the conversation, can "talk to" each other.

A session is a logical data path between two logical units. It is a shared resource and is allocated to a transaction in response to a request from the transaction. Resource definition determines the number of sessions available for allocation. While a conversation is active, it has sole use of the session allocated to it.

A transaction starts a conversation by requesting the use of a session to a remote system. When it obtains the session, the transaction can issue commands that cause an attach request to be sent to the other system to activate the transaction that is to be the conversation partner. A transaction can issue an attach request to more than one other transaction.

[[ Contents Previous Page | Next Page Index ]]