Changing Code Without Breaking It

When you encounter legacy code that has been running untouched for decades, the prospect of changing it can be terrifying. Many legacy programs rely on complex, unstructured GO TO loops and overlapping memory spaces (REDEFINES). Modifying such code without a safety net often introduces subtle bugs that are difficult to trace.

Refactoring is the process of changing the internal structure of code without altering its external behavior. In COBOL, this means transforming “spaghetti code” into structured, readable logic. However, you should never attempt this without regression testing.

The Regression Test Harness

A test harness isolates the behavior of a program segment so it can be verified independently. This baseline is your safety net. You run the original code, capture its outputs and side-effects, and assert that the new code produces identically the same results.

Below is an example of an unmodified legacy program wrapped in a simple test harness:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TestHarness.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  TEST-VAL PIC 9 VALUE 1.
       PROCEDURE DIVISION.
           PERFORM RUN-TEST.
           STOP RUN.
       RUN-TEST.
           DISPLAY "BEFORE: " TEST-VAL.
           PERFORM LEGACY-CODE.
           DISPLAY "AFTER: " TEST-VAL.
       LEGACY-CODE.
           ADD 5 TO TEST-VAL.

BEFORE: 1
AFTER: 6

Small Incremental Steps

Refactoring should be performed in small, verifiable steps. After every minor change, you rerun your test harness. If the output diverges, you immediately know which step broke the logic.

Here is the same test harness, but the LEGACY-CODE has been refactored into NEW-CODE:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. RefactoredHarness.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  TEST-VAL PIC 9 VALUE 1.
       01  ADD-AMOUNT PIC 9 VALUE 5.
       PROCEDURE DIVISION.
           PERFORM RUN-TEST.
           STOP RUN.
       RUN-TEST.
           DISPLAY "BEFORE: " TEST-VAL.
           PERFORM NEW-CODE.
           DISPLAY "AFTER: " TEST-VAL.
       NEW-CODE.
           ADD ADD-AMOUNT TO TEST-VAL.

BEFORE: 1
AFTER: 6

Notice that the output remains precisely the same. Behavior preservation means the outputs of the old and new logic are identical for all inputs. Refactoring changes how the program is written without changing what it does.

Untangling GO TO Logic

One of the most common refactoring tasks in COBOL is removing GO TO statements in favor of structured PERFORM or IF/ELSE blocks.

Consider this unstructured snippet:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. Before.
       PROCEDURE DIVISION.
       P1.
           GO TO P2.
       P2.
           DISPLAY "X".
           STOP RUN.

X

It can be safely refactored to:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. After.
       PROCEDURE DIVISION.
       P1.
           PERFORM P2.
           STOP RUN.
       P2.
           DISPLAY "X".

X

The exact behavior is maintained, but the flow of control is now predictable and structured.

Visualizing the Flow

Predict the Output

Before proceeding, let’s verify you understand the behavior of the refactored complex logic.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. ComplexR.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  VAL PIC 9 VALUE 1.
       PROCEDURE DIVISION.
       P1.
           ADD 1 TO VAL.
           GO TO P3.
       P2.
           ADD 2 TO VAL.
       P3.
           ADD 3 TO VAL.
           DISPLAY VAL.
           STOP RUN.

5

• 7
• 5
• 4

The program skips P2 because of the GO TO P3 statement. So VAL becomes 1 + 1 + 3 = 5.