Handling errors

Message handlers should be designed to handle errors that may occur in the pipeline.

When an error occurs in a message handler program, the program is invoked again for error processing. Error processing always takes place in the response phase of the pipeline; if the error occurred in the request phase, subsequent handlers in the request phase are bypassed.

In most cases, therefore, you should write your handler program to handle any errors that may occur.

  1. Check that container DFHFUNCTION contains HANDLER_ERROR, indicating that the message handler has been called for error processing.
    Tip:
    • If DFHFUNCTION contains any other value, the message handler has not been invoked for error processing, and these steps do not apply.
  2. Analyze the error information, and determine if the message handler can recover from the error by constructing a suitable response.

    Container DFHERROR holds information about the error. For detailed information about this container, see Container DFHERROR.

    Container DFHRESPONSE is also present, with a length of zero.

  3. Perform any recovery processing.
    • If the message handler can recover, construct a response, and return it in container DFHRESPONSE.
    • If the message handler can recover, but no response is required, delete container DFHRESPONSE, and return container DFHNORESPONSE instead.
    • If the message handler cannot recover, return container DFHRESPONSE unchanged (that is, with a length of zero).
Start of changeIf your message handler is able to recover from the error, pipeline processing continues normally. If not, CICS generates a SOAP fault that contains information about the error. In the case of a transaction abend, the abend code is included in the fault.End of change