RPG Academy: Debug Done Right - A Step-by-Step Debug Session, Part 2

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Let's continue our debug session where we left off and learn a few more debug tips and tricks!

Written by Rafael Victoria-Pereira

In order to get the most out of this TechTip, you'll need to read or re-read Part 1 of this TechTip and follow the instructions it contains, because this one will continue exactly where the last one ended.

After pressing F12 and getting back to the command line (yup, that's the last instruction of the previous TechTip) and assuming you didn't issue an ENDDBG command, you can still see the Display Module screen again. Simply type DSPMODSRC. The Display Module Source command does exactly what its name suggests. It's a good way to see if you're still in debug mode, because it works only in that mode. If you run this command and get a "command not allowed"-like error message, you know that your debug was terminated. I know quite a few programmers who didn't know that this command existed and were used to terminating the debug session and starting a new one, losing all their breakpoints and watches, just to get to the Display Module screen!

Let's execute TST_DTEOPS again and see what happens. The execution stopped before reaching the first line of code! Why? Well, because there's a watch on W_DayNbr, and the variable is initialized in the definition line. In other words, the variable's contents changed since the last time the watch was triggered, so the initialization process caused by the INZ keyword in the variable definition triggered the watch, which forced execution to stop.

Press F10 to advance a few steps, until the first line of code - the one that assigns '2014-11-16' to W_Date - is executed; press F10 again to run that statement. Now place the cursor over W_Date and press F23. The debugger will prompt you for the new value for W_Date; type today's date and press Enter. Alternatively, you can type Eval W_Date = '<today's date>' and press Enter. Note that because of the W_Date definition, you must enclose the date in apostrophes, like the assignment statement in line 18 and the conditional breakpoint in Figure 3 of the previous TechTip.

Press F12 to resume execution. You'll see that, of the two breakpoints that you defined in lines 21 and 24, only the latter is triggered. No, there's nothing wrong with the debugger - just like the watch, both breakpoints are still active. So, what's going on? Remember that the breakpoint in line 21 is conditional. It will be triggered only if W_Date is equal to '2014-11-16'. You changed that variable's content to the current date, so when the debugger evaluated the condition associated with the breakpoint and determined that it was false, it decided the breakpoint shouldn't be triggered.

Feel free to play around a bit with the debugger, exploring the function keys available in the Display Module screen, as I didn't cover all of them. When you're done, return to the command line and type ENDDBG, followed by Enter. This will end your debug session, freeing up the resources allocated to the ILE debugger. Table 1 summarizes the new debug commands mentioned In this and the previous TechTip.

A Debug Commands Summary

Command

Abbreviation

What It Does

BREAK <line number>

BR <line number>

Inserts/removes an unconditional breakpoint in line <line number>.

BREAK <line number> WHEN <condition>

BR <line number> WHEN <condition>

Inserts a conditional breakpoint in line <line number> that will be triggered only when the condition is satisfied.

EVAL <variable name>

EV <variable name>

Displays the content of the <variable name> variable. Positioning the cursor over the variable and pressing F11 does the same thing.

EVAL <variable name> = <new value>

EV <variable name> = <new value>

Assigns the value <new value> to the <variable name> variable. Positioning the cursor over the variable, pressing F23, typing the new value, and pressing Enter does the same thing.

STEP <number of statements>

ST <number of statements>

Allows you to run one or more statements of the source code being debugged. Pressing F10 <number of statements> times does the same thing.

STEP <number of statements> INTO

ST <number of statements> INT

Allows you to run one or more statements of the source code being debugged and drills down into the procedure, function, or program being executed, if possible. Pressing F20 accomplishes the same thing. The object to debug must have been compiled with debug view for this to work.

 

The "Debug Done Right" subseries has thus far provided you with the tools and knowledge to perform more efficient and pleasant (if debugging can ever be pleasant) debug sessions. However, the ILE debugger, just like the Interactive Source Debugger, has its quirks and can be hard to master. Don't be discouraged by your initial attempts. After a few tries, you'll get the hang of it and you'll never want to go back!

The remainder of this subseries will move to other interesting uses of the ILE debugger, such as debugging service programs, OPM and CL programs, and even batch jobs! Stay tuned for the next TechTips of this RPG Academy subseries.

BLOG COMMENTS POWERED BY DISQUS