Debugging COBOL code
So you've written your program, finally got it to compile
after sorting out all those syntax errors and undefined variables and the rest.
A D V E R T I S E M E N T
So you execute the program and Hey Presto! ... nothing happens, you get a
runtime error, or worst of all, your computer locks up and you're reaching for
CTRL+ALT+DEL. So what went wrong?
Don't worry. The next thing to do after writing your
wonderfully crafted program is to fix all the bugs, that is, all the errors in
the code that lie hidden in the logic beyond the reach of the compiler. Here are
a few personal hints and tips of mine to set about debugging your program (and
avoiding errors in the first place), or at least how I go about getting my code
to do what I want it to do.
- Before a line of code is written...preparation
- Commenting
- Variable names
- Break it up
- "Stubs"
- Watching variables
- Debugging tools
(i) Before a line of code is
written...preparation
The best way to avoid spending hours trying to untangle a
mass of complex code (that you brilliantly typed into the computer straight from
the top of your head) is PREPARATION. By that I mean: (1) be absolutely clear
about what you want the program to do - know what the inputs and outputs are,
(2) write a very broad algorithm and gradually refine as far as you can using
pseudo-code, (3) draw a flow chart or structure chart that matches the
pseudo-code, and (4) translate the flow chart into actual COBOL.
One issue is: Do I write the PROCEDURE DIVISION first and
then go back and write the DATA DIVISION? This would seem a fairly sensible
thing to do except that in practise you find you will forget to declare a whole
slew of variables. A further point is that a good deal of COBOL involves doing
things to the data that rely on what's been declared in the DATA DIVISION.
Again, I would suggest preparing a fair proportion of the data definitions on
paper first. When I write a program I write as much DATA DIVISION as possible
before starting on the PROCEDURE DIVISION. Then, as I proceed through the code I
keep going back to the DATA DIVISION to update it as soon as possible.
(ii) Commenting
Liberally sprinkle you code with comments
that explain exactly what each fragment of code is meant to do. This really
helps when trying figure out what's going on.
(iii) Variable names
Use variable names that are meaningful and
stick to a standard format. For example, some people use a prefix before
variable names to indicated the general function of the variable, such as
printing variables:
01 PRINT-OUTPUT.
03 P-NAME PIC X(20).
03 P-ADDRESS PIC X(50).
03 P-CUS-CODE PIC 9(6).
03 P-PAGE-COUNT PIC 999.
|
This example uses "P-" before each name to indicate a member of the print output
group. Sometimes the prefix "WS-" is used to indicate WORKING-STORAGE, "L-" for
LINKAGE SECTION variables. Notice that the names are also meaningful. While you
may spend longer typing out longer names you'll thank youself when it comes to
fixing bugs. Care should be taken when deciding names that you spell
them correctly (PAGE-COUNTRE) and/or consistantly (RECORD-NUM and RECORD-NO) and
that you don't try to use singular and plural names (CUSTOMER-TOTAL and
CUSTOMER-TOTALS).
(iv) Break it up
Breaking your code into smaller procedures (i.e.
paragraphs) not only makes the program easier to read, but easier spot where
problems are arising.
(v) "Stubs"
One way to monitor what is going on when you run your
program is to place "stubs" at important points in the logic. By stubs I mean a
DISPLAY statement that tells you the that certain position in the logic has been
executed:
MAIN-PARAGRAPH.
DISPLAY 'IN MAIN PARAGRAPH'
PERFORM INIT-PARAGRAPH.
PERFORM RECORD-READ-PARAGRAPH
UNTIL NO-MORE-RECORDS
PEFORM TERMINATE-RUN
DISPLAY 'PROGRAM ENDING'
STOP RUN.
|
If you have a DISPLAY at the beginning of each paragraph then the console window
might look something like this:
IN MAIN PARAGRAPH
IN INIT-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN RECORD-READ-PARAGRAPH
IN TERMINATE-PARAGRAPH
PROGRAM ENDING
You must remember to remove all of the stubs when the program is fully debugged.
(vi) Watching variables
Of course, just putting little flags say "IN PARAGRAPH XYZ" can be extended
further to display the value of certain important variables:
DISPLAY "P-COUNTER = " P-COUNTER
Again, don't forget to remove them (or comment them out) when your done.
(vii) Debugging tools
Both the Fujitsu COBOL85 and Microfocus Personal COBOL compilers (and presumably
other too) have debugging utilities. Most significant are the ability to
animate the program and set breakpoints throughout your code.
Animating your code allows you to view each line of code as the debugger steps
through the program. You can pause the run at any point and check the value of
variables. During this process you can specify variables that you want to watch
throughout the run. Animating a program run can prove a bit tedious if large
amounts of iterations are involved.
An alternative is to set breakpoints. By doing so the
program run will pause at defined breakpoints (wherever you want them) to allow
you to check the value of variables.
You should check your compiler documentation to find out
how to use debugging utilites: for large programs they are well worth the
effort.
* * *When it comes to actually fixing errors try to avoid
"hacks", that is, adding bits of code to correct erroneous data values rather
than trying to find out why the data was wrong in the first place. You may find
yourself getting bound up in ever more complex arrays of Boolean flags to allow
certain conditions: e.g.
IF (X = Y) AND (Z >= W) AND ((A = B) OR (A <> C)) AND (D < F) THEN...scream..?
This being the case, see if your logic couldn't be better designed. Sometimes
going back to the drawing board (more than once) is the best strategy in the
long run. Like a famous chess grandmaster once said (I don't know who) "If you
see a good move, look for a better one" : if you think of a good way of coding
something, look for a better alternative (not as snappy ?!). Something to keep in mind at all times is that one day
someone other than yourself may have to read and understand (and perhaps modify)
your code. Whether this is true or not it is a good habit to get into because it
makes you write better code. And, as a software professional, this will almost
certainly be the case.
|
