There's no debate that the source-level debugger IBM introduced for the Integrated Language Environment (ILE) languages helped programmer productivity. While no one believes it's the best debugger out there, and it hasn't been improved much in the 10 years or so its been available, people love it.
However, there are alternatives, such as the so-called "GUI Debugger" from IBM and the debugger in WDSC, both of which provide a better debug interface. The fact is, though, that virtually everyone uses the green-screen source-level ILE debugger. So I dug into my upcoming book, RPG TNT: 101 Dynamite Tips 'n Techniques for RPG IV, and pulled out a few tips that make things even easier.
Show Me the Data!
Normally, if you want to view the content of a variable in the source-level debugger, you do one of two things:
- Place the cursor on the field in the debugger's source window and press F11.
- Type in the EVAL command, followed by the name of the field you want to view.
This is pretty straightforward and easy to do. But what if you have code that includes a variable with the same name as one of the debugger's commands?
For example, suppose a legacy application has been converted to RPG IV. A field named EVAL is declared in the application. This field contains the current evaluation rating of a product. You start debugging the application, set a break point after the field is populated, and position the cursor under the EVAL field. You get "Syntax error" instead of the field's value.
How do you get around it? The answer is %VAR(). This debugger built-in function allows you to wrap a field name so that the debugger knows that EVAL is a field name, not just a syntax error. For example, on the debugger command line, type the following:
Now, instead of the syntax error, you get to see the content of the field named EVAL.
How do you find this stuff out? Do this:
Start debug on your program. When the source window appears, press F1 (Help). Press Page Down (or Rollup if you have a 5250 display) until you see the RPG Language Examples help link. Press the Tab key to position the cursor in the space to the left of this link and press Enter.
At this point, you'll see more than a dozen links to examples of using the debugger in RPG IV. The first one, Display a Variable—RPG, is the one we want. Tab over to the space to the left of that and press Enter. The first page of this help topic isn't all that interesting, unless you've never used the debugger before. To get to the information we want, press Page Down. At the bottom of the screen is the following text:
Debug command: EVAL %VAR(EVAL)
Result: DEC = 22.1
Comment: If the variable has the same name as a debug
command, the %VAR keyword must be used.
This illustrates how and when to use %VAR. Note that it is required when the variable has the same name as a debugger command.
OK, so what are the debugger command names? Here's a list of debugger commands from the online help text:
- attr
- bottom
- break
- clear
- display
- down
- equate
- eval
- find
- help
- left
- next
- previous
- qual
- right
- sbreak
- set
- step
- tbreak
- thread
- top
- up
- watch
Source-Level Debugging RPG III
When the ILE debugger was introduced, it was the first time many RPG developers had ever used a source-level debugger. However, the source-level debugger for RPG III had already been around for a couple years. That debugger is still installed on the system today and can be used when debugging RPG III programs.
Assume you have an application with RPG IV programs that call legacy RPG III programs. What happens when you get to a point in the RPG IV program (during debugging) where it calls the RPG III program? Is your only choice to step over the CALL opcode? Absolutely not.
While debugging the RPG IV program, set a breakpoint at the CALL to the legacy RPG III program. Then continue debugging as normal.
When the debugger breaks on the CALL to the RPG III program, press Shift+F10 (command key F22). This is known as "Step Into." If the RPG III program was compiled correctly, the debugger will load a legacy source-level debugger for the RPG III program, and you can source-level debug it. The downside is, of course, that the legacy debugger has different function keys and syntax than the ILE debugger. So use caution.
To make sure your RPG III programs will support the Step Into option, you must do two things:
First, specify OPTION(*SRCDBG) or OPTION(*LSTDBG) on the CRTRPGPGM command (PDM option 14) when the program is created. Here's an example:
Second, when debugging, include the OPMSRC(*YES) parameter on the STRDBG command, as follows:
Specify OPMSRC(*YES) if any program being debugged is RPG III (even if the main program not RPG III).
More tips on debugging are available in the "Debugging RPG Programs" session that will be presented at the RPG World 2007 Conference. To find out more, visit RPGWorld.com.
Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.
LATEST COMMENTS
MC Press Online