The system administrator requests the CICS recovery facilities described so far. He makes the necessary entries in the appropriate tables. The only responsibility of the application programmer is to make sure that all the entries are in place.

Other CICS recovery facilities require the active participation of the programmer. CICS commands can be used within the program to Handle processing errors, Provide a programmer supplied abend processing routine. Indicate the completion of a LUW, record data not recorded by CICS journaling services, etc.For handling processing errors the CICS commands like HANDLE CONDITION, IGNORE CONDITION, and options like RESP, NOHANDLE, etc., which were discussed in the chapter on exception handling can be used.

Another option for error handling is to create a program-level abend exit. This is an application program that receives control when a task abends. Program level abend exists are specified using the HANDLE ABEND command which is discussed in a later chapter. If specified, an abend exit receives control before any other abend processing is performed. This process is shown in the following figure.

Program level abend exits are useful when unexpected abends or error conditions not handled by the exception condition handling routine causes a task to be abnormally terminated by CICS. The abend-processing program can decide whether abend processing should be allowed to continue or control should be returned to the next higher level of application processing.

An abend exit can request DTB using the SYNCPOINT ROLLBACK command. It can also display a special termination message or instructions on how to restart the transaction. Such messages can be more helpful than the CICS abend messages. Keep in mind that passing control to an abend exit requires more processing than handling an exception routine. As a result, including processing to handle exception conditions is the recommended method for trapping common CICS related processing errors. Abend exits are recommended only if they can trap errors and thus avoid an abend that cannot be detected any exception condition handling techniques.

CICS Recovery Facilities invoked by the Abnormal Termination of a TaskCommitting a LUW

CICS Recovery Facilities invoked by the Abnormal Termination of a TaskCommitting a LUW

Some tasks perform larger number of resource modifications before they terminate processing. If such a task abends, much processing will be required to back out all the changes. As we mentioned earlier, a task's work is automatically committed at task termination. Tasks can commit a portion of work completed without terminating the task by issuing a SYNCPOINT Command. This command indicates that the processing of the current lUW is completed and can be committed. If the task abends after the sync point is created, update processing done before the sync point will not be backed out. However, any resource modifications made after the SYNCPOINT command is issued will be backed out. The following figure illustrates this process:

Committing with Syncpoints

Committing with Syncpoints

When a task performs a series of updates during processing, the SYNCPOINT command can be used to commit a portion of those updates. In our order entry example, suppose that the user can enter information for four order item on a single screen, the program could use a SYNCPOINT command to commit the updates for one of the entered items before continuing with the next. However, this should only be done if the updates will not need to be backed out if the task abends after the sync point. If the complete order entry transaction is viewed as a single LUW, this would not be appropriate.

An application program can request DTB with the ROLLBACT option of the SYNCPOINT command. ROLLBACK causes all resource modifications since the last sync point to be backed out. The backout performed is the same as that provided by the Dynamic Backout Program during automatic recovery. ROLLBACK should be used when a task has determined that updates performed during the current LUW are incorrect and must be backed out. This option is also useful in an abend exit routine to cause backout for the current LUW to be performed while allowing processing to continue. This can be helpful in that backout processing is performed without the terminal user receiving a CICS abend message.

Handling Logical Deletes

Earlier we mentioned that DTB would delete the new records added. This is not true in the case of records added to a VSAM/ESDS. This is because an ESDS does not support the physical deletion of records. To physically delete a record form an ESDS, you have to create a new copy of the data set.

Most applications using ESDS in a CICS environment provide a method for logically deleting a record. This is normally done with a flag field that can be set to indicate that the record is considered deleted. Records that are logically deleted should be ignored by other application programs in the system. Programs that use files containing logically deleted records should contain the logic needed to handle them. Additional work is needed to logically delete records during recovery processing. To logically delete records that have just been added to an ESDS, the installation must provide a DTB file error exit program. This program receives control when a record added to an ESDS must be backed out during recovery processing.

The exit program performs the processing specified by the application system to logically delete the record. DTB then rewrites the record to the file after the exit program is complete. Keep in mind that if the application uses logical deletion to delete existing records from an ESDS, no additional work is needed to restore records that were deleted since the last sync point. DTB will recover those deletes by restoring the before-images of the records (without the delete flag set).

Journaling Changes to Data Sets

Earlier we have said that application program may need to provide additional recovery processing of their own. This processing may include generating an audit trail or providing data to be used for forward recovery of a data set that has been destroyed or incorrectly updated. Applications can use the CICS journaling facility to collect file modification data automatically or collect additional information created by the application program itself.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics