Use the HANDLE CONDITION command to specify the label to which control is to be passed if a condition occurs. You must include the name of the condition and you must ensure that the HANDLE CONDITION command is executed before the command that may give rise to the associated condition.

You cannot include more than 16 conditions in the same command. You must specify any additional conditions in further HANDLE CONDITION commands. You can also use the ERROR condition within the same list to specify that all other conditions are to cause control to be passed to the same label.

The HANDLE CONDITION command for a given condition applies only to the program in which it is specified. The HANDLE CONDITION command:

  • Remains active while the program is running, or until:
    1. An IGNORE CONDITION command for the same condition is met, in which case the HANDLE CONDITION command is overridden
    2. Another HANDLE CONDITION command for the same condition is met, in which case the new command overrides the previous one
  • Is temporarily deactivated by the NOHANDLE or RESP option on a command

When control passes to another program, by a LINK or XCTL command, the HANDLE CONDITION commands that were active in the calling program are deactivated. When control returns to a program from a program at a lower logical level, the HANDLE CONDITION commands that were active in the higher-level program before control was transferred from it are reactivated, and those in the lower-level program are deactivated.

The syntax of the HANDLE CONDITION command is as follows:



The 'condition' represents the exceptional condition. The label is the name of the paragraph or routine to which the control will be passed when the specified condition occurs. If there is no label the default action will be taken. The general ERROR condition can be specified within the same list to specify that all other conditions cause control to be passed to the label specified in the ERROR option. The maximum number of handle conditions that be specified in a single HANDLE CONDITION is 12.

For example, the following HANDLE CONDITION command checks for the length error (LENGERR) and record-not-found (NOTFND) conditions.

(NOTFND) conditions

If a length error occurs, after the preceding HANDLE CONDITION command is issued, CICS gives control to the TOOLONG exception routine. Similarly if no rows found the control is passed to the NOREC routine. If any other exception condition occurs, CICS gives control to the generalized exception routine, GENERR. The use of ERROR option in the HANDLE CONDITION command prevents from taking the default action for conditions not specified in the command.

The HANDLE CONDITION command is a convenient way to check for command related exception conditions in an application program. However, the use of HANDLE CONDITION may complicate rather than simplify the programs you write. Remember that HANDLE CONDITION options apply to commands that are executed after the HANDLE CONDITION command is issued. It is not uncommon that the error-handling logic for a given command may be coded in a different section of the program from the command itself. This separation can cause difficulties when debugging the program.

Remember also that some exception conditions can occur on several different commands. This presents no problem if a HANDLE CONDITION that specifies the appropriate exception routine precedes each command. Consider the following sequence of commands:

sequence of commands

In this example the RECEIVE and READ commands are preceded by separate HANDLE CONDITION commands, each of which specifies the LENGERR option. If a length error occurs on the receive command, CICS gives control to the LONGMSG routine. If the READ command results in a length error condition, the control is passed to LONGREC. Each exception routine can perform processing that is appropriate to the command, which gave rise to the length error condition. However, if the same length error routine were specified for both the commands, then additional logic would be needed to determine which command caused the error.

A common technique for making this distinction is to examine the command function code in the EIB and then include the name of the command in an error message that is send to the terminal.

A similar consideration exists when the HANDLE CONDITION ERROR option is used in favor of the CICS default action. In order to help the user to determine what caused the error, an ERROR exception routine should include logic to analyze and report the cause of the error. The program could examine both the command function code (EIBFN) and the command response code (EIBRCODE) in the EIB. The error message could then identify the command that caused the error, as well as the nature of the error that occurred.

The most obvious disadvantage to using HANDLE CONDITION is, of course, that conditional branches are used to pass control to the program's exception routines. Since the straight-line flow of program execution is altered, the HANDLE CONDITION command violates strict structured programming conventions.

An exceptional condition routine passed by a HANDLE CONDITION command can contain another CICS command, which may cause the same exceptional condition. In this case there will be an infinite loop. This usually happens when an exceptional condition handling routine passed by a CICS command issues the same CICS command. Such loops can be avoided in the application program by issuing IGNORE command or by specifying NOHANDLE or RESP options in the command in the exception handling routine or by simply terminating the task.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics