This topic tells you how to design your applications so that they take advantage of the CICS® recovery facilities.
Note the following terms used in this topic:
Ideally, but not necessarily, a transaction would correspond to a UOW. Dividing the business application into units of work that correspond to transactions simplifies the entire recovery process.
An example of a typical business application is an order-entry system. A typical order-entry application includes all the processes needed to handle one order from a customer, designed as a set of processing units, as follows:
Depending on the agreed recovery requirements statement, noting details of ordered items and updating files can be implemented either as one large transaction or as several transactions--one for each item within the order.
Specify how to subdivide the application into transactions. Name each transaction, and describe its function in terms that the terminal user can understand.
Your application could include transactions to recover from failures, such as:
Specify the files and databases that can be accessed in each processing unit.
Of the files and databases that can be accessed, specify those that are to be updated (as distinct from those that are only to be read).
For those files and databases updated by an application processing unit, specify how to apply the updates; factors to consider here include the consistency and the immediacy of updates.
Specify which (if any) updates must happen in step with each other to ensure integrity of data. For example, in an order-entry application, it may be necessary to ensure that a quantity subtracted from the inventory file is, at the same time, added to the to-be-shipped file.
Specify when newly entered data must or can be applied to the files or databases. Possibilities include:
You will need the above information when deciding on the internal design of application processing units.
Specify what data needs to be passed from one application processing unit to another.
For example, in an order-entry application, one processing unit may accumulate order items. Another, separate, processing unit may update the inventory file. Clearly, there is a need here for the data accumulated by the first processing unit to be passed to the second.
This information is needed when deciding what resources are required by each processing unit (see Mechanisms for passing data between transactions).
The resource recovery element of the Systems Application Architecture® (SAA) common programming interface (CPI) provides an alternative to the standard CICS application program interface (API) if you need to implement SAA-compatible applications. The resource recovery facilities provided by the CICS implementation of the SAA resource recovery interface are the same as those provided by CICS API. Therefore, you have to change from CICS API to SAA resource recovery commands only if your application needs to be SAA-compatible.
To use the SAA resource recovery interface, you need to include SAA resource recovery commands in your applications in place of EXEC CICS SYNCPOINT commands. This book refers only to CICS API resource recovery commands; for information about the SAA resource recovery interface, see the CPI Resource Recovery Reference manual.
[[ Contents Previous Page | Next Page Index ]]