Conversations

In DTP, transactions pass data to each other directly. While one sends, the other receives. The exchange of data between two transactions is called a conversation. Although several transactions can be involved in a single distributed process, communication between them breaks down into a number of self-contained conversations between pairs. Each such conversation uses a CICS® resource known as a session.

Conversation initiation and transaction hierarchy

A transaction starts a conversation by requesting the use of a session to a remote system. Having obtained the session, it causes an attach request to be sent to the other system to activate the transaction that is to be the conversation partner.

A transaction can initiate any number of other transactions, and hence, conversations. In a complex process, a distinct hierarchy emerges, with the terminal-initiated transaction at the very top. Figure 11 shows a possible configuration. Transaction TRAA is attached over the terminal session. Transaction TRAA attaches transaction TRBB, which, in turn, attaches transactions TRCC and TRDD. Both these transactions attach the same transaction, SUBR, in system CICSE. This gives rise to two different tasks running SUBR.

Figure 11. DTP in a multisystem configuration
 The picture shows the scenario described in the preceding text. It shows five CICS regions, CICSA through CICSE, arranged in a hierarchical, pyramid structure, with CICSA at the top and CICSE at the base. CICSB is below CICSA; CICSC and CICSD are on the same level, below CICSB. A terminal starts a transaction, TRAA, in CICSA. TRAA attaches transaction TRBB, in CICSB. TRBB attaches transactions TRCC, in CICSC, and TRDD, in CICSD. TRCC and TRDD both attach transaction SUBR, in CICSE.

Structure of a distributed process

The structure of a distributed process is determined dynamically; it cannot be specified beforehand in transaction definitions. For each transaction, there is only one inbound attach request, but there can be any number of outbound attach requests. The session that activates a transaction is called its principal facility. A session that is allocated by one transaction to activate another transaction is called the alternate facility of the allocating transaction. In Figure 11, session 1 is the principal facility of transaction TRBB and an alternate facility of transaction TRAA. A transaction has only one principal facility, but can have any number of alternate facilities. Transaction TRBB has two alternate facilities, sessions 2 and 3.

When a transaction initiates a conversation, it is the front end on that conversation. Its conversation partner is the back end on the same conversation. In Figure 11, transaction TRBB is the front end of the conversations on sessions 2 and 3, and the back end of the conversation on session 1. (Some publications refer to the front end as the initiator and the back end as the recipient.) It is normally the front end that dominates, and determines the way the conversation goes. You can arrange for the back end to take over if you want, but, in a complex process, this can cause unnecessary complication. This is further explained in the discussion on synchronization later in this chapter.

Application design

DTP has none of the transparency of function shipping or transaction routing. A conversation transfers data from one transaction to another. For this to function properly, each transaction must know what the other intends. It is therefore necessary to design, code, and test front end and back end as one software unit. The same applies when there are several conversations and several transaction programs. Each new conversation adds to the complexity of the overall design.

In Example 2, the DTP solution (Solution 3) is to transfer a file of data from one transaction to another-in this case, transmit the entire contents of the transient data queue from the front end to the back end. The next stage of complexity is to cause the back end to return data to the front end, perhaps the result of some processing. Here, the front end is programmed to request conversation turnaround at the appropriate point.

Among other things, the designer of a DTP application must decide:

Control flows

During a conversation, data passes over the link in both directions. A single transmission is called a flow. Issuing a SEND command does not always cause a flow. This is because the transmission of user data can be deferred; that is, held in a buffer until some event takes place. The APPC architecture defines data formats and packaging. CICS handles these things for you, and they concern you only if you need to trace flows for debugging.

The APPC architecture defines a data header for each transmission, which holds information about the purpose and structure of the data following. The header also contains bit indicators to convey control information to the other side. For example, if one side wants to tell the other that it can start sending, CICS sets a bit in the header that signals a change of direction in the conversation.

To keep flows to a minimum, non-urgent control indicators are accumulated until it is necessary to send user data. Then they are added to the header.

In complex procedures, such as establishing syncpoints, it is often necessary to send control indicators when there is no user data available to send. This is called a control flow.

Conversation state and error detection

As a conversation progresses, it moves from one state to another within both conversing transactions. The conversation state determines the commands that may be issued. For example, it is no use trying to send or receive data if there is no session linking the front end to the back end. Similarly, if the back end signals end of conversation, the front end cannot be in a state to receive more data.

