Most AS/400 documentation was accurate on the day somebody typed it.
That is the whole problem in one sentence. A Word file describing the order entry suite matched the code in 2009. Nothing since then has forced the two back into agreement, because no compiler reads a Word file. Twelve rounds of changes later, the document still opens, still looks authoritative, and nobody on the team will bet a release on it.
The fix is a different kind of document. Documentation that a developer can check against the compiled source in under a minute is worth keeping. Documentation that requires a two-hour interview to verify is a historical artifact.
Why AS400 documentation goes stale on a live system
Four forces work against every binder, and none of them is anybody's fault.
Nobody owns it. Somebody wrote most AS400 documentation for a project, and the project ended. The document has no maintainer after the go-live party, because maintaining it was never on anyone's job description.
Source changes and the document does not. A developer fixes a rounding error at four in the afternoon, tests it, promotes it, and closes the ticket. Updating a document nobody reads is not on the ticket, and it never becomes urgent enough to make the list.
The people who understood the gap retire. A senior developer knows which sections of the document to trust. That knowledge is a mental errata sheet, and it walks out with them.
Nothing ever fails because the document is wrong. A stale comment in a source member at least sits next to the code. A stale document sits in a shared folder, and the first person to discover it is wrong is usually a new hire making a change they cannot undo.
The test that separates documentation from a description you can trust
Ask one question about any sentence in an IBM i document. How long does it take a developer to prove it?
If the sentence came from the source, the developer opens the member and confirms it in the routine. That takes a minute. If the sentence came from an interview in 2009, proving it means reading the whole program and reconstructing the intent. That takes an afternoon, and most teams skip it and assume instead.
The difference is provenance. A description generated from the ingested source points back at specific code. Every claim in it is checkable by construction, and a developer who checks three claims and finds them accurate will trust the fourth.
This is the property to demand from any AS400 documentation tool. Not polish. Traceability back to the member the sentence came from.
What a generated program description contains
A description built from source covers ground an interview never reaches consistently.
- What the program does, stated in plain English, at the level a developer needs before opening it.
- Which files it reads and which it writes, with the record formats behind them.
- What calls it and what it calls, including the copy members it pulls in.
- The parameters it takes and where they come from.
- The branches that fire rarely, meaning the exception paths a summary usually drops.
The last item is where hand-written documentation fails most predictably. Somebody describing a program from memory describes the main path. The branch that fires twice a year for one customer is exactly the branch that breaks a conversion, and it is the first thing an interview leaves out.
Readiness status: what parser confidence actually reports
AS/Forward attaches a readiness status to every program it reads. The status reports confidence in the read. It does not grade the program.
That distinction matters when the report reaches a manager. A low-confidence flag does not mean somebody wrote the program badly. It means the ingestion layer could not fully resolve something about that member, and it names what.
A high status means the pass resolved every copy member and found every call target it needed. Those descriptions can go straight to a developer.
A low status means the pass hit something it could not follow. The program page shows the specific warning. Your team reads the warning and leaves the program closed until somebody has a reason to open it.
What a low-confidence flag means for your next step
A flag is a work item with a name attached. Four causes account for most of them, and each has a different fix.
- A copy member sits in a library the source list never reaches. Somebody adds the library to the list and the pass reruns clean.
- The source in the member no longer matches the object that runs. Somebody edited in place, or a promotion skipped a step. This one is a real finding and worth chasing on its own.
- The program builds a call target at runtime from a parameter. No static read can follow that edge, and a developer has to document it by hand.
- A member is simply missing. Nobody kept the source when somebody compiled the object, and the object still runs in production every night.
That fourth case is the one worth naming to a board. A production program whose source nobody has is a program your organization cannot change, cannot audit, cannot convert and cannot safely retire. Most shops carry a few. Few know how many.
The flag turns that from a rumor into a count.
Running the pass on a 40-year AS/400 library
No team documents four thousand programs by opening them one at a time. The practical method reads the whole source library in one pass and builds the document from what the source says.
AS/Forward runs that pass. It reads six RPG dialects through a proprietary ingestion layer, then builds an interconnection graph across every program, file, copy member and display file in the library. From that structure it generates the plain-English description of each program. Machine time carries the bulk read, and your developers spend their hours on the exceptions the pass flags.
Expect the first pass to be messy, because nobody has read a real library end to end before. Members sit in libraries the list never reaches. Some source no longer matches its object. The report names those cases by member and by program, and that list is the first honest inventory your team has had.
Where the source sits during the pass is the question a regulated shop asks first. The preferred deployment runs air-gapped inside your own infrastructure, and nothing leaves your network. Model backends include Claude, OpenAI, Gemini and local models running on your own hardware. AS/Forward carries one US patent pending. Golden Path Digital tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
What the documentation is worth once it exists
The document pays for itself in four places, and only one of them is documentation.
Onboarding gets shorter. A developer who has never seen RPG can read a plain-English description of the nightly close and then open the member with a map already in hand. The senior developer then answers questions about intent, and the document covers the structure.
Audits get cheaper. When an auditor asks which programs touch the regulated field, the answer is a named list with a date and a method. Our page on RPG code analysis covers how a team uses that inventory under review.
Change scoping stops being a guess. The migration view takes a field or an object and lists everything that moves with it. A field length change becomes a named set of programs and print jobs, and the argument about how risky it feels ends there.
Retirement decisions become defensible. The graph names every program nothing calls. Your team stops paying to host and convert code that has not run since the last upgrade.
What a source-level pass cannot document
Two limits deserve a plain statement, because a demo hides both.
A read of the source describes what the code does. It cannot tell you why a rule exists. The description will report that orders over a threshold route to a manual queue, and the reason that threshold was set in 1998 lives with whoever set it. Capture that layer while your senior developers are still there, and attach it to the generated description as a note.
A read of the source also cannot confirm that the member matches the running object. Somebody edited a member in place years ago and recompiled from a different copy. The description will accurately describe the source it read, and production will behave differently. Comparing source dates against object dates finds most of these, and it belongs in the first pass.
Both limits argue for the same sequence. Generate the descriptions first, then spend your developers' time on the two questions only a person can answer.
Keeping it current after the first pass
A document that goes stale in six months repeats the original problem, so put the refresh on a schedule the way your team schedules anything else.
Rerun the pass on a cadence tied to change volume. A shop promoting changes weekly benefits from a monthly pass. A shop that touches production twice a year can run it twice a year. The pass is machine time, and the cost of running it again is small next to the cost of trusting a stale answer.
Watch the warning count between runs. A rising number of unresolved copy members usually means the library list has drifted or a promotion process has developed a gap. That trend is a maintenance signal your team gets for free.
Keep the old runs. Two passes six months apart show which programs changed, and that comparison answers a question no single document can.
Questions to ask about any AS400 documentation tool
Take these into the evaluation and write the answers down.
- Which RPG dialects does the tool read, including fixed-format RPG III?
- Can a developer trace any sentence in a description back to the source it came from?
- What does the tool report when it cannot resolve a copy member?
- Does it show which programs nothing calls?
- Where does our source code sit while the tool reads it?
The second question is the one that separates the field. A tool that generates confident prose with no path back to the member gives your team something that reads like documentation and gives nobody a way to check it. That is where your team started.
Start with the library you already have
Documentation for a 40-year RPG library does not begin with a writing project. It begins with a read.
Our IBM i modernization assessment page walks through what the pass produces and what your team does with each artifact. The AS/Forward page covers the product itself. Call Golden Path Digital at 501-232-7188 and tell us how many programs your production libraries hold. If nobody knows the number, that is the first thing the pass returns.