Watch Your Data While Stepping Out With RDi Debug

In this latest in my series of tips on using the RDi debugger, I’ll talk about one of my favorite debug features–the Monitors view–and we’ll explore not just one or two, but four different options for stepping through program code a statement at a time.

Stepping Out

Just like with the green screen debugger, you can step through code a statement at a time. Figure 1 shows the various debug tool bar icons with those related to stepping through your code highlighted. The most commonly used options are the two arrows in the middle: “Step Into (F5)” and “Step Over (F6)”. Just as with STRDBG (where Step Into is F22 and Step Over is F10), the only difference between those two types of step is whether you want to debug a called program or procedure (step into) vs. run the code and then step to the next statement following the call statement in the current program (step over).

Figure 1.

Unlike STRDBG, RDi also has “Step return (F7)” option, which is shown by the rightmost of the highlighted arrow icon in Figure 1. This helps when you have stepped into a program or procedure and you then decide that you don’t really want to continue stepping through that routine. It runs the rest of the logic and then stops on the next statement after the call back in the calling code. It doesn’t work when the called program was not created with an ILE compiler, so in that case, you’ll likely need to go back into the source for the calling program and add a breakpoint right after the call statement and then press Resume (F8).

Another RDi step option that can be helpful–or at the very least mildly entertaining–is “Animated Step Into,” which is shown by the leftmost of the highlighted step icons. That causes the debugger to effectively press the “step into” button for you repeatedly so you can follow the logic of a program without wearing out your keyboard. You may speed up or slow down the animation from the menu arrow next to the icon. Pressing the icon again stops the animation whenever you want. I’ve found this option surprisingly useful when trying to get a feel for the way that the logic flows within a routine.

Watching Your Data

While you’re stopped on a statement in debug, you can look at the current value of any variable by hovering over its name with your mouse. If you want to continually monitor the value of one or more variables while you’re stepping through your code or when stopped at breakpoints, add those variables to your Monitors list. The old ISDB debugger for non-ILE code had a similar feature but it wasn’t as flexible and took space away from the debug source view. To use the RDi monitor feature, double click on a variable name in the source to select it, then right click and select “Monitor Expression.” RDi puts the variable name and its current value in the Monitors view (shown in Figure 2.), which is in the upper right corner of the debug perspective, along with the Breakpoints view. You’ll notice as you continue to step through your code, that when the value of a variable being monitored changes, the color turns red to highlight recent changes. You can see this in effect in Figure 2.

Figure 2.

You don’t need to find the variable in the code to monitor it, you may also add one from the Monitors view itself. Right click and select “Monitor Expression. . .” or click the plus sign in the Monitors view toolbar. A dialog box opens where you can key in the variable name. You aren’t limited to simple variables. You can also monitor data structures or arrays. The values can be seen by expanding the DS or array name in the Monitors view. If you prefer to monitor a specific array element, of course you can also do that. I find it handy to monitor for some (or all) of the *IN array from time to time.

To change the value of a variable, double click on its value in the Monitors view. That opens up an input box where you can key in the value you want.

Sometimes it’s helpful to view a value in hex. To do that simply right-click on the value in the Monitors view and choose the Change Representation option. If your variable value is large, you can use the slider in the display area at the bottom of the monitors view to scroll though the data. However, that technique only works for up to 1024 bytes, the maximum size supported in the Monitors view. If you need to see more than that, you’ll need to use the Monitor Memory option instead.

After selecting the variable in the source, right click and choose “Monitor Memory.” By default the Memory view appears in the area underneath your source code. The Monitor Memory option is far less user friendly. It is tough to figure out where your variable begins and ends because the values you see aren’t delimited by the boundaries of your defined variable. For my large character variable, I used the EBCDIC representation. I found it a little easier to view the values when I re-formatted the value display. You can do that by selecting “Format. . .” from the context menu in the memory display area and trying different combinations of row and column size. In Figure 3, you can see an example of the Memory view for my VeryBigVar, which was formatted to a row size of 64 and a column size of 16.

Figure 3.

Why Monitor Values At All?

In RDi, you also have the Variables view, which lists the value of every variable in the code currently being debugged. Why not just use that instead of monitoring individual variables? For programs or procedures that are very small and consequently have few variables, using the variables view works well. But when debugging large programs, finding the variable value you need in the Variables view is cumbersome. More importantly, asking RDi to constantly refresh all those values in the Variables view on every step or breakpoint can slow down debugging to a crawl. So for most programs, you’re probably better off leaving the Variables view in the background and bringing the Monitors view (or Breakpoints or any other view in that section of the debug perspective) into the foreground. If you rarely debug small programs and procedures, you could even close the Variables view to avoid potential performance issues with it.

There is one occasion where the Variables view can be very useful. That’s when it is used in combination with the call stack shown in the Debug view, as seen in the upper left corner of Figure 2 to the left of the highlighted Monitors view box. The program I’m currently debugging (DBGRPGIV) calls some other procedures and programs, you can see calls to FillArray and DbgSubproc in the source showing in Figure 2. If I step into DbgSubproc on one of those calls, the Debug view will then show both DBGSUBPROC and DBGRPGIV in the call stack. If I want to look back at the value of some variable in DBGRPGIV while I’m in DBGSUBPROC, I can simply click on DBGRPGIV in the call stack and then look at the Variables view to the right of it. I can look back the value of variables of any earlier programs or procedures being debugged that are currently in the call stack by using the Debug view to choose which set of values I want to see in the Variables view.

In this series of tips, I’ve talked about different ways to start a debug session with RDi, various things you can do with breakpoints when debugging, and now stepping through your code and looking at or changing variable values in a debug session. If there are other things about using the RDi debugger that you want to hear about, let me know. Until then, may all your bugs be easy to fix.

Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.

RELATED STORIES

RDi Debug Without SEPs

When You Reach Your Break(ing) Point. . . Or Not