11. Handling Errors – ILE RPG in Easy Bytes

You can anticipate some errors that might arise during program execution. For those cases, most programmers prefer to practice defensive programming; that is, they handle errors internally within the program rather than letting the them cause a program abend (abnormal ending). You can use any of several alternative methods to handle errors.

For these situations, ILE RPG supports another means of trapping errors: the Monitor (Begin a Monitor Group) and On-error (On Error) operations. These operations provide error trapping within a block of multiple code lines in a program.

For example, a date variable contains a nonexistent date, a numeric variable has a nonnumeric value, or a conversion function encounters problems when converting a character value to a numeric value. RPG offers several approaches to dealing with invalid data. We’ve already discussed how to capture these types of errors when they happen by using the %Error and %Status functions, and the Monitor and On-error operations.

RPG also supports several error-handling mechanisms that take effect on a wider scope: File information data structure (Infds) File error subroutine (Infsr) Program status data structure (Psds) Program error subroutine (*Pssr) File Information Data Structure For each file in an ILE RPG program, you can define a file information data structure (Infds) to provide feedback to your program about a file’s current status, along with details about any file errors that may have occurred. To name a file information data structure, use the Infds keyword when you declare the file:

With this capability, you can reuse a single copy of code without having to retype it in every module. A copybook is especially useful for storing any reusable code snippets which tend to be duplicated across many programs, such as common error handling code To use a copybook, you use an editor to store all the reusable code in a source member (here we call it STATUSCODE). Then in each source member that needs the code in the copybook, at the point where the code normally appears, code the following compiler directive:

Unit 9 discussed the SQL Communication Area, which the SQL precompiler automatically inserts into any SQLRGPLE program. To review, the SQLCA is updated every time the program executes an SQL statement. Two important subfields in this data structure, Sqlcode and Sqlstate, signal the success or failure of an SQL statement.

Many operation codes can set a resulting indicator in positions 73–74 (Lo) to signal an error. The error resulting indicator serves the same purpose as the (E) extender. When an error occurs on a line that includes an error resulting indicator, that indicator is set to *On and the program continues—in this case, the %Error function is not set to *On.