RPG Development Services: Solving the Maintainer Knowledge Gap

It Starts with the Wrong Programs 

Older environments often contain source code that is no longer being used. An RPG AS400 programmer who inherits such an environment may assume that every program matters simply because it is still there. 

Documenting everything is rarely the best use of time. A better starting point is the code that actually runs. Job logs and program call data can help identify the active working set, which is often much smaller than the full source library. 

What to Extract, in Order 

A practical knowledge transfer effort should follow the application as it operates rather than trying to document the entire codebase at once. 

1. Live inventory: Identify which programs run, how often they run, and what triggers them. 
2. Data model in practice: Document how the data is actually used, including files written by multiple programs. Shared files often contain important business exceptions. 
3. Business rules: Describe the rules in plain language, with separate documentation for each functional area. The goal is to make the rules understandable even to a developer who has never worked with RPG. 
4. Integration points: Record every connection to other systems, including scheduled transfers and screen-scraping processes. 
5. Exceptions and workarounds: Capture the manual steps that operations teams use when the standard process does not work. These are often some of the least documented parts of an application. 
6. Deployment and change process: Document how changes are actually tested, approved, deployed, and maintained. 

The business rules deserve particular attention because they remain useful regardless of what happens to the platform. That knowledge can support continued iSeries application development, an interface modernization effort, or a future rewrite. Capturing it once gives the organization more options later. 

Using AI Assistance Without Fooling Yourself 

AI can make this work considerably faster. A language model can summarize unfamiliar code, suggest plain-language descriptions, and help engineers work through large numbers of program members. That can remove much of the repetitive work involved in the first pass. 

There is an important limitation, though. AI can describe what the code appears to do. It cannot reliably explain why a business rule exists, whether that rule is still valid, or why an exception was added years ago. 

That makes the division of work straightforward. AI can handle repetitive extraction. Engineers and subject matter experts need to own the interpretation, architecture, judgment, and review. A generated description that has not been checked by someone with the right domain knowledge is not reliable documentation. It is only an interpretation of the code. 

The Verification Rule