Reading a Program You Did Not Write

When maintaining COBOL applications, you will spend far more time reading code than writing it. Many systems you encounter will have been written decades ago, relying on unstructured programming techniques that modern languages typically avoid.

This lesson is your guide to code archaeology. We will explore how control flows in legacy applications and how to trace execution through unstructured logic like GO TO, ALTER, and paragraph fall-throughs.

Tracing a One-Way Jump

The first thing that defeats a modern reader is that control does not come back. PERFORM returns to its caller, so you can read a paragraph, note “this calls that”, and carry on. GO TO is a one-way jump: control leaves and never returns, so the paragraph you are reading has no ending you can rely on.

That changes how you read. You cannot scan a program top to bottom and assume the order on the page is the order of execution. You have to trace — pick an entry point, follow each jump, and keep your own note of where control actually went.

(The next lesson covers GO TO, GO TO DEPENDING ON and their structured replacements properly. Here we only need enough to follow the flow.)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. GotoUncond.
       PROCEDURE DIVISION.
           DISPLAY "START".
           GO TO END-PARA.
           DISPLAY "SKIPPED".
       END-PARA.
           DISPLAY "END".
           STOP RUN.

START
END

Because GO TO does not return, following the logic of a program heavily reliant on it requires tracing every jump manually.

When the Code You Read Is Not the Code That Runs

Everything above assumes the jump goes where the source says it goes. ALTER breaks that assumption: it rewrites the target of a GO TO at run time, from somewhere else entirely.

This is the single most important thing to know when reading old COBOL, because it defeats reading. You can study a paragraph, understand it completely, and still be wrong about where it goes — the answer is in a different paragraph that ran earlier. When tracing unfamiliar code, search the whole program for ALTER before you trust any GO TO you have read.

       ID DIVISION. PROGRAM-ID. A.
       PROCEDURE DIVISION.
       P-1.
           DISPLAY "1".
           ALTER P-3 TO PROCEED TO P-4.
           GO TO P-3.
       P-2.
           DISPLAY "2". STOP RUN.
       P-3.
           GO TO P-2.
       P-4.
           DISPLAY "4". STOP RUN.

1
4

In the example above, if you only looked at PARA-C, you would assume it jumps to PARA-B. However, PARA-A silently rewires it to jump to PARA-E instead!

Fall-through and Dead Code

Another common source of confusion in legacy COBOL is paragraph execution. Paragraphs do not inherently isolate code like functions do in modern languages. Unless you explicitly transfer control (using GO TO, PERFORM, or STOP RUN), execution “falls through” from the end of one paragraph straight into the beginning of the next.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. Fallthrough.
       PROCEDURE DIVISION.
       START-PARA.
           DISPLAY "START".
       NEXT-PARA.
           DISPLAY "NEXT".
           STOP RUN.

START
NEXT

Because execution can jump unpredictably and fall through without warning, many legacy programs contain dead code—paragraphs that are completely unreachable. Unreachable paragraphs remain in the program, clutter the logic, and must be manually refactored.

Refactoring with PERFORM

Modern COBOL replaces GO TO and ALTER with the PERFORM statement. The PERFORM statement transfers control explicitly to one or more procedures and implicitly returns control to the next executable statement. This keeps your code structured and predictable.

If you must execute a sequence of paragraphs, you can use PERFORM THRU.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PerformThru.
       PROCEDURE DIVISION.
           PERFORM PARA-1 THRU PARA-3.
           DISPLAY "MAIN-END".
           STOP RUN.
       PARA-1.
           DISPLAY "1".
       PARA-2.
           DISPLAY "2".
       PARA-3.
           DISPLAY "3".
       PARA-4.
           DISPLAY "4".

1
2
3
MAIN-END

The exercises for this lesson challenge you to find dead code and refactor spaghetti code using PERFORM. Good luck with your archaeology!