IBM i > DEVELOPER > RPG

Debugging RPG IV Programs - The Green-Screen Way

Learn the secrets to debugging in green screen


 

Lately we’ve been asked a surprising number of questions about how to debug RPG IV programs, so we thought it was time to cover the topic. Three primary debuggers are available from IBM – one green screen, one stand-alone GUI debugger and one in the WDSC toolset. In this article, we’ll cover the use of the green-screen debugger. We hope even those of you who already knew about the green-screen source view debugger pick up on a few often-missed features.

Perhaps it shouldn’t surprise us that many people don’t seem to even know that a source view debugger similar to the Start Interactive Source Debugger (STRISDB) used with RPG/400 is available for RPG IV programs. After all, the STRISDB command doesn’t work on RPGLE programs and the Start Debug (STRDBG) command doesn’t do anything terribly useful if you compile your programs using the system-shipped defaults.

Debug View Parameters

If you’re one of those folks who don’t realize you have a source view debugger for your ILE language programs, here’s the secret: the Debug View (DBGVIEW) parameter on the compile commands. The shipped default for this command (for some mysterious reason) is *Stmt, which means you can only set breakpoints the old fashioned way, i.e., without the benefit of source view.

The more productive way to debug ILE language programs is to use one of the other Debug View options. The most commonly used are *Source, *List and *All. *Source lets you use the source code from the member during a debug session. The issue you can run into with *Source is that the source member may have been changed since the program was compiled, making the debug session, at best, very confusing. Or the source may not even be available on the system where you want to debug the program. *List takes care of that issue by keeping a copy of the source in a compile listing format – with the compiled program object. This copy is complete with expanded file definitions and /Copy source. Don’t be misled into thinking that *Source stores a copy of the source with the program object – it doesn’t. We typically choose the *All option, which includes both the source view and the listing view. That way we always know we have a valid version of the source available for debug. After all, when debugging, we can use all the help we can get! The debug view parameter is one of the most frequently changed command defaults in most shops we see.

STRDBG

Assuming you’ve compiled the program with the source and/or listing view options, when you issue the STRDBG command on that program, the source will appear. You can then set breakpoints prior to activating the program if you wish. Once the program is running you can view and change the values of variables, step through the source, etc. If you’ve used STRISDB in the past, you’ll find many of the same options available to you, such as the capability to add breakpoints, step through the code one line at a time, and display and change values of variables in the program. Sometimes the way you do these is different. For example, in the STRDBG debugger you can display the value of a variable with F11 as you might expect, but to change its value, you use the EVAL command on the debug command line. You can see a value in hex format by placing “:x” after the variable name on the EVAL command.

Another significant difference is that by default the STRISDB command automatically called the program for you and paused at the beginning for you to add breakpoints or step into the code. The STRDBG debugger shows you the source for adding breakpoints but you must still call the program manually, typically by using F21 to bring up a system command line.

The Step function is available using either F10 to step only within the code in a single program or procedure, or by using F22 (conveniently Shift F10) to step into code on a call to another program or procedure. This Step Into feature is one that’s escaped many experienced users of the ILE debugger, who mistakenly think they must first set breakpoints in any called programs or procedures.

Another part of the STRDBG debugger that many people haven’t noticed is the capability to redisplay the source view debug screen in case you left it for some reason and want to go back to set another breakpoint or do some stepping through the code. While your job is still in debug mode, you can issue the Display Module Source (DSPMODSRC) command to get back to the source view debug screen.

If you want to add a program or service program to the debug session, you may either simply step into the program or procedure by using F22, or add a program or service program from the Work With Module List screen. You can get to this screen via F14 on the source view debug screen. From there, you may also display the source for another module or program so you can set breakpoints in the code without needing to step into the code.

While you’re looking at the source view debug screen, you may switch to the listing view version of the program by using F15 to “Select View”, assuming you’ve compiled with DBGVIEW(*All).

 

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.


comments powered by Disqus
Buyers Guide

Advertisement

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App
IBMi News Sign Up Today! Past News Letters

Advertisement