Once the overall structure of the distributed process has been decided, you can then start to design individual conversations. Designing a conversation involves deciding what functions to put into the front-end transaction and into the back-end transaction, and deciding what should be in a distributed unit of work. So you have to make decisions about how to subdivide the work to be done for your application.
Because a conversation involves transferring data between two transactions, to function correctly, each transaction must know what the other intends. For instance, there is little point in the front-end transaction sending data if all the back-end transaction is designed to do is print the weekly sales report. You must therefore consider each front-end and back-end transaction pair as one software unit.
The sequences of commands you can issue on a conversation are governed by a protocol designed to ensure that commands are not issued in inappropriate circumstances. The protocol is based on the concept of a number of conversation states. A conversation state applies only to one side of a single conversation and not to a transaction as a whole. In each state, there are a number of commands that might reasonably be issued. The command itself, together with its outcome, may cause the conversation to change from one state to another.
To determine the conversation state, you can use either the STATE option on a command or the EXTRACT ATTRIBUTES STATE command. Note, however, that the STATE option is valid only for MRO and APPC sessions, not for LUTYPE6.1 sessions. For programming information about the state values returned by different commands, see CICS® Application Programming Reference.
When a conversation changes state, it is said to have undergone a state transition, which generally makes a different set of commands available. The available commands and state transitions are shown in a series of state tables. Which state table you use depends on the protocol, sync level, application programming interface (API), and conversation type that you choose. (Only the APPC protocol gives you a choice of APIs and conversation types.)
Maintaining data integrity contains guidance on selecting the sync level for a conversation. Syncpointing a distributed process discusses the synchronization commands and their effects.
The following sections discuss how you choose the protocol, the API, and the conversation type. These sections also tell you where to find the state tables and command descriptions relevant to the choice you have made.
CICS provides three different protocols:
These protocols define the rules under which two transactions can communicate with each other.
Both APPC and LUTYPE6.1 are protocols defined by SNA. They are therefore more widely available for communicating with non-CICS systems. LUTYPE6.1 is the predecessor of APPC; so you should, if possible, avoid using LUTYPE6.1 for new applications. However, some new applications may still need to use LUTYPE6.1 to communicate with existing LUTYPE6.1 applications.
To help you migrate applications from LUTYPE6.1 to APPC, CICS provides a migration path. For more information on this, see Appendix B. Migration of LUTYPE6.1 applications to APPC links.
Choosing between MRO and APPC can be quite simple. The options depend on the configuration of your CICS complex and on the nature of the conversation partner. MRO does not support communication with a partner in a non-CICS system. Further, it supports communication between transactions running in CICS systems in different MVS™ images only if the MVS images are in the same MVS sysplex, and are joined by cross-system coupling facility (XCF) links; the MVS images must be at IBM® MVS/ESA release level 5.1, or later. (For full details of the hardware and software requirements for XCF/MRO, see the CICS Intercommunication Guide.)
For communication with a partner in another CICS system, where the CICS systems are either in the same MVS image, or in the same MVS/ESA 5.1 (or later) sysplex, you can use either the MRO or the APPC protocol. There are good performance reasons for using MRO. But if there is any possibility that the distributed transactions will need to communicate with partners in other operating systems, it is better to use APPC so that the transaction remains unchanged.
APPC application programs will not run under MRO. Even if both partners are in the same MVS image, CICS will not use MRO facilities but will send conversation data through the communications controller. That involves some VTAM® overhead. So you must decide whether your application programs are to converse using APPC or MRO and code them accordingly.
Table 2 points out the main differences between the MRO and APPC protocols.
MRO | APPC |
---|---|
Function is realized without using a telecommunication access method. | Depends on VTAM or similar. |
Non-standard architecture. | SNA architecture. |
CICS-to-CICS links only. | Links to non-CICS systems possible. |
Communicates within single MVS image, or (using XCF/MRO) between MVS images in same sysplex. | Communicates across multiple MVS images or other operating systems. |
Sync level 2 forced for the conversation. | Sync level 0, 1, or 2 can be selected. |
Program initialization parameter (PIP) data not supported. | PIP data supported. |
Data transmission not deferred. | Deferred data transmission. |
Partner transaction may be identified in data. | Partner transaction defined by program command. |
Performance overhead over a single application. | Even greater performance overhead over a single application. |
RECEIVE can be issued only in receive state. | RECEIVE causes conversation turnaround when issued in send state on mapped conversations. |
No ISSUE SIGNAL command. | ISSUE SIGNAL command available. |
WAIT command has no function. | WAIT command causes transmission of deferred data. |
If you decide to use the APPC protocol, see the next section APPC protocol and decide on which programming interface and which conversation type to use.
If you decide to use the MRO protocol, see Writing programs for MRO conversations.
If you decide to use the LUTYPE6.1 protocol, see Writing programs for LUTYPE6.1 conversations.
[[ Contents Previous Page | Next Page Index ]]