Managing transaction and system failures

To help you manage transaction failures and uncontrolled shutdowns of the system, a number of facilities are available to help ensure that:

  1. Files and databases remain in a coordinated and consistent state
  2. Diagnostic and warning information is produced if a program fails
  3. Communication between transactions is not affected by the failure

These facilities are discussed here under the following headings:

The actions taken by CICS® are described under Unit of work recovery and abend processing and Processing operating system abends and program checks.

Transaction failures

When a transaction fails, the following CICS facilities can be invoked during and after the abend process:

These facilities can be used individually or together. During the internal design phase, specify which facilities to use and determine what additional (application or systems) programming may be involved.

The RESP option on a command returns a condition ID that can be tested. Alternatively, a HANDLE CONDITION command is used in the local context of a transaction program to name a label where control is passed if certain conditions occur.

For example, if file input and output errors occur (where the default action is merely to abend the task), you may wish to inform the master terminal operator, who may decide to terminate CICS, especially if one of the files is critical to the application.

Your installation may have standards relating to the use of RESP options or HANDLE CONDITION commands. Review these for each new application.

HANDLE ABEND commands

As described in How CICS handles transaction abends, a HANDLE ABEND command can pass control to a routine within a transaction, or to a separately compiled program when the task abends.

The kind of things you might do in abend-handling code include:

Your installation may have standards relating to the use of HANDLE ABEND commands; review these for each new application.

EXEC CICS SYNCPOINT ROLLBACK command

ROLLBACK might be useful within your transaction if, for instance, the transaction discovers logically inconsistent input after some database updates have been initiated, but before they are committed by the syncpoint.

Before deciding to use it, however, consider the following:

Dynamic transaction backout (DTB)

DTB occurs automatically for all transactions that have recoverable resources. It is not an option you can specify on a transaction resource definition. (The actions of DTB are described under Transaction backout.)

Remember that:

Transaction restart after DTB

For each transaction where DTB is specified, consider also specifying automatic transaction restart. For example, for transactions that access DL/I databases (and are subject to program isolation deadlock), automatic transaction restart is usually specified.

Even if transaction restart is specified, a task will restart automatically only under certain default conditions (listed under Abnormal termination of a task). These conditions can be changed, if absolutely necessary, by modifying the restart program DFHREST.

Use of the program error program (DFHPEP)

Decide whether or not to include your own functions, examples of which are given in The CICS-supplied PEP. (DFHPEP is invoked during abnormal task termination as described at Abnormal termination of a task.)

System failures

Specify how an application is to be restarted after an emergency restart.

Depending on how far you want to automate the restart process, application and system programming could provide the following functions:

Handling abends and program level abend exits

Unit of work recovery and abend processing describes how CICS processes abend requests and executes program level abend exit code.

Information that is available to a program-level exit routine or program includes the following:

Command Information provided
ADDRESS TWA The address of the TWA
ASSIGN ABCODE The current CICS abend code
ASSIGN ABPROGRAM The name of the failing program for the latest abend
ASSIGN ASRAINTRPT The instruction length code (ILC) and program interrupt code (PIC) data for the latest ASRA or ASRB abend.
ASSIGN ASRAKEY The execution key at the time of the last ASRA, ASRB, AICA, or AEYD abend, if any
ASSIGN ASRAPSW The PSW for the latest ASRA or ASRB abend
ASSIGN ASRAREGS The general-purpose registers for the latest ASRA or ASRB abend
ASSIGN ASRASPC The type of space in control at the time of the last ASRA, ASRB, AICA, or AEYD abend, if any
ASSIGN ASRASTG The type of storage being addressed at the time of the last ASRA or AEYD abend, if any
ASSIGN ORGABCODE Original abend code in cases of repeated abends
Notes:
  1. If an abend occurs during the invocation of a CICS service, issuing a further request for the same service may cause unpredictable results because the reinitialization of pointers and work areas and the freeing of storage areas in the exit routine may not have been completed.
  2. ASPx abends, which are task abends while in syncpoint processing, cannot be handled by an application program.

In program-level abend exit code, you might want to perform actions such as the following (although it is best to keep abend exit code to a minimum):

For transactions that are to be dynamically backed out if an abend occurs, beware of writing exit code that ends with a RETURN command. This would indicate to CICS that the transaction had ended normally and would therefore prevent dynamic transaction backout (and automatic transaction restart where applicable). (See the description of program level abend processing under How CICS handles transaction abends.)

Exit programs can be coded in any supported language, but exit routines must be in the same language as the program of which they are a part.

See the CICS Messages and Codes manual for the transaction abend codes for abnormal terminations that CICS initiates, their meanings, and the recommended actions.

Programming information relating to the coding of program-level exit code (such as addressability and use of registers) is in the CICS Application Programming Guide. For background information, see the CICS Application Programming Guide.

Processing the IOERR condition

Any program that attempts to process an IOERR condition for a recoverable resource must not issue a RETURN or SYNCPOINT command, but must terminate by issuing an ABEND command. A RETURN or SYNCPOINT command causes the recovery manager to complete the unit of work and commit changes to recoverable resources.

START TRANSID commands

In a transaction that uses the START TRANSID command to start other transactions, observe the following points to maintain logical data integrity:

  1. Always use the PROTECT option of the START TRANSID command. This ensures that if the START-issuing task is backed out, the new task will not start.
  2. If you pass data to the started transaction (on one of the data options FROM, RTERMID, RTRANSID, or QUEUE), ensure you define the associated temporary storage queue as recoverable. The temporary storage queue is named on the REQID option of the START command when using any of the data options. To make the temporary storage queue recoverable, define the queue in a temporary storage table using the DATAID option of the DFHTST TYPE=RECOVERY macro (see Recovery for temporary storage).

    This ensures that data being passed to another task is deleted from the temporary storage queue if the START-issuing task fails and is backed out.

Use of a recoverable DATAID also ensures that, if a system failure occurs after the START-issuing task has completed its syncpoint, the START command is preserved. CICS starts the transaction specified on a recoverable START command after an emergency restart, when the expiry time is reached and provided the terminal specified the TERMID option is available. Note that a DATAID is relevant only if data is being passed to the started transaction.

Note:
Consider using EXEC CICS RETURN TRANSID(...) with the IMMEDIATE option if the purpose is to start the next transaction in a sequence on the same terminal. This does not unlock the terminal, incurs less overhead, and, in a dynamic transaction routing (DTR) environment, the transaction is eligible for DTR.

PL/I programs and error handling

ON-units are a standard method of error-handling in PL/I programs. If the execution-time option STAE is specified, CICS program control services set up an exit routine that activates the PL/I ON-units.

This exit routine can handle:

Note that, under CICS, PL/I execution-time options can be specified only by the PLIXOPT character string.

For details of PL/I coding restrictions in a CICS environment, see the appropriate PL/I programmer’s guide for your compiler.

[[ Contents Previous Page | Next Page Index ]]