Application design

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:

Application
In this context, application refers to a set of one or more transactions designed to fulfill the particular needs of the user organization.
Transaction
This refers to a set of actions within an application which the designer chooses to regard as an entity. It corresponds to a unit of execution, which is typically started in a CICS region by invoking the transaction by its identifier from a terminal attached to CICS. It is for the designer to decide how (if at all) to subdivide an application into transactions, and whether the transactions should consist of just one unit of work, or more than one.

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:

  1. Check the customer’s name and address and allocate an order number
  2. Record the details of ordered items and update inventory files
  3. Print the invoice and shipping documents

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.

Splitting the application into transactions

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:

Files accessed by each transaction

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).

Updates performed by each processing unit

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.

Consistency 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.

Immediacy of updates

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.

Relationships between 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).

SAA-compatible applications

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 ]]