Entering the Debugger

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.

Note: If you receive the following message when entering debug mode, it is indicating that the program has somehow started multiple OS threads, which is currently not supported. You must figure out how the multiple OS threads have been spawned, and prevent them before you can debug the program:

Multiple OS threads detected

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.