3.1.1 Entering the Debugger

When the debugger is entered, 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 this 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" 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. In this case the meaning of the system's abort key is changed. When abort is typed, the program finishes execution of the current instruction and then 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. This method of starting the debugger does not work on all machines. (Under Windows, the "Enter Debugger" menu option accomplishes the same thing.)

If you have already entered the debugger initially, 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.