Now that you know how to start a debug session, let’s see how to set and use breakpoints. This is one area where the “new” ILE debugger is way better than the “old” STRDBG.

Finding and squashing application bugs can be frustrating and time-consuming. Often, a critical situation exists, and you’re under pressure to resolve the issue quickly and accurately. Familiarity with the navigational debug commands, explained in the previous TechTip, will help a lot during your debugging sessions. Naturally, simply moving through the source isn’t enough. You’ll also need to be familiar with the actual debugging commands. This entails, among other things, adding and removing breakpoints.

This and the next TechTips will explore the actual debug process, starting with the breakpoints. Before we start, there are a few things you should know about breakpoints:

• When a breakpoint is set on a statement, the breakpoint occurs before that statement is processed—i.e., the control is passed back to you before the line of code is executed.
• When a statement with a conditional breakpoint is reached, the conditional expression associated with the breakpoint is evaluated before the statement is processed. If the expression is true, the breakpoint takes effect and the program stops on that line.
• If the line on which you want to set a breakpoint is not a runnable statement (a comment line, a variable definition, etc.), the breakpoint will be set on the next executable statement. For example, if you try to add a breakpoint in a comment line, the debugger will move the breakpoint to the next executable line of code.

Setting a breakpoint is achieved by finding the appropriate line in the source code on the Display Module screen, placing the cursor in that line, and pressing F6. You can also use the BREAK debug command (discussed in more detail later in this subseries) and indicate the line number. A third option is pressing F13 to display the Work with Module Breakpoints screen and then using option 1 to add a breakpoint, specifying only the line number. Any of these courses of action will create an unconditional breakpoint in that line. However, in some situations, this is not the best solution. For instance, when you want to follow what the program does when a variable within a loop reaches a certain value, it might not be practical to manually advance the execution of the code line by line until the right conditions are met.

Imagine that you’d need 1,000 loops until your variable had the value you’re expecting. It wouldn’t make much sense to manually step through the loop 1,000 times, right? Because of this, there’s a way to create a conditional breakpoint. Simply type the following:

BREAK <line number> WHEN <condition>

The condition can be any simple expression, such as W_Item_ID = ‘12345678’ or I_SflClr = ‘1’. Unfortunately, a simple expression excludes the use of the AND and OR operators, which means that composed conditions like this are not possible:

W_Item_ID = ‘12345678’ AND W_Part_Number = 90877474

One workaround is to add two conditional breakpoints in adjacent lines, one with each of the conditions you want to use. As I said before, you can also use F13 to display the Work with Module Breakpoints screen. There, you can specify your simple condition, as shown in Figure 1.

Figure 1: Adding a breakpoint via the Work with Module Breakpoints screen

It’s possible to change the condition of a conditional breakpoint. Simply type this followed by Enter, and you’re done:

BREAK <line number> WHEN <new condition>

You can also turn a conditional breakpoint into an unconditional one by typing this:

BREAK <line number>

To perform the reverse operation, type this:

BREAK <line number> WHEN <condition>

When it comes to removing breakpoints, you have several options:

• You can use the aforementioned Work with Module Breakpoints screen, in which you can use option 4 in the line corresponding to the breakpoint you want to remove.
• You can place the cursor in the line with the breakpoint and press F6.
• You can type CLEAR <line number> followed by Enter, and the breakpoint at <line number> will be removed.

Finally, there’s a “big red button” solution to nuke all the breakpoints of your debug session: type CLEAR PGM and press Enter. All the breakpoints will be removed.

Want to Know More?

Breakpoints, particularly conditional ones, are very useful when you know what you’re looking for. However, in many situations, the code’s complexity and/or length makes it almost impossible to find the right place to put the breakpoint. For these situations, there’s another useful concept: the watch condition. Unfortunately, I’m running out of space, so you’ll have to wait until the next TechTip to learn about this great tool. Meanwhile, feel free to comment, criticize, or simply share your own knowledge In the Comments sections below.