The AS/400 Migration: Building a Plan B for RPGLE
The response to “The Myth of the ‘Impossible’ AS/400 Migration” proved that when we open up these tough conversations as a community, there is nothing we cannot achieve together. I’m not just thanking everyone for the support on my previous post; I am bowing my head with respect.
Some felt this exercise was a waste of time and money, or perhaps a marketing gimmick. Let me clear the air: my intention isn’t to sell anything. I have been an IBM i developer for 7 years. I sit right in the middle of the incoming GenZ and the retiring veterans — I like to call myself “MidZ.” My core worry is the widening skills gap. Will GenZ want to code in RPG? Will the veterans be around forever to keep the platform alive? We have to explore what a “Plan B” looks like.
Diving into wmsPOCv3: The Second Case Study
My first case study, AlphaMFG, was a baseline test to check for immediate roadblocks when migrating to AWS. Now, we are going much deeper. I designed this second case study to stress-test the major programming concepts of the AS/400 across different eras of RPG:
- RPG IV (Fixed format)
- RPG IV (Free format)
- RPG IV (Mixed format)
- COPYBOOKs (RPGLE)
- SQLRPGLE (Fixed and Free)
Here is exactly what we accomplished and validated using this case study POC:
1. Fixed-Format Program
Classic RPG IV column-based specification format. WMSMSTR (Menu Option 01, Warehouse Master maintenance) is a compact, authentic example of a pattern very common in real IBM i shops: a compound DOWEQ/ANDEQ loop condition, and a single CHAIN whose found/not-found indicator decides whether to WRITE a new master record or UPDATE an existing one — no separate add/change/delete screens, just one indicator-driven flow.
2. Free-Format Program
Strict free-format RPGLE, **FREE in column 1. WMSGRN (Menu Option 03, Goods Receipt) is one half of the post-refactor engine split — a focused, single-purpose program with its own dedicated display file, sequence-number generation, and zero branching by transaction type.
3. Mixed-Format Program
Fixed-format H/F/D specs combined with a /FREE calculation block and fixed-format EXSR/BEGSR subroutines in the same program. WMSPRCPS (Menu Option 08) receives its transaction number via a fixed-format *ENTRY PLIST, executes its main calculation in /FREE, and drops back into fixed-format subroutines to invoke copybook procedure calls.
4. Legacy Branching (CABEQ / GOTO / TAG) — and Its Retirement
WMSENGIN demonstrates classic compare-and-branch opcodes. While retained in the codebase for reference, it was deliberately unhooked from the main menu during refactoring to prove how legacy control flows can be modernized into single-purpose modular dispatchers.
5. Copybooks
/COPY pulls shared source into a program at compile time. WMSCPY1 supplies a shared item data structure plus procedure prototypes; WMSCPY2 supplies the actual procedure bodies (CalcAvailQty, IsLowStock), consumed by WMSPRCPS. What the generated Java does with this is worth knowing before you rely on copybooks as a reuse mechanism through this kind of transform.
Technical Detail: Differentiating IBM i RPGLE /COPY logic from mainframe COBOL copybooks during automated translation was a significant technical milestone in this project.
6. Keyed Access (CHAIN, SETLL / SETGT + READP)
Demonstrating fundamental IBM i file operations: single-record random lookup via CHAIN, and boundary positioning via SETGT + READP to fetch the highest key for auto-sequencing.
7. Interactive UI & Indicator Data Structures (INDDS)
Every program in wmsPOCv3 uses an Indicator Data Structure (INDDS) to map named booleans to raw indicators, removing hardcoded *INxx numbers from display logic.
8.a SQLRPGLE — The Legacy Approach
Fixed-Format Embedded SQL (WMSSQLFX): fixed-format C/EXEC SQL, a single-row SELECT INTO against host variables, checked with a plain fixed-format IF on SQLCOD.
8.b SQLRPGLE — The Modern Approach
Fully Free-Format SQL Cursor (WMSSQLFR): The FREE directive with inline EXEC SQL, an explicit DECLARE CURSOR + FETCH NEXT loop, checked against SQLSTATE each pass.
Conclusion: The AWS Reality Check and Our “Plan B”
This entire case study has been migrated to AWS. While a few display formatting details are still being fine-tuned, the core RPG logic, SQL cursors, and business rules are firing natively in the cloud:
Get Md Hussain’s stories in your inbox
Join Medium for free to get updates from this writer.
👉 Live Demo: www.as400toaws.com/wmspocv3
The goal of this POC isn’t to claim that every enterprise must shut down their IBM i tomorrow. It was built to answer one question: As the skills gap widens, is there a viable Plan B for RPGLE codebases?
The answer is a definitive yes.
What Is My Future Roadmap?
This case study proved the engine works, but there is still a lot to unpack under the hood. In my upcoming articles, I will be breaking down the exact mechanics of this transition:
- RPGLE vs. Java: A side-by-side autopsy comparing the original legacy code patterns with the newly transformed Java output.
- The DB2 Migration Blueprint: A deep dive into DB2 for i migration, specifically addressing the physical and logical file (PF/LF) transition and the hurdles of EBCDIC to ASCII conversion.
- AI-Driven IBM i Migration: Prototyping a custom RAG (Retrieval-Augmented Generation) setup to automate the translation and deployment pipeline, streamlining the CLI workflow used during the initial AlphaMFG / wmsPOCv3 rollout.
Let’s Open the Discussion
If migration might become necessary down the road anyway, why wait to explore options? What is currently holding your team back from building a Plan B today?
P.S. Let’s stress-test this in the real world. I want to test this translation pipeline against real enterprise complexity. If your team has an isolated test box or an LPAR and is open to a collaborative technical experiment, let’s connect! Let’s see how your heaviest legacy RPG handle the transitions.
— Md Hussain
#IBMi #AS400 #AWS #CloudMigration #RPGLE #LegacyModernization #BuildInPublic
