This section tells you how to design your programs to use the CICS® recovery facilities effectively.
When deciding how to implement application processing units in terms of transactions, units of work, and programs, consider the following:
Short UOWs are preferable for several reasons:
In applications for which little or no re-keying is feasible (discussed in question 9 under Questions relating to recovery requirements), short units of work are essential so that all entered data is committed as soon as possible.
An application may require several interactions (input and output) with the user. CICS provides the following basic techniques for program design for use in such situations:
With conversational processing, the transaction continues to run as a task across all terminal interactions--including the time it takes for the user to read output and enter input. While it runs, the task retains resources that may be needed by other tasks. For example:
Conversational processing is not generally favored, but may be required where several file or database updates made by several interactions with the user must be related to each other--that is, they must all be committed together, or all backed out together, in order to maintain data integrity.
With pseudoconversational processing, successive terminal interactions with the user are processed as separate tasks--usually consisting of one UOW each. (This approach can result in a need to communicate between tasks or transactions (see Mechanisms for passing data between transactions) and the application programming can be a little more complex than for conversational processing.)
However, at the end of each task, the updates are committed, and the resources associated with the task are released for use by other tasks. For this reason, pseudoconversational transactions are generally preferred to the conversational type.
When several terminal interactions with the user are related to each other, data for updates should accumulate on a recoverable resource (see CICS recoverable resources for communication between transactions), and then be applied to the database in a single task (for example, in the last interaction of a conversation). In the event of a failure, emergency restart or dynamic transaction backout would need to back out only the updates made during that individual step; the application would be responsible for restarting at the appropriate point in the conversation. This may involve re-creating a screen format.
Bear in mind, however, that other tasks may try to update the database between the time when update information is accepted, and the time when it is applied to the database. Design your application to ensure that no other application can update the database at a time when it would corrupt your updating.
In those applications where one transaction needs to access working data created by a previous transaction, consider what mechanism should carry that data over. The possible mechanisms are discussed under two broad headings:
See also Implications of interval control START requests.
Main storage areas that you can use to pass data between transactions include:
CICS does not log changes to these areas (except as noted later in this section). Therefore, in the event of an uncontrolled shutdown, data stored in any of these areas is lost, which makes them unsuitable for applications needing to retain data between transactions across an emergency restart. Also, some of these storage areas can cause inter-transaction affinities, which are a hindrance to dynamic transaction routing. To avoid inter-transaction affinities, use either a COMMAREA or the TCTUA. For information about intertransaction affinities, see the CICS Application Programming Guide.
The advantages of main storage areas are realized only where recovery is not important, or when passing data between programs servicing the same task.
Resources recoverable by backout that can be used for communication between transactions include:
CICS can return all these to their status at the beginning of an in-flight UOW if a task ends abnormally.
You can use a temporary storage item to communicate between transactions. (For this purpose, the temporary storage item needs to be unique to the terminal ID. If the terminal becomes unavailable, the transaction sequence is interrupted until the terminal is again available.) The temporary storage queue-name (DATAID or QUEUE name) can be read and reread, but the application program must delete it when it is no longer needed to communicate between a sequence of transactions.
Transient data (intrapartition) is similar to temporary storage (auxiliary) for communicating between transactions. The main difference is that you can read each record in a transient data queue only once, after which the record is no longer available. Transient data must be specified as logically recoverable to achieve backout to the start of any in-flight UOW.
You can dedicate files or database segments to communicating data between transactions.
Transactions can record the completion of certain functions on the dedicated file or database segment. A progress transaction (whose purpose is to tell the user what updates have and have not been performed) can examine the dedicated file or segment.
In the event of physical damage, user VSAM files, DL/I, and DB2 databases can be forward recovered.
User-maintained data tables (UMTs), which are recoverable after a unit of work failure, can be a useful means of passing data between transactions. However, they are not forward recoverable and not recoverable after a CICS restart.
Coupling facility data tables updated using the locking model, and which are recoverable after a unit of work failure, can be a useful means of passing data between transactions. Unlike UMTs, coupling facility data tables are recoverable in the event of a CICS failure, CFDT server failure , or an MVS™ failure. However, they are not forward recoverable.
To avoid transaction deadlock (see Possibility of transaction deadlock), consider the following techniques:
Ways of doing this include the following:
This method requires special terminal operator action, which may not be practical within the constraints of the application. (For example, orders may be taken by telephone in random product number sequence.)
This method requires additional application programming, but imposes no external constraints on the terminal operator or the application.
This method requires less additional programming than the second method. However, issuing a synchronization point implies that previously processed data items in the transaction are not to be backed out if a system or transaction failure occurs before the entire transaction ends. This may not be valid for the application, and raises the question as to which data items in the transaction were processed and which were backed out by CICS. If the entire transaction must be backed out, synchronization points should not be issued, or only one data item should be entered per transaction.
Of the three methods, the second (sorting data items into an ascending sequence by programming) is most widely accepted.
Note that, if you allow updates on a data set through the base and one or more alternate index (AIX) paths, or through multiple AIX paths, sequencing record updates may not provide protection against transaction deadlock. You are not protected because the different base key sequences will probably not all be in ascending (or descending) order. If you do allow updates through multiple paths, and if you need to perform several record updates, always use a single path or the base. Define such a procedure in your installation standards.
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.
The PROTECT option on a START request ensures that, if the task issuing the START fails during the UOW, the new task will not be initiated, even though its start time may have passed. (See START requests for more information about the PROTECT option.)
Consider also the possibility of a started task that fails. Unless you include abend processing in the program, only the master terminal will know about the failure. The abend processing should analyze the cause of failure as far as possible, and restart the task if appropriate. Ensure that either the user or the master terminal operator can take appropriate action to repeat the updates. You could, for example, allow the user to reinitiate the task.
An alternative solution is for the started transaction to issue a START command specifying its own TRANSID. Immediately before issuing the RETURN command, the transaction should cancel the START command. The effect of this will be that, if a started task fails, it will automatically restart. (If the interval specified in the START command is too short, the transaction could be invoked again while the first invocation is still running. Ensure that the interval is long enough to prevent this.)
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.
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).
In cases where the application requires the reply to consist of a large amount of data that cannot all be viewed at one time (such as data required for browsing), several techniques are available, including:
The application program (using the SEND PAGE BMS commands) builds pages of output data on a temporary storage queue for subsequent display using operator page commands. (Such queues should, of course, be specified as recoverable, as described in Recovery for temporary storage.)
The application program should then send a committed output message to the user to say that the task is complete, and that the output data is available in the form of terminal pages.
If an uncontrolled termination occurs while the user is viewing the pages of data, those pages are not lost (assuming that temporary storage for BMS is designated as recoverable). After emergency restart, the user can resume terminal paging by using the CSPG CICS-supplied transaction and terminal paging commands. (For more information about CSPG, see the CICS Supplied Transactions manual manual.)
When a number of tasks direct large amounts of data to a single terminal (for example, a printer receiving multipage reports initiated by the users), it may be necessary to queue the data (on disk) until the terminal is ready to receive it.
Such queuing can be done on a transient data queue associated with a terminal. A special transaction, triggered when the terminal is available, can then format and present the data.
For recovery and restart purposes:
If the terminal at which the transaction runs is a printer, however, dynamic transaction backout (and a restart of the transaction by whatever means) may cause a partial duplication of output--a situation that might require special user procedures. The best solution is to ensure that each UOW corresponds to a printer page or form.