RPG 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 RPG source. It explains the ideas you will see in Zengines Data Lineage—the same Modules, Tables, Fields, Variables, Jobs, and Files tabs as COBOL projects—not how to write programs.

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

For COBOL-centric projects, see COBOL basics for lineage research. The UI and research patterns are the same; only the language concepts below differ.

Program and module

In IBM i and mainframe shops, a program is a compiled unit of RPG logic (fixed-format, RPG IV, free-form, and other flavors). In Zengines, that program is a module on the Modules tab.

When documentation or AI text names a program, look for it 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 RPG is how programs talk to the database. Zengines parses that SQL and links it to modules and variables.

Variables (RPG working data)

RPG does not work on “rows” inside the program the way SQL does. It works on variables—fields, data structures, and record buffers defined in the program or copied from shared specs.

On the Variables tab you see those names and how they connect to SQL and files:

Use top variables (parent groups) and 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—useful for spotting fixed codes, flags, and constants without reading source.

Shared layouts

RPG programs often use copy members, data structures, and external descriptions for file and table layouts—similar in role to COBOL copybooks and DCLGEN. AI summaries may reference these when explaining structure.

Where logic runs: subroutines (not paragraphs)

COBOL organizes logic into paragraphs. RPG organizes it into subroutines (and procedures in newer RPG).

On variable detail on the Variables tab, Zengines lists the subroutine where related code runs—not paragraphs. Click a subroutine to see statements and other variables in that section.

• Free-form RPG — Subroutine names are usually readable; the list is a practical map of where logic lives.
• Legacy fixed-format RPG — Subroutine names are often short abbreviations that are hard to interpret without reading source. Treat the list as a pointer, not a plain-English label.

When subroutine names are not enough

Zengines Assist - Variable Summaries, Ask a Lineage Question, and other Zengines Assist answers use code comments and full lineage context—not just subroutine labels. For non-developers, these AI tools are often the better starting point on legacy RPG than clicking through abbreviated subroutines alone.

See Zengines Assist - Variable Summaries and Ask a Lineage Question.

Files vs tables

Tracing “where does this file field 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, CLLE, and related) are ingested with the programs. See Understanding your Data Lineage project.

Batch jobs (job languages)

Job languages are the scripts that run batch work: which program runs, which files or data sets are inputs and outputs, in what order.

In Zengines:

• Jobs tab — Job streams and steps for COBOL, RPG, PL/I, and other ingested legacy modules
• Links from jobs to modules and variables (file record layouts)

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

Edges: how analysts trace RPG without reading code

An edge is where data enters or leaves a module:

• Table in — Read from Db2
• Table out — Insert, update, delete
• File in — Read a file
• File out — Write a file

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. Use subroutines, children, or AI summaries as needed.
4. End at the output edge (table or file) for the same business outcome.

See Tracing data lineage in Explore and Research best practices.

Quick map: concept → Zengines tab

What you can skip as an analyst

You do not need RPG specification levels, opcode manuals, or fixed-format column rules to use Data Lineage effectively. Use Explore for facts, Summary / Tell Me More and Ask a Lineage Question for narrative—especially on older RPG where subroutine names alone are opaque.