Error Handling › Common Error Subroutines

Common Error Subroutines

Most CA Ideal programmers are familiar with the <<ERROR>> procedure as a means of producing information for the end-user when a processing error occurs. A large number of sites have attempted to standardize this processing by using a common subprogram to display and record the error information.

There are two problems that generally arise from the use of a common subprogram:

• First, by simply being a common subprogram, it participates in a very high number of PGM-PGM-CALL relationships in CA‑DataDictionary. Changes to the common program result in a very large number of dictionary calls when you issue a CA Ideal DUPLICATE or MARK STATUS command. This can make it necessary to run overnight batch jobs to do the DUPLICATE or MARK when you change the common subprogram.
• Second, the subprogram is usually called directly from the <<ERROR>> procedure, which can cause anomalies in its processing. When the <<ERROR>> procedure is entered, CA Ideal processes all subsequent statements in an error mode until the QUIT or PROCESS NEXT that leaves the scope of the procedure. A DO or CALL to a subordinate procedure or program is still in error mode. This prevents error recursion, where errors in the <<ERROR>> procedure could make the application loop endlessly. The effects of being in this error mode are often subtle, but an obvious one is that a called subprogram cannot handle errors in its own code. This means, for example, that a common error subprogram that reads message text from a database table cannot handle database errors.

There is a single solution to both problems: A horizontal calling structure, where a dispatcher program calls all the processing programs according to the value of a control variable. The same dispatcher can invoke the common error subprogram with the following advantages:

• The <<ERROR>> procedure of the failing program sets return variables to describe the error and quits the program. This leaves error mode and allows the error handler full recovery of its own errors.
• The error subprogram is called only by dispatcher programs, which are much fewer in number and eliminate the overworking of the relationship file in the dictionary. The nesting depth of the application is reduced by one, which saves storage and reduces the complexity of the calling structure.