Either end of the conversation can cause a change of state, usually by issuing a particular command from a particular state. CICS tracks these changes, and stops a transaction from issuing a command that is wrong for its current state.

Synchronization

Many things can go wrong during the running of a transaction. The conversation protocol helps you to recover from errors and ensures that the two sides remain in step with each other. This use of the protocol is called synchronization.

Synchronization allows you to protect resources such as transient data queues and files. Whatever goes wrong during the running of a transaction should not leave the associated resources in an inconsistent state.

Example

A transaction is transmitting a queue of data to another system to be written to a file. The receiving transaction is abended.

Even if a further abend can be prevented, there is the problem of how to continue the process without loss of data. It is uncertain how many queue items have been received and how many have been correctly written to the file. The only safe way of continuing is to go back to a point where you know that the contents of the queue are consistent with the contents of the file. The sending system must restore the queue entries that have been sent, and the receiving system must delete any entries made in the file. CICS helps you to do this (see Taking syncpoints).

Rollback and backout

The cancelation by an application program of all changes to recoverable resources since the last known consistent state is called rollback. The physical process of recovering resources is called backout. For the most part, the two terms are used interchangeably. The condition that exists as long as there is no loss of consistency between distributed data resources is called data integrity.

Application-initiated rollback

There are cases where you want to recover resources, even though there are no error conditions detectable by CICS. Consider an order entry system. While entering an order for a customer, an operator is told by the system that the customer’s credit limit would be exceeded if the order went through. Because there is no use continuing until the customer is consulted, the operator presses a PF key to abandon the order. The transaction can be programmed to respond by restoring the data resources to the state they were in at the start of the order. At synchronization level 2 (see Synchronization levels), rollback occurs automatically in all remote partner transactions.

Taking syncpoints

If you log your own data movements, you can arrange backout of your files and queues. However, this involves very complex programming. To save you the trouble, CICS arranges resource recovery for you.

A point in the process where resources are declared to be in a known consistent state is called a synchronization point, often shortened to syncpoint. Synchronization points are implied at the beginning and end of a transaction. A transaction can define other syncpoints by program command. All processing between two syncpoints belongs to a unit of work (UOW).

Taking a syncpoint, if successful, commits all changes to recoverable resources. This means that all systems involved in a distributed process erase all the information they have been keeping about data movements on recoverable resources. Now backout is no longer possible, and all changes to the resources since the last syncpoint are made irreversible.

An unsuccessful syncpoint causes rollback. Recoverable resources are restored to their state at the start of the UOW.

CICS can commit and back out changes to resources, but the service has a performance trade-off. Some transactions do not need such facilities. If the recovery of resources is not a problem, use simpler methods of synchronization.

The three synchronization levels

The APPC architecture defines three levels of synchronization:

At synchronization level 0, there is no system support for synchronization. It is nevertheless possible to achieve some degree of synchronization through the interchange of data, using the SEND and RECEIVE commands.

If you select synchronization level 1, you can use specific commands for communication between the two conversation partners. One transaction can confirm the continued presence and readiness of the other. The user is responsible for preserving the data integrity of recoverable resources.

The level of synchronization described earlier in this section corresponds to synchronization level 2. Here, system support is available for maintaining the data integrity of recoverable resources.

CICS implies a syncpoint when it starts a transaction; that is, it initiates logging of changes to recoverable resources, but no control flows take place. CICS takes a full syncpoint when a transaction is normally terminated. Transaction abend causes rollback. The transactions themselves can initiate syncpoint or rollback requests. However, a syncpoint or rollback request is propagated to another transaction only when the originating transaction is in conversation with the other transaction, and synchronization level 2 has been selected for the conversation between them.

Remember that syncpoint and rollback are not peculiar to any one conversation within a transaction. They are propagated on every current synchronization level 2 conversation within the transaction.

A transaction specifies the required synchronization level in the CONNECT PROCESS command that initiates a conversation. The requested level must not be higher than that supported between the two products. Support for the different synchronization levels varies between products. Refer to CICS product communication support.

Related concepts
Why use distributed transaction programming?
EXEC CICS or CPI Communications?
Related reference
CICS product communication support
[[ Contents Previous Page | Next Page Index ]]