Can (should) they be standardized?

Error Severity Levels

by Conrad Weisert
May 1, 2013
© 2013 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.


Background: Operating system conventions

I was just reading an extended discussion on Linked-In about error-severity levels in a program, and I was struck with the sense of rediscovery of techniques we were using decades ago. I can't think of a textbook that addresses this issue thoroughly, so let me try to start. First let's look at a little historical background:

Both the codes and those actions, of course, were only conventional. You could set up a job to do anything you wanted for any return-code values, as long as a program didn't ABEND.2

Programming conventions

Some applications extended the OS/360 conventions, especially in the case of transaction processing programs. Our own company and several of our clients adopted the following conventions and provided a standard subroutine for issuing error-diagnostic messages, first in PL/I, later in COBOL, and eventually, with necessary changes, in C++ and Java:

1. Upon encountering an error, the program shall
    CALL SYSERR(lvl, msg);
where the msg text conventionally began with an identifier3 that contained the name of the subroutine executing the call, and the lvl code was a symbolic equivalent of one of the conventional JCL return codes.

2. Upon termination of the program, a companion exit routine would set the OS return code to the highest value encountered during the run.

3. A limit, which the program could override, defined a maximum number of errors allowed during the run. When that number was exceeded, the program would terminate. This feature was useful for preventing an out-of-control program from generating hundreds of pages of meaningless output (for example if one accidentally fed a source program to a program expecting a file of transactions).

There were other features, but you get the idea. Programmers liked using the routine, and it was found (and still is) in almost every program developed in those organizations.4

Further obvious refinements were needed to support multi-threaded programs. When should a subtask be allowed to terminate the main task and how?

Other ideas?

Let us know if you've developed or if you know of any better way of handling program-discovered errors, diagnostic messages, and severity levels. What related standards, if any, would you support?


1—Dave Farber of Bell Telephone Laboratories referred to this level at a SHARE meeting as "GO DAMMIT!"
2—abnormal end: the most drastic action when further processing may cause serious damage. (Actually, later versions of OS supported conditional step execution even if an ABEND had occurred, but prudent programmers avoided it.)
3—In some programming languages this identifier could be generated automatically, but in most languages it was just a convention programmers were expected to comply with. That avoided the frustration users feel when they get a mysterious message from, say, Windows®, advising that "the specified program cannot . . . ".
4—If you'd like a copy contact us at cweisert@acm.org and let us know which language and environment you need it for.

Return to table of contents
Return to technical articles

Last modified May 1, 2013