Often, when I'm debugging an RPG IV program, I run across some built-in functions whose values have been set by an opcode or perhaps even the %PARMS built-in function. As we all know, for some reason, IBM seems to have decided that we don't need to see the value represented by these built-in functions. So we are left to step through our code, watch our logic unfold, and guess what the built-in function's value is.

One way to circumvent this shortcoming in the debugger is to copy the value of those built-in functions to a work field. Then, using debug, you can view the content of those fields to see what the built-in function was set to.

The problem with this technique is that it puts variables and logic into the program that have nothing to do with the program itself. While it is fine for development/debug mode applications, production mode applications certainly should not have that extra stuff planted in them.

This is where compiler directives can help. While they don't completely resolve the issue at hand, they do provide a workaround for those annoying debugging issues related to built-in functions.

The basic idea is that you use the /IF DEFINED directive along with some descriptive word, such as "DEBUG," and condition the inclusion of certain lines of code based on that word being defined at compile time. You then include declarative statements and logic that define some work fields and then copy the value of the built-in functions into those work fields. Then, while you're in debug mode, you can view the content of the built-in function as it was when it was copied into the work fields.

The example in Figure 1 declares three works fields and then copies the value represented by %FOUND and %PARMS into two of those work fields.

Figure 1: Use compiler directives to simplify debugging.

The good thing about this technique is that, unless you also include a /DEFINE DEBUG statement in your source code or specify DEFINE(DEBUG) when you compile, the source code between these /IF DEFINED(DEBUG) and /ENDIF statements is not included in the compiled object.

If you are not a fan of the /IF and /ENDIF compiler directives and simply want to test for "debug mode" at runtime, you can use the DEBUGMODE() procedure from the RPG ToolKit. It provides you with a way to check for debug mode at runtime and then do whatever is necessary, based on the mode the program is in.

Here's an example of using the DEBUGMODE built-in function. Note that you can test for debug mode or not debug mode by optionally specifying *ON or *OFF for the first parameter.

Bob Cozzi has been programming in RPG since 1978. Since then, he has written many articles and several books, including The Modern RPG Language--the most widely used RPG reference manual in the world. Bob is also a very popular speaker at industry events such as RPG World and is the author of his own Web site and of the RPG ToolKit, an add-on library for RPG IV programmers.

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.

---

MC Press books written by Robert Cozzi available now on the MC Press Bookstore.

		RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
		The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95 Now On Sale