COBOL Basics for Lineage Research

This page is for business analysts and architects who know relational data well (tables, columns, keys, batch schedules) but rarely read COBOL source. It explains the ideas you will see in Zengines Data Lineage—not how to write programs.

If you have been a DBA or data modeler, think of COBOL as the layer that moves and transforms data between Db2 tables and files, under control of batch jobs defined in job languages such as JCL on z/OS (and CL / CLLE on IBM i for AS/400-style applications).

Program and module

In mainframe shops, a program is a compiled unit of COBOL logic. In Zengines, that program is a module on the Modules tab.

When documentation or AI text says “the retail posting program,” look for that name as a module and open its detail view for table, file, and variable relationships.

Tables and fields (what you already know)

Tables and fields in Zengines are SQL database objects—columns on Db2-style tables, same mental model as elsewhere:

• Tables tab — Who touches this table? How many modules use it?
• Fields tab — Which programs read or update this column?

Embedded SQL in COBOL (SELECT, INSERT, UPDATE, cursors) is how programs talk to the database. Zengines parses that SQL and links it to modules and variables.

Variables (COBOL working data)

COBOL does not work on “rows” inside the program the way SQL does. It works on variables—named areas in memory defined in the DATA DIVISION.

On the Variables tab you see those names and how they connect to SQL and files. This is the main mindset shift for DBAs:

You do not need to memorize COBOL level numbers (01, 05, and so on). In the UI, use top variables (parent groups) and their children the same way you would expand one logical record.

Hardcoded values

When a variable is assigned a literal in code, Explore shows that hardcoded value next to the variable name in the variable tree on the Variables tab.

Top variables and children

A top variable is a parent group—similar to one row’s structure or a record buffer. Children are the pieces inside it (account number, amount, status code).

On the Modules tab, sorting variables by number of children often surfaces the main input/output records a program uses.

When you care about “this column on the table,” follow the Fields tab into the variable that receives or holds that data, then explore the group around it.

Copybooks and DCLGEN (shared layouts)

Programs rarely redefine every field from scratch.

• Copybooks — Shared COBOL layouts (often file records or common structures) copied into many programs.
• DCLGEN — Layouts generated from Db2 table definitions so COBOL variables match table columns.

In AI variable summaries, you may see copybook names as sources of structure. In Explore, related variables and fields show how table columns map into program storage.

Where logic runs: paragraphs

COBOL business logic is organized into paragraphs (labeled sections in the PROCEDURE DIVISION), not into SQL-style steps.

On variable detail, Zengines lists paragraphs where that variable appears. Click a paragraph to see statements and other variables in that chunk of logic—useful when you need “where is this amount calculated?” without reading the whole program.

You do not need to learn PERFORM or paragraph naming rules for lineage work. Follow paragraphs as chapters inside one module.

Files vs tables

A program can read a table in the morning and write a file for downstream systems—or the reverse. Tracing “where does this file column come from?” often goes Files or Jobs → variable (record layout) → module → table edges.

Files and data set names appear reliably when job language sources (JCL, CL, and related) have been ingested with the COBOL.

Batch jobs (job languages)

Job languages are the scripts that run batch work: which program runs, which data sets are inputs and outputs, in what order. On z/OS this is usually JCL; on IBM i, CL and CLLE are common.

In Zengines:

• Jobs tab — Job streams and steps
• Links from jobs to modules and variables (file record layouts)

If you know “job JOBRPT01 loads the extract,” start on Jobs; if you know the program name, filter Jobs by module.

Operations teams think in job names and data set names; application teams think in program names. Zengines links both.

Edges: how analysts trace COBOL without reading code

An edge is where data enters or leaves a module:

• Table in — Read from Db2 (including cursor fetch into variables)
• Table out — Insert, update, delete
• File in — Read a dataset
• File out — Write a dataset

Strong lineage research is edge to edge inside a module (and into called modules when they are in the project):

1. Start at an input edge (table or file).
2. Follow links to variables and the top variable for the record.
3. Walk paragraphs or children as needed.
4. End at the output edge (table or file) for the same business outcome.

You are tracing a business fact or record, not one tiny field in isolation.

Quick map: concept → Zengines tab

What you can skip as an analyst

You do not need fixed-format column rules, compiler options, or COBOL syntax manuals to use Data Lineage effectively. Use Explore for facts, Summary / Tell Me More for narrative, and Ask a Lineage Question when you are exploring by business topic.