Modifying default CICS exception handling

CICS® provides the following EXEC CICS commands which modify the default CICS exception handling and one which modifies the way CICS handles abends:

Note:
These commands cannot be used in C, C++, or Java™ programs. The rest of this chapter is not relevant for these languages.

HANDLE CONDITION
Specify the label to which control is to be passed if a condition occurs.
IGNORE CONDITION
Specify that no action is to be taken if a condition occurs.
HANDLE ABEND
Activate, cancel, or reactivate an exit for abnormal termination processing.

An abend is the commonest way in which CICS handles exception conditions.

The current effect of IGNORE CONDITION, HANDLE ABEND, and HANDLE CONDITION may be suspended by using PUSH HANDLE and reinstated by using POP HANDLE .

You have two ways of passing control to a specified label:

  1. Use a HANDLE CONDITION condition(label) command, where condition is the name of an exception condition
  2. Use a HANDLE CONDITION ERROR(label) command

The HANDLE CONDITION command sets up some CICS code to name conditions that interest you, and then uses this code to pass control to appropriate sections of your application if those conditions arise. So with an active HANDLE CONDITION command, control goes to whichever label you specified for that particular condition.

The same condition can arise, in some cases, on many different commands, and for a variety of reasons. For example, you can get an IOERR condition during file control operations, interval control operations, and others. One of your first tasks, therefore, is to sort out which command has raised a particular condition; only when you have discovered that, can you begin to investigate why it has happened. This, for many programmers, is reason enough to start using the RESP option in their new CICS applications. Although you need only one HANDLE CONDITION command to set your error-handling for several conditions, it can sometimes be awkward to pinpoint exactly which of several HANDLE CONDITION commands is currently active when a CICS command fails somewhere in your code.

If a condition which you have not named arises, CICS takes the default action, unless this is to abend the task, in which case it raises the ERROR condition. If you name the condition but leave out its label, any HANDLE CONDITION command for that condition is deactivated, and CICS reverts to taking the default action for it, if and when it occurs.

The need to deal with all conditions is a common source of errors when using the HANDLE CONDITION command. When using an unfamiliar command, you should refer to the description of the command in the CICS Application Programming Reference manual to find out which exception conditions are possible. Even if you then issue HANDLE commands for all of these, you may not finish all the error-handling code adequately. The outcome is sometimes an error-handling routine that, by issuing a RETURN command, allows incomplete or incorrect data changes to be committed.

The best approach is to use the HANDLE CONDITION command, but to let the system default action take over if you cannot see an obvious way round a particular problem.

Bearing in mind the distinction between an error condition, a condition that merely causes a wait (see page How CICS keeps track of what to do for examples of conditions that cause a wait), and the special case of the SEND MAP command overflow processing, a HANDLE CONDITION command is active after a HANDLE CONDITION condition(label), or HANDLE CONDITION ERROR(label) command has been run in your application.

If no HANDLE CONDITION command is active for a condition, but one is active for ERROR, control passes to the label for ERROR, if the condition is an error, not a wait.

If you use HANDLE CONDITION commands, or are maintaining an application that uses them, do not include any commands in your error routine that can cause the same condition that gave you the original branch to the routine, because you will cause a loop.

Take special care not to cause a loop on the ERROR condition itself. You can avoid a loop by reverting temporarily to the system default action for the ERROR condition. Do this by coding a HANDLE CONDITION ERROR command with no label specified. At the end of your error processing routine, you can reinstate your error action by including a HANDLE CONDITION ERROR command with the appropriate label. If you know the previous HANDLE CONDITION state, you can do this explicitly. In a general subroutine, which might be called from several different points in your code, the PUSH HANDLE and POP HANDLE command may be useful--see Using PUSH HANDLE and POP HANDLE commands.

[[ Contents Previous Page | Next Page Index ]]