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.
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:
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.
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.
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.
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 ]]