You step into a new role as CTO. You inherit an IBM i estate running core business operations. You know the system holds forty years of accumulated business logic. You ask your vendors for a code audit. A week later a consultant delivers a fifty page document.
You open the file and you read a long list of user profiles. You see system values governing password expiration. You see object permissions dictating who can delete a physical file. This document tells you who can sign into the machine. It says nothing about how your billing programs calculate an invoice. You received a security audit of your object settings. A true code audit reads the lines of text inside your source physical files.
What a code audit reads inside your libraries
The operating system currently known as IBM i runs on Power hardware. It was once sold as AS/400 and iSeries. IBM later called it System i. Programs written in the 1990s still compile on modern machines. Those programs run your company today. You need to know what those programs actually do.
Object settings tell the operating system how to handle a compiled program. The object settings record the owner and the creation date. They record the public authority level. They tell you if a user can execute the program. A source level code audit reads the logic inside the members. It maps the dependencies between a calculation specification and a physical file. It reads the exact variables a developer declared in 1998.
The system tool DSPPGMREF reports which files a program references at the file level. It captures references at compile time. DSPPGMREF gives you a shallow view of your dependencies. It tells you a program touches a specific database file. It cannot tell you which specific field the program updates. Our process reads the source code itself to find those granular field level connections. For the object side of the equation, we recommend reading our dedicated IBM i security audit guide. For the application logic side, you must read the source text.
Six findings a source level code audit returns
A proper ingestion pass produces a precise list of actionable items. We categorize the anomalies inside your source code. You receive a structured view of your technical debt. Here are six specific findings our process uncovers when we read your RPG source.
| Finding | What it means | What your team does with it |
|---|---|---|
| Programs nothing calls | The program exists on disk but no active menu or program routes a user to it. | You isolate the program and stop paying to maintain it. |
| Unresolved copy members | Copy members pull source from other libraries into a program at compile time. An unresolved copy member is one the reading tool could not find. | You locate the missing library or confirm the code is obsolete. |
| Source members that no longer match the running object | A developer compiled the program and then changed the source code without compiling again. | You retrieve the correct source version before a migration. |
| Credentials as literal text in CL | CL programs that drive FTP transfers often hold a user ID and password as literal text. | You move the credentials to an encrypted configuration file. |
| Programs that adopt authority | A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. | You review the program to ensure it requires elevated permissions. |
| Runtime-built call targets | A program name assembled from a parameter does not appear in any static cross reference. | A developer documents the call by hand. |
Each finding requires a different response from your engineering team. Programs nothing calls clog your maintenance queues. Developers spend hours analyzing a module during a project only to discover the application never executes it. Finding dead code reduces your modernization scope.
Unresolved copy members halt modern compilers. This happens when past developers moved files or deleted old test environments. You cannot migrate an application with missing pieces.
CL programs that drive FTP transfers often hold a user ID and password as literal text. This practice was common decades ago. Today it presents a severe vulnerability. Identifying these literal strings lets you move credentials to secure storage.
Programs that adopt authority represent another historical shortcut. A program compiled with USRPRF(*OWNER) adopts its owner’s authority while it runs. This allows a restricted user to execute a highly privileged task. You must document these programs to pass modern compliance checks.
Runtime-built call targets hide your application structure. A program name assembled from a parameter does not appear in any static cross reference. The system evaluates the destination at the exact moment of execution. You must identify these dynamic calls to build a complete dependency map.
Why mismatching source requires your attention
Source that no longer matches the running object is the finding that matters most. A developer opens a source physical file and modifies a calculation. They save the changes to the text file. They forget to run the compile command. The production environment continues to run the older compiled object. The source member contains new logic that users have never executed.
Comparing source dates to object dates finds this discrepancy. The operating system attaches a creation date to the compiled program object. It attaches a last changed date to the source physical file member. Comparing these two dates belongs in the first pass. A newer source date indicates a dangerous mismatch.
This mismatch destroys modernization timelines. You decide to move your billing system to Python. You feed your source members into a translation engine. The engine produces clean Python code. Users immediately report incorrect invoice totals. The conversion engine translated the uncompiled text file. It translated logic that differs from the live production object.
You must reconcile your source members before you begin any conversion project. You investigate the modified text. You retrieve the correct historical source version. You establish a verified baseline of the exact logic running in production today.
The challenge of hidden dependencies and missing files
A forty year old application stack contains invisible connections. You need to know how data flows from a physical file to a calculation specification. You need to know how a display file presents that data to a user. Developers working decades ago did not build formal dependency maps. They wrote code to solve immediate business problems.
The operating system provides basic cross reference commands. DSPPGMREF reports which files a program references at the file level. It captures references at compile time. This system tool provides a shallow outline of your database usage. It tells you a program touches a specific database file. It cannot tell you which specific field the program updates.
Missing files create hard stops during any modernization effort. Copy members pull source from other libraries into a program at compile time. An unresolved copy member is one the reading tool could not find. Your current production program compiles perfectly because the compiled object already exists on disk. If you try to recompile that same program today, the compiler throws a fatal error.
The original developer deleted the library containing the copy member ten years ago. You cannot convert logic you cannot find. You must identify every unresolved copy member before you commit to a migration schedule. Our ingestion pass flags these missing dependencies as warnings. You receive a clear list of the exact files your team needs to locate.
Reading thousands of programs in one pass
A manual review of forty years of code rarely finishes. A human developer cannot hold the architecture of four thousand programs in their head. The developer loses track of nested copy members. The developer skips over dead logic. A code audit of RPG cannot be done by hand at scale.
A single ingestion pass does the job accurately. AS/Forward is software that reads IBM i RPG source. It reads six RPG dialects through a proprietary ingestion layer. It builds an interconnection graph across every program, file, copy member and display file. It flags unresolved copy members and missing dependencies as warnings. It generates a plain-English description of each program from the ingested source. It shows a readiness status per program.
We tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories. A migration view lets you scope a change. You pick a field or object, and the view lists what else moves. This precision removes guesswork from your estimates.
AS/Forward runs against Claude, OpenAI, Gemini or local models on the customer’s own hardware. The preferred deployment is air-gapped inside the client’s network. This keeps your proprietary business logic entirely private. AS/Forward carries one US patent pending.
What the final report hands a CTO
Our IBM i modernization assessment gives you the inventory. We ingest your production source libraries and hand back the program count. We provide the dependency graph and the plain-English descriptions. We deliver the warning list and the list of programs nothing calls. We document every unresolved copy member.
The final report hands a CTO exact metrics for executive planning. You receive counts by finding and members by name. You receive a readiness status per program. You receive the specific list of what the pass could not read. Every honest limit of the tool appears in your final documentation. You know exactly where the automated pass succeeded and where your team needs to perform manual checks.
We provide understanding first. You make the target decision second. Every outcome is valid once you have the facts. You might move off RPG entirely. You might clean up your existing estate to free-format RPG. You might keep your green screens and modernize the database behind them. You might rewrite your core logic in Python. You use the code audit as a map. You decide the destination.
How to use the report in the next budget cycle
A verified inventory shapes your funding requests. IBM i 7.4 reaches IBM end of support on 30 September 2026. IBM i 7.3 reached end of support on 30 September 2023. No date is announced for 7.5 or 7.6. You have a hard deadline to evaluate your application stack and plan your infrastructure moves.
You use the code audit report to justify your budget. You stop paying to host dead code. You avoid paying to convert dead code. You know exactly how many objects require attention. You know exactly how many programs adopt authority. You take the total program count and build a realistic timeline.
The migration view lets you scope an application change accurately. You pick a database field. The view lists every program, physical file, copy member and display file that moves if you alter that field. You hand this list to your developers. They know exactly which modules to test. You present your board with a budget based on exact program counts. You eliminate the vague estimates that cause modernization projects to fail.
How to start your code audit today
You have the authority to map your legacy logic. We offer custom software development and precise source analysis. You can call Golden Path Digital and ask us to read your production source libraries. We run the ingestion pass and we deliver the final assessment.
Or we install AS/Forward air-gapped on your own hardware and it reads the source there. You control the hardware and the model. Both paths give you a clear map of your legacy logic.
Call us at 501-232-7188. Speak to our team about your RPG library. We answer the phone and we plan the ingestion process around your schedule. We scope the project to fit your exact timeline. Go to our contact page and tell us you want to see exactly what lives inside your IBM i source files. Tell us the size of your estate. Tell us your timeline for modernization. We configure the ingestion pass to meet your deadlines. You take the first step toward a verified inventory today.