You should design your application to cope with the things that can go wrong while a transaction is running, for example, a session failing. The conversation protocol helps you 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 recoverable resources such as transient data queues and files, whether they are local or remote. Whatever goes wrong during the running of a transaction should not leave the associated resources in an inconsistent state.
An application program can cancel all changes made to recoverable resources since the last known consistent state. This process is called rollback. The physical process of recovering resources is called backout. The condition that exists as long as there is no loss of consistency between distributed resources is called data integrity.
Sometimes you may need to backout changes to resources, even though no error conditions have arisen. 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 is programmed to respond by returning the data resources to the state they were in at the start of the order transaction.
The point in a process where resources are declared to be in a known consistent state is called a synchronization point, often shortened to syncpoint. Syncpoints 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). In a distributed process, this is also known as a distributed unit of work.
When a transaction issues a syncpoint command, CICS® commits all changes to recoverable resources associated with that transaction. After the syncpoint, the transaction can no longer back out changes made since the previous syncpoint. They have become irreversible.
Although CICS can commit and backout changes to local and remote resources for you, this service must be paid for in performance. If the recovery of resources throughout a distributed process is not a problem (for example, in an inquiry-only application), you can use simpler methods of synchronization.
Systems Network Architecture (SNA) defines three levels of synchronization for conversation using the APPC protocol:
At sync level 0, there is no CICS support for synchronization of remote resources on connected systems. But it is still possible, under the control of the application to achieve some degree of synchronization by interchanging data, using the SEND and RECEIVE commands.
At sync level 1, you can use special commands for communication between the two conversation partners. One transaction can confirm the continued presence and readiness of the other. Both transactions are responsible for preserving the data integrity of recoverable resources by issuing syncpoint requests at the appropriate times.
At sync level 2, all syncpoint requests are automatically propagated across multiple systems. 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 syncpoint when one of the transactions terminates normally. One abending transaction causes all to 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 sync level 2 has been selected.
Bear in mind that syncpoint and rollback are not limited to any one conversation within a transaction. They are propagated on every conversation currently active at sync level 2.