Today you'll learn about symbolic debugging. You should be familiar with using a debugger, because it's an indispensable tool. Today's lesson shows you the main activities for which a symbolic debugger may be used.

Today you will learn

• What a symbolic debugger is
  
  
• How to prepare a program for symbolic debugging
  
  
• How to start and run a symbolic debugger

The Symbolic Debugger

The symbolic debugger is probably the single most powerful tool that you will ever use to understand a program. Unfortunately, there is no such thing as a standard debugger. However, certain common features of a debugger can be discussed.

New Term: A symbolic debugger lets you execute a program in small increments (usually a line at a time) and watch the code as it's being executed. A symbolic debugger also lets you display the values of variables using the variable name. It is called a symbolic debugger because it lets you display the variables using the symbolic name that the variable was given in the original source-code program.

Learning to use a debugger requires a complete course in itself, but knowing even the fundamentals makes your programming life easier.

It's not easy to create a lesson on this subject, because debuggers vary, but an example using the Micro Focus Personal COBOL debugger will give you an idea of how powerful debuggers are. You must read your debugger's manual and practice with it to learn how to use it. The steps shown here are fairly common to all debuggers. Examples for different machines are given. If you're using Micro Focus Personal COBOL, follow along with these steps.

Preparing for Debugging

The first step in debugging is often to compile the program for debugging. In these examples, you will compile and run wrdsrt01.cbl from Day 4, "Decision Making." This simple program illustrates the debugger's power. Adding debugging information to a compiled program usually increases the size of the program and slows down the compiler. It also slows down the program itself when it runs. Most versions of COBOL require that the program be compiled in a special way to allow for debugging:

• Micro Focus Personal COBOL has no special requirements. The Micro Focus Personal COBOL compiler is set up to automatically compile with debugging.
  
  
• Press F2 until Check is displayed, and then press Enter. The program will be compiled with debugging information included. Unless you have deleted the earlier compiled version of wrdsrt01.cbl, you don't need to follow this step, but it doesn't hurt to do it anyway.
  
  
• For ACUCOBOL, add -Zd to the command line:

ccbl -Zd -owrdsrt01 wrdsrt01.cbl

• For VAX COBOL, add /DEBUG=ALL to the compile command line and /DEBUG to the link command line:

COBOL/DEBUG=ALL WRDSRT01.COB
LINK/DEBUG/EXE=WRDSRT01 WRDSRT01.OBJ

Starting the Debugger

Some versions of COBOL require that a program be run in a special way in order to be debugged:

• For Micro Focus Personal COBOL, you must run the program through the debugger, called the Animator. If you have just loaded and compiled, you have already loaded the program into the editor. Otherwise, start by loading it into the editor:

PCOBOL WRDSRT01

• Press F2 until Animate is displayed, and then press Enter.
  
  
• For ACUCOBOL, add -d to the command line:

runcbl -d wrdsrt01

• For VAX COBOL, a program compiled and linked with debug information will start automatically in debug mode:

RUN WRDSRT01.EXE

Running the Debugger

You already have seen considerable differences between compiling for debugging and starting the debugger. Once the debugger is running, the differences in the behavior of debuggers are too complex to cover here. The following steps show a series of common debugging actions using the Animator debugger in Micro Focus Personal COBOL.

When the debugger first comes up, the screen displays a portion of the code on rows 1 through 21. Rows 22, 23, and 24 contain a menu of various commands you can give to the debugger. The next line of code to be executed is highlighted on the display, as shown in Figure B4.1.

Figure B4.1.
The first screen from the debugger.

Pressing S causes a single step of the program (the next line) to be executed. The line to be executed is PERFORM INITIALIZE-PROGRAM.

After this line is executed, the highlight moves to line 27, the first line of INITIALIZE-PROGRAM. The highlight indicates that the next line of code to be executed is MOVE " " TO WORD-1.

Press S again to step to the next line of code. Line 27 is executed, and the highlight is now ready to execute line 28.

Pressing S again steps through line 28, completing the INITIALIZE-PROGRAM paragraph. The highlight is now set to line 18.

Press S four more times, and you step one line at a time until the highlight is set to line 35. The 21 rows at the top of the screen might shift around while you're doing this to display different sets of lines.

Pressing S one more time moves the highlight to line 36 and displays a new group of 21 lines, including line 36. Line 36 is ready to be executed.

Pressing S at this point causes the display to shift to the screen as the user would see it. The debugger is executing an ACCEPT verb and needs input from the keyboard. Type the word beta and press Enter. The screen should look like this:

OUTPUT:

* Accepted - CONFIRM
This program will accept 2 words,
and then display them
in ASCII order.
Please enter the first word.
beta

The debugger returns to the debug screen, ready to execute line 38.

Press S once more to advance the highlight to line 39, ready to accept WORD-2.

Pressing S one more time displays a user screen again into which you should type the word alpha. The screen should look like this:

OUTPUT:

