Error Handling

Contents
[hide]

1 Introduction 2 Just Abend 3 Fail-Fast 4 The Decision Process

Introduction
Pragmatically, there are two approaches to error handling in a CICS application: fail-fast and just abend.

Just Abend
The latter approach is relatively simple, as it is the default for most exceptions that may occur in a CICS API - don't code the NOHANDLE, RESP and RESP2 options. When most exceptional conditions occur in a CICS API, your program will abend. You will be the recipient of a core dump of the machine state at the point of error. An application programmer can also do something similar with respect to (e.g.) an unexpected SQLCODE. Check the appropriate return code and EXEC CICS ABEND if it is not of the expected value. This has its good and bad points. Coding in this manner ensures the machine state hasn't been altered by the execution of any application code. However, you must debug by reading the core dump, a technique currently out of favor in many IT shops. Additionally, care must be taken to not produce a large number of dumps due to an error which prevents processing from continuing. For example, if DB2 is currently unavailable, all applications written in this manner will begin dumping core and only serve to exacerbate the problem by potentially bringing down the CICS region.

Fail-Fast
The fail-fast approach is to detect and report the error. While one may argue that abending is a mechanism by which an error is reported, the idea here is to report the error in a manner more conducive to quick error resolution. One available avenue for reporting errors is the WRITE OPERATOR API. This allows reporting of the error in a manner friendly to automation software which can be used to (e.g.) page support staff. Having

the error recorded in the system log can have other benefits, as the error message can be viewed in context with other messages. Another avenue of reporting is a special purpose TD queue, perhaps redirected to a spool DD. Either of these error reporting avenues are assisted by shared subroutines which encapsulate the necessary code. Subsequent to reporting the error, an application may choose to produce a core dump, with or without abending. The downside of the fail-fast approach is that at this point the machine state has been altered from what it was at the time of the error by the error reporting code. Care must be also taken when using this approach to not produce a large number of messages due to an error which prevents processing from continuing. Overwhelming the spool merely exacerbates the problem.

The Decision Process

At the end of the day, the decision as to which approach is used must take into consideration the cost to the business of each type of failure, the cost of an outage, the skill set of those responsible for error resolution, shop standards, and any applicable Service Level Agreements. Example code implementing the fail-fast approach can be found in file 788 on the CBTTAPE web site. Craig Schneiderwent 14:03, 5 October 2008 (CDT) Category: Programming
article

discussion

view source

history

navigation

Log in / create account

Main Page Help Need an id? Community Forum

CICS Jobs CICS in the news CICS alerts Online users News feed

create content
Create page Boot Camp How do I...

discover pages
Categories Popular pages Recent pages Site statistics Wanted pages Random page Adoption plan

resources
IBM CICS site CICS Infocenter The Master Terminal Trivia

search
Go Search

toolbox

What links here Related changes Upload file Special pages Printable version Permanent link

This page was last modified 19:03, 5 October 2008.

This page has been accessed 761 times.

Privacy policy

About CICS Wiki

Disclaimers