Start with the shape, not the syntax
Opening a COBOL program for the first time can feel like reading a legal contract from another era. Thousands of lines, terse data names, and no comments worth trusting. The trick is to stop reading top to bottom. COBOL programs have a fixed shape, and once you know it, you can skip straight to the parts that matter.
Most of the business meaning in a program lives in a small share of its lines. The rest is declarations, file handling and housekeeping. Your job as a reader is to separate the two quickly. This walkthrough shows how, using the program's own structure as a map.
The four divisions and what each tells you
Every COBOL program is split into divisions, always in the same order. Each one answers a different question.
- IDENTIFICATION DIVISION names the program. It is short, and the author or date entries are often stale, so do not treat them as documentation.
- ENVIRONMENT DIVISION links the program to its files. Read the file-control entries to learn what the program reads and writes.
- DATA DIVISION describes every field the program touches. This is where you learn what PAYMENT-AMOUNT or ACCOUNT-STATUS actually is, how big it is, and how it is grouped into records.
- PROCEDURE DIVISION holds the logic. This is where the business rules live.
A good reading order is Environment, then Data, then Procedure. Knowing the inputs and the vocabulary first makes the logic far easier to follow.
Reading the procedure division by paragraph
COBOL has no functions in the modern sense. The Procedure Division is broken into named paragraphs and sections, and control moves between them with PERFORM statements. Start at the first paragraph, which is usually a small driver, and list the paragraphs it performs. That list is your table of contents.
Then read the paragraph names before you read any code. Names like VALIDATE-CUSTOMER or CALCULATE-NET-PAYMENT often tell you more than the comments do. Watch for GO TO statements, which jump control around and are a common source of surprises in older code.
Look for the lines where decisions happen: IF and EVALUATE blocks, and COMPUTE statements. A line such as NET = AMOUNT minus FEE is a business rule written in a few characters. Collect those as you go, with the field names involved, and you have the start of a rules inventory. If you are heading toward a migration, our guide on extracting business rules from COBOL code picks up from this point.
Copybooks: where the field definitions hide
Many field definitions are not in the program at all. A COPY statement pulls in a copybook, a shared file of record layouts that several programs use. If a field is used but never declared in the program, it almost certainly comes from a copybook.
Open the copybooks early. They tell you the record structure that flows between programs, and a change to one copybook can touch every program that copies it. That makes copybooks a natural place to start when you ask what else would be affected if a field changes. For that question, see our piece on change impact analysis for legacy code, and for following a single field through a system, data lineage in legacy systems.
Where AI-assisted analysis speeds up the reading
Everything above works, but it is slow on a real estate of many programs and shared copybooks. The slow parts are the mechanical ones: tracing a field across paragraphs and files, following PERFORM chains, and finding every program that copies a given layout.
This is where AI-assisted analysis helps. Replai reads existing code, including COBOL, and builds a structured map of the business rules, workflows and dependencies between components. Instead of hand-tracing a field, you can ask a plain-language question about it and follow the answer back to the source lines. The evidence stays linked to the code, so a person can still check the logic. Human judgment stays in the loop. The tool shortens the search, not the review.
For a plain-language look at how this works, read how AI agents read legacy code. For the broader practice of understanding code you did not write, see legacy code analysis.
Frequently asked questions
What is the best order for reading an unfamiliar COBOL program?
Read the Environment Division to see which files are used, then the Data Division to learn the fields, then the Procedure Division for the logic. Knowing the inputs and field names first makes the logic easier to follow.
What does a COPY statement do in COBOL?
A COPY statement pulls in a copybook, a shared file of record layouts used by several programs. If a field is used but not declared in the program, it usually comes from a copybook.
Where are the business rules in a COBOL program?
Mostly in the Procedure Division, in IF and EVALUATE blocks and COMPUTE statements. Paragraph names such as CALCULATE-NET-PAYMENT often point you to them quickly.
Why are COBOL paragraph names useful when reading code?
The Procedure Division is organized into named paragraphs that are called with PERFORM. Reading the names first gives you a table of contents for the program before you read any logic.
How can AI help with understanding COBOL code?
AI-assisted analysis can map business rules, workflows and dependencies across the code, so you can ask plain-language questions and trace answers back to the source lines. A person still reviews the logic.