* Accepted - CONFIRM
This program will accept 2 words,
and then display them
in ASCII order.
Please enter the first word.
beta
Please enter the second word.
alpha

The debug screen returns, having completed the ENTER-THE-WORDS paragraph, ready to execute line 19.

Using the Debugger to View Variables

Now you should examine the values in WORD-1 and WORD-2. Press Q to start a query. Row 24 changes to allow various new options.

Press E to enter a name. Row 24 again changes, and a blinking cursor appears in row 25. You can now type the variable name. Type word-1 and press Enter.

As shown in Figure B4.2, row 25 now displays the value beta, the value that you entered for word-1.

Figure B4.2.
Displaying the value of a variable.

The ability to enter a variable name and display the contents of the value is what gives a symbolic debugger its power. Prior to the advent of symbolic debuggers, the programmer had to know where each of the program's variables were in memory. Then a request was made to display the values at the memory address. This made debugging very tedious and error-prone.

Press Esc, Q, E to enter a new variable, and then change word-1 to word-2 and press Enter. The value in word-2, alpha, is displayed on row 25.

While this has been going on, the highlight bar has been waiting patiently at line 19, ready for the next step command. Press Esc, and then press S to continue stepping through the program. This lets you examine how the IF logic in lines 45 through 51 is processed. Continue to press S until the highlight is on STOP RUN. Press S one more time, and a final message is displayed on row 25, concluding the program. Leave the program sitting at this point in the debugger because you will continue working with this program in the next section.

You can see that the debugger makes it possible to examine in detail what's going on in a program. You can step through the action one line at a time and examine the values in variables at any point. This is a very useful tool to find out what a program is doing, and especially to find out why a program is doing something wrong.

Stopping the Program at a Specific Line

Before leaving the debugger, you should examine one more feature, called a breakpoint.

In a large program, it would be tedious to step through all the lines of code one by one to get to the area of code where you know your program is having trouble.

This example illustrates how to use a breakpoint to get to a section of a program quickly. Restart the program by pressing R, S to reset and start the program. This sets the highlight back to line 17.

Press the down arrow twice. This moves the cursor (not the highlight) down two lines to line 19. Press B to set a breakpoint and S to set it at the current cursor position. Figure B4.3 shows the debugger screen after B is pressed.

Figure B4.3.
The debugger is ready to set a breakpoint.

When the breakpoint is set, press Z to zoom. This starts the program running as if it were not in the debugger. The debugger screen clears, and you're asked for the two words, just as you would be in the usual running:

OUTPUT:

This program will accept 2 words,
and then display them
in ASCII order.
Please enter the first word.
dog
Please enter the second word.
cat

Enter any value for both fields, and the program will continue running as usual.

This usual running continues until the line with the breakpoint is encountered--line 19. The program reverts to debugging mode, and the debug screen is displayed with line 19 highlighted as the next line to be executed. Row 25 displays the message Breakpoint encountered.

From this point you may examine variables, single-step through the program, or set another breakpoint further on in the program and zoom to it.

Summary

Symbolic debuggers improve debugging capability. There is no such thing as a "standard" symbolic debugger, because debuggers vary from one software vendor to another, but they all have common commands that can be used to examine a program. Today you learned these basics:

• Programs usually must be compiled in a special way to so that they can be executed by a symbolic debugger.
  
  
• A symbolic debugger loads a program and then waits for the user to press a key to start the program.
  
  
• When a program is running, it can usually be stopped.
  
  
• A symbolic debugger lets you inspect the value of a variable in the program.
  
  
• A symbolic debugger lets you set a breakpoint at a line of code. The program will run normally until that line of code is about to be executed, and then the program will stop in the debugger window and wait for commands from the user.

Q&A

Q If a breakpoint is set on a line, does the debugger stop the program before or after the line is executed?

A Every debugger I have ever worked with (about 40 different ones) stops the program before the line is executed. I would be very surprised to have it break after, but I suppose this is possible.

Q How can I learn a different symbolic debugger?

A Ask for the manual. Although COBOL is a fairly standard language, the tools used to develop and test COBOL programs are not. It's not uncommon to have to read the manuals to learn a linker, an editor, and a debugger.

Workshop

Quiz

1. The following code is a fragment of a program being run in the debugger. Assuming the normal breakpoint behavior of breaking before, what value would be displayed in A-NUMBER if the program broke at line 018500? At line 018600?

008300 01  A-NUMBER            PIC 999.
. . . . . .
018400     COMPUTE A-NUMBER = 110 / 11.
018500     COMPUTE A-NUMBER =  110 / 10.
018600     DISPLAY A-NUMBER.

Exercises

1. Find a program that you don't understand perfectly and compile it for debugging. Load it into the debugger and step through it using the debugger until you understand what the program does.

2. If you're working on a different computer system, locate the manual for your debugger and find out how to prepare a program for debugging, start the debugger, examine the contents of a variable, and set a breakpoint. Practice with the debugger if you can get permission.

---

© Copyright, Macmillan Computer Publishing. All rights reserved.