In general, recovery processing should be performed for all tasks whose failure would affect the integrity of critical system resources. A task that does not modify any system resources, like a simple file inquiry, will not affect the integrity of the system if it does not complete processing. Such transactions need not be specified as recoverable.

The recovery processing provided by CICS is sufficient for most applications. After a failure, CICS will automatically return recoverable resources modified by recoverable transactions to a pre-failure state. This will back out all updates performed by the last LUW for the transaction. In most cases, the user will need to repeat the transaction that was in progress at the time of failure. Any additional recovery processing that is desired will have to be supplied by the application program.

After deciding which transactions and resources are to be defined as recoverable, you should create the appropriate entries in the CICS tables. When selecting the resources to be recovered, keep, in mind that if a recoverable transaction modifies a resource that is not defined as recoverable, automatic recovery of that resource Will not be performed by CICS.

CICS resources are used to store the data needed for recovery processing. The more transactions and resources that are defined as recoverable, the more CICS processing will be required, whether or not a failure ever occurs. To minimize the effect of recovery processing on system performance, only those functions critical to the integrity of the system should be defined as recoverable.

Another consideration for recovery design relates to the enqueing of file resources. You are already familiar with the exclusive control enqueue that prevents two tasks from attempting to update a record at the same time. If a file resource is not designated recoverable, the first task to request an update gets exclusive control of the record until it issues a DEQ command. If a resource is designated as recoverable, the task gets exclusive control of the record until either the end of the task or the end of a LUW is signaled by a syncpoint. The addition of recovery process can make this enqueue last considerably longer than it would when the file is not recoverable. This type of enqueuing occurs for all READ for UPDATE, WRITE and DELETE commands issued against a recoverable file. Similar enqueuing techniques are used to handle updates to recoverable intrapartition TDQs , TSQs and DL/I data bases. For this reason, you should try to minimize the amount of time that a recoverable task has control of a recoverable resource. This will help to reduce contention between tasks that use the same recoverable resources.

Thus we can divide the CICS recovery services into two:

  1. Recovery services automatically provided by CICS without any intervention from the task.
  2. Recovery services provided by CICS at the request of the application programs or provided by user defined exits to CICS processing modules.

These services can be used independently or together to achieve your recovery objectives

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

IBM Mainframe Topics