If it is important for you to be able to recover your data when things go wrong, design conversations for synchronization level 2, and keep the LUWs as small as possible. However, this is not always possible, because the size of an LUW is determined largely by the function that is being performed. Remember that CICS® sync point processing has no information about the structure and purpose of your application. As an application designer, you must ensure that sync points are taken at the correct time and place, and to good purpose. If you do, error conditions are unlikely to lead to inconsistencies in recoverable data resources.
- Because an LUW starts at point (1), a sync point has no effect. If TRBB tries to take a sync point without having first issued a command to receive data, it will be abended because it is not valid to perform sync point with a synchronization level 2 conversation in receive state.
- A sync point at point (2) causes CICS to commit a record in system B before it has been deleted from system A. If either system (or the connection between them) fails before the distributed process is completed, data might be duplicated.
- Because minimum processing is needed before resources are committed, point (3) might be a safe place to take a sync point if the queue is long or the records are large. However, performance might be poor because many sync points are likely to be taken.
- If you take a sync point only at point (4), a failure before this point means that all data that is sent will have to be retransmitted. A distributed process that sync points only at this stage completes more quickly than one that sync points at point (3), provided that no failure occurs. However, it takes longer to recover. If more than two systems are involved in the process, this problem is made worse.
Remember that having too many conversations within one distributed transaction complicates error recovery. A complex structure might sometimes be unavoidable, but usually it means that the design could be improved by simplifying the structure of the distributed transaction.
An LUW must be recoverable for the whole process of which it forms a part. All changes that are made by both partners in every conversation must be backed out if the LUW does not complete successfully. Sync points are not arbitrary divisions, but must reflect the functions of the application. LUWs must be designed to preserve consistent resources so that when a transaction fails, all resources are restored to their correct state.