Ensure data integrity with synchronization support

When designing applications that update data on more than one system, it is important to remember that network or system failures sometimes occur. These failures are difficult to manage in a distributed environment because the application is exposed to partial failures that do not occur in a single-system environment. This is best shown with an example.

Consider the case of a single system in which an application is moving records between two recoverable files, FILEA and FILEB, as shown in Figure 1. If a problem occurs, for example, data is corrupted in one of the files, a transaction abends, or a CICS® region fails, CICS backs out the changes that were made before the problem occurred. Consequently, the files return to the state in which they were at the time the transaction was initially started.

Figure 1. A simple transaction

Now consider the case where FILEB resides on a remote system, as shown in Figure 2. The work of the application is effectively split into two transactions, TRN1 and TRN2. Because the application is distributed, it is now difficult for TRN1 (in the local system) to detect problems with adding the record to FILEB (in the remote system). If TRN1 cannot detect these problems, it might delete a record from FILEA that has not been added to FILEB, and cause the record to be lost.

Figure 2. A distributed application

The solution is to use a form of acknowledgment processing so that the two transactions in the application can ensure that they each complete their task successfully. The exact form of this acknowledgment depends on the requirements of the application. For example, the application can be transferring a list of changed customer addresses between the two systems. As shown in Figure 3, after TRN2 writes a record to FILEB, it can send a message to TRN1, indicating that the record can be deleted from FILEA.

Figure 3. Acknowledgment processing

Thus a record can never be lost because TRN1 deletes the record from FILEA only when it knows that the record is written to FILEB. However, if TRN1 fails after it receives the message to delete the record, but before the record is actually deleted from FILEA, thus the record appears twice, once in FILEA and again in FILEB.

In this application, it does not matter whether a customer's address is updated once or twice. However, if the data in FILEA represents money in some form, and the act of transferring it between the systems effectively transfers the money from one bank account to another, two copies of the record cause the money to be transferred twice.

A mechanism is required to ensure that the deletion from FILEA always occurs if the write operation to FILEB is successful and never occurs if the write operation to FILEB is unsuccessful. This requires a much more sophisticated coordination between the two systems.

When SNA systems first establish contact, they agree the maximum synchronization that they will use. The synchronization level for each individual task is then determined either by CICS or by the application program. TXSeries for Multiplatforms supports all three synchronization levels across both SNA and TCP/IP. Refer to Designing your network configuration for more information about these communication methods.

If the remote system and the communication network are able, TXSeries for Multiplatforms uses synchronization level 2 conversations on function shipping, asynchronous processing, and distributed program link (DPL) requests. Transaction routing requests from TXSeries for Multiplatforms always use synchronization level 1 conversations because they do not update recoverable data on the local region. However, TXSeries for Multiplatforms can receive synchronization level 2 transaction routing requests from CICS Transaction Server for z/OS, CICS/ESA, CICS/MVS, and CICS/VSE. Distributed transaction processing (DTP) uses the synchronization level that is requested on the SYNCLEVEL parameter of the EXEC CICS CONNECT PROCESS command.

For further information on the CONNECT PROCESS command, see CONNECT PROCESS.

The following table summarizes the synchronization level that is used on outbound intersystem requests. Refer to the following legend:

FS

Function shipping

TR

Transaction routing

AP

Asynchronous processing

DPL

Distributed program link

DTP

Distributed transaction processing

NS

Not supported