Using Breakpoints and Watchpoints

A breakpoint indicates a line of code or program at which you want the execution of an application to pause. When the application is paused, you can view and change the values of data items at that particular step.

Similarly, a watchpoint is a type of breakpoint that indicates an area of memory associated with a data item that you want to watch, pausing your application when that memory is updated. These types of breakpoint are set on a data item, as opposed to a particular line of code. This type of breakpoint is not supported for JVM COBOL applications.

You can add conditions to both types of breakpoints. A condition can be a coded expression - for example, for a conditional watchpoint set on my-variable, with an expression of my-variable > your-variable, would only break execution when the memory for my-variable was updated and the value of my-variable was greater than your-variable. A condition can also be a hit count - for example, for a conditional breakpoint on line 15 of a program, where hit count > 2 is set, execution will only break when an attempt is made to execute that line for the third time. If you are reverse debugging, the hit count still increments when you step backwards. You can also combine both types of condition, where both conditions must be true before execution will break.

The Breakpoints property view shows details of all bound breakpoints and watchpoints, and enables you to configure them.

You set breakpoints and watchpoints by:

The icon appears in the marker bar when a breakpoint is set, and the icon when a watchpoint is set. A tick mark is added to these icons when the breakpoint or watchpoint is bound to the program. A program breakpoint is indicated by the icon.

Note: Breakpoints in Eclipse are set in source files, not in programs (as they are in other Micro Focus products). This means that a single breakpoint may actually be encountered many times if the source file is used in multiple programs or used multiple times in the same program. For example:

Main.cbl:

Procedure division.
       Copy "Code.cpy".
       …
       Copy "Code.cpy".

Code.cpy:

       Add 1 to count		// set breakpoint here

When a breakpoint is set before debugging is started, or no program that uses the copybook is active, the breakpoint is pending. This means that it has not been resolved to a real code position. When debugging is started or a new program is called, the debugger attempts to resolve all pending breakpoints and bind them to actual code positions.

In the above example, when the main executable is loaded by the debugger it binds the single (pending) breakpoint to two actual (bound) breakpoints. The breakpoints are then shown with a plus sign added to the breakpoint icon , both in the margin of the editor and in the Breakpoints view.