Ask an IBM i team what a specific program from 1994 does, and the honest answer is usually a name. Dave knows. Dave wrote it, Dave maintained it, and Dave retires in August. RPG code analysis is how you get that answer out of Dave's head and into something your whole team can read, before the question becomes urgent.
For shops sitting on decades of RPG, analysis is not an academic exercise. It is the difference between planning a modernization and gambling on one. It is also, increasingly, the only practical way to onboard developers who did not grow up on the platform.
What RPG Code Analysis Actually Has to Cover
RPG is not one language. Depending on when your shop started and how it grew, your source library probably holds fixed-format RPG III alongside free-format RPG IV, with DDS-defined files, display files, printer files, and copy members threaded through all of it. AS/Forward reads six RPG dialects through a proprietary ingestion layer, because a tool that only understands the modern dialect leaves the oldest and riskiest code unread.
Real analysis has to answer four questions about every program in the library:
- What does this program do, in terms a person can read?
- What does it depend on, and what depends on it?
- Is anything unresolved, like a missing copy member or a dependency the source never declares cleanly?
- Is this program still doing work, or is it dead weight nobody has retired?
Anything less is a partial map, and partial maps are how migrations find their surprises in production.
Why Grep and Tribal Knowledge Stop Scaling
Most IBM i teams already do code analysis. They do it with source scans, cross-reference utilities, spreadsheets, and the memories of senior developers. That works right up until it does not. Cross-reference tools show you that program A references file B, but not what the reference means for a migration. Scanning source for a field name finds the literal matches and misses the indirection. And tribal knowledge has a retirement date.
The failure mode is consistent: the team is confident about 80 percent of the codebase and silent about the rest. The silent 20 percent is where the nightly job nobody documented lives, and it is exactly the code a modernization project trips over.
Dependency Maps: Seeing the Edges Instead of Guessing
The core artifact of modern RPG code analysis is an interconnection graph. Every program, file, and copy member becomes a node, and every dependency becomes an edge you can actually look at. When someone proposes changing a field, the migration view scopes the blast radius: every program that reads it, every report that prints it, every downstream file that inherits it.
That map changes the conversations. A field length change stops being "should be fine" and becomes a list of fourteen named programs and two print jobs. Leadership gets scope instead of assurances. Your developers get to say "here is what moves" instead of "we think it is contained."
Dead Code Is a Finding, Not a Feeling
Forty years of development leaves sediment. Duplicated routines, one-off fixes that became permanent, programs whose only caller was deleted in 2009. An honest analysis flags code that nothing references, so you can decide what to retire instead of paying to modernize logic that stopped mattering years ago.
This is one of the quietest ways an assessment pays for itself. Shops routinely discover that a meaningful slice of what they assumed they had to migrate does not need to go anywhere except the archive.
Plain-English Descriptions Your Newer Staff Can Read
The other half of the output is language. AS/Forward generates structured plain-English descriptions of each program: what it reads, what it writes, what its logic does. The descriptions are built from the ingested source itself, not from a model's guess, which is why they hold up when a developer checks them against the code.
For teams hiring developers who have never touched RPG, this is the onboarding document that never existed. A new hire can read what the order allocation program does before they read a line of fixed-format source. The knowledge that used to live only in Dave's head becomes a document that survives Dave's retirement party.
From Analysis to a Decision
Analysis is the first step of a modernization, not the whole thing. Each program page in AS/Forward pairs the source with its description, its dependency edges, warnings for anything unresolved, and a readiness status based on how confident the ingestion layer is in what it read. Programs that are clean and well-understood are marked ready. Programs with gaps get flagged for human review before anyone converts them.
From there the choice is yours: convert to free-format RPG and stay on the platform, move to Python or another modern language, or modernize in stages. The whole process runs air-gapped inside your own infrastructure, so the analysis never requires your source code to leave your network. If you want the fuller picture of how the assessment stage works, we broke that down in our guide to the IBM i modernization assessment.
Get the Map Before You Need It
The best time to analyze a 40-year-old codebase is before the migration deadline, the audit, or the retirement that forces the question. Golden Path Digital can run AS/Forward against your RPG library and hand your team the dependency map, the descriptions, and the dead code list. Call 501-232-7188 and tell us what your system runs.