Error Reporting

Issuing Error Messages

JOCKEY writes error messages to a message log known as the STAT file. It also displays most messages on the sysout with DISPLAY ... UPON CONSOLE. (Black magic redirects these messages to the sysout -- they don't really go to a console.) The use of DISPLAY without the UPON CONSOLE clause may be used in development for debugging, but not in production.

Other applications have their own conventions. In particular, an interactive application may display messages on the user's screen.

Include Enough Information

An error message should specify: This information should be as specific as possible. Ask yourself: If this error occurs, what information would I like to have in order to investigate it? For example, a message might indicate the service order number and WTN associated with an error.

Building good, informative error messages may be tedious, but it's easier than reconstructing an error after the fact.

Different Messages for Different Errors

This idea is a special case of the previous advice. It is best explained with an example.

Suppose your program issues a message: USOC 1BHNF NOT FOUND. Then it abends. So far as you know, the program should have found that USOC. Evidently there's a bug in the program.

As you dig into the code, you discover that there are two different places that issue the same message. There's no obvious bug in either place. You don't know which possibility to pursue, and either one will take a lot of digging to investigate. It sure would be nice if you knew which piece of code had issued the message.

Now suppose one of the pieces had issued a slightly different message: USOC '1BHNF' NOT FOUND. It differs only by putting quote marks around the USOC, but that difference would tell you where the message was coming from.

In general: each error message should be issued only in a single kind of circumstance. Different circumstances call for different messages, even if they differ only trivially.

homeCOBOL Home [style forum]COBOL Style Forum