When a program is executed in debug mode, the debugging window pops up over the lower portion of the screen. Commands to the
debugger and their results are displayed in this window. You can control the size of the command window from within the debugger
by pulling down the Source menu and selecting Window Size.
If you are running the debugger under Windows, you can change the size of the entire debugger window. Point to a border or
corner, and when the mouse pointer changes into a double arrow, hold the mouse button down and drag the border or corner to
reach the size you want. Release the button when you are ready.
You can enter the debugger in several ways; the most common is to specify the
-d option to
runcbl. Here's a list of all the ways the debugger can be entered initially:
- When you specify the
-d option to
runcbl. This causes the program to start in the debugger. For example:
runcbl -d payroll
- Whenever a STOP statement executes that is not a STOP RUN. In this case, the argument to STOP is displayed in the debugging
window. This method functions even if
runcbl is not run in debugging mode. Note, however, that symbols and source will not be available in this case. To do source level
debugging, compile with the
-Gd or
-Ga option and run with the-d option.
- When the program has been started in debugging mode, and the abort key (such as
Ctrl + C) is pressed. On Windows systems, the same effect is achieved by selecting the
Enter Debugger menu option. In either case, when the command is received, the program finishes execution of the current instruction and
enters debugging mode. Note that if the current instruction is an ACCEPT statement, the program will not enter debugging mode
until the ACCEPT statement is satisfied by having something entered. Using the abort command to enter the debugger does not
work on all machines.
If you have already entered the debugger, you may reenter it in one of the following ways:
- When a breakpoint is reached. Breakpoints are set by the user through the debugger.
- When the program is being
stepped through by the debugger and the step count has been reached.
- When a variable that is being monitored changes. In this case an automatic breakpoint is generated at the beginning of the
next statement.
- When you've compiled with
-Za along with
-Gd, and an array violation occurs. In this case, you automatically break to the debugger and see the line on which the array
violation occurred.
Each of the situations described above causes the debugging window to pop up over the lower portion of the screen. If source-level
debugging is being used, then the upper half of the screen displays the source at the location currently being executed. When
the debugger exits, these windows are removed and the application screen is restored. The application screen is not restored,
however, until an ACCEPT or DISPLAY verb is executed. This allows you to debug a section of code without the distraction of
having the screen being constantly repainted.