Program design

This section tells you how to design your programs to use the CICS® recovery facilities effectively.

Dividing transactions into units of work
You must decide how to implement application processing units in terms of transactions, units of work, and programs.
Processing dialogs with users
An application may require several interactions (input and output) with the user.
Mechanisms for passing data between transactions
In those applications where one transaction needs to access working data created by a previous transaction, you must decide which mechanism will pass the data between the transactions.
Designing to avoid transaction deadlocks
You must design your program to avoid transaction deadlocks. There are a number of techniques that you can use in your program to avoid this situation.
Implications of interval control START requests
Interval control START requests initiate another task—for example, to perform updates accumulated by the START-issuing task; this allows the user to continue accumulating data without waiting for the updates to be applied.
Implications of automatic task initiation (TD trigger level)
Specifying the TRANSID operand in the resource definition for an intrapartition transient data destination starts the named transaction when the trigger level is reached. Designate such a destination as logically recoverable. This ensures that the transient data records are committed before the task executes and uses those records.
Implications of presenting large amounts of data to the user
Ideally, a transaction that updates files or databases should defer confirmation (to the user) until such updates are committed (by user syncpoint or end of task).

Parent topic: Programming for recovery