“In many global enterprises, RPG III remains a mission-critical asset. This series provides the foundational skills to decode legacy logic and prepare for future modernization.”
Understanding 80% of Display Programs by Following the “Order of Execution”
- ✅ Introduction: Why I Decided to Write About “How to Read” RPG III Now
- 🔀 The “Divide” Occurring in the Field
- 🎯 What I Aim to Achieve with This Series
- 1. The Verdict: Read Display Programs in This Specific Order
- 🗂️ 2. F-Specs: Start by Identifying “Update or Inquiry?”
- 🧾 3. I-Specs: Focus Only on “Input Fields” and “Key Fields”
- ⚙️ 4. C-Specs: Read in “Logic Blocks” (Don’t Trace Line-by-Line)
- 🧨 5. Common Pitfalls (Where Beginners Get Stuck)
- 🚀 6. A Final Word on DX: Reading is the Gateway to Migration Design
✅ Introduction: Why I Decided to Write About “How to Read” RPG III Now
The reason for starting this series is simple.
In my recent projects, I have repeatedly encountered situations that led me to a stark realization: “Leaving these systems unaddressed poses a critical risk to the business.”
Even today, systems running on IBM i (AS/400) remain the “beating heart” of many enterprises. From Sales and Procurement to Inventory, Billing, Payments, and Manufacturing—if these systems fail, the entire operation grinds to a halt. In many cases, these mission-critical applications have been running for decades without a single moment of downtime.
Yet, despite their importance, the following alarming scenarios are becoming far too common in the field:
- The source code exists, but only a handful of people can actually read it.
- Modifications are needed, but fear of the “unknown impact” makes it impossible to touch.
- The “veterans” who know the system inside out are either retiring or already gone.
- As a result, messy “operational workarounds” keep piling up just to keep the system running.
⚠️ A Harsh Reality (But the Truth)
It may sound harsh, but being able to “read the code” is no longer the same as being able to “maintain it for the future.”
🔀 The “Divide” Occurring in the Field
A clear divide is currently emerging in the workplace.
While the expertise built on RPG III remains highly valuable, modernization efforts—such as moving to Free-Form RPG or SQL-centric development—require a different set of skills and a new workflow.
This is not to say that “veterans are lacking.”
The reality is that the methods optimized over years of operation are simply becoming harder to apply to today’s changing requirements.
And if we are to achieve true DX (Digital Transformation), taking the next step based on the current reality is unavoidable.
- 📌 First, organize the current status into a readable format (Inventory / Visualization).
- 📌 Next, perform small, safe modifications (Step-by-step migration).
- 📌 Then, proceed toward Free-Form RPG (and SQL integration if necessary).
Rather than a sudden, full-scale overhaul, the only sustainable approach that actually works in the field is: Make it readable → Visualize → Modify safely and in small steps.
🎯 What I Aim to Achieve with This Series
This series is not about “reminiscing” about RPG III.
The purpose is to provide a structured approach to “reading” the code, ensuring that mission-critical systems remain operational while being successfully passed on to the next generation.
- 🧭 To serve as a “Map” for young developers as they tackle RPG III source code.
- 🧠 To provide a “Trigger” for veterans to verbalize the tacit knowledge stored in their minds.
- 🏢 To be the “First Step” for companies to break free from person-dependent dependencies.
I would be honored if this series serves as a helpful resource in these efforts.
Now, for our first lesson, let’s organize the way we read display programs by focusing on the “Order of Execution.”
1. The Verdict: Read Display Programs in This Specific Order
To quickly understand an RPG III display program, you should follow this fundamental reading order:
- 🗂️ F-Specs (File Specifications): Understand what is being input and output.
- 🧾 I-Specs (Input Specifications / Subfiles): Identify which fields are displayed and what data is being input.
- ⚙️ C-Specs (Main Logic Flow): Display → Input → Validation → DB Update.
- 🧯 Error Messaging: Understand where and why data is rejected.
- 🔗 CALL Targets / Referenced LF & PF: See what external programs or files are being called behind the scenes.
✅ Beginners often get lost by jumping straight into the C-Specs. The shortest path to mastery is to understand the “Ingredients” (F/I-Specs) first, before analyzing the “Cooking Process” (C-Specs).
🗂️ 2. F-Specs: Start by Identifying “Update or Inquiry?”
When reading F-Specs, the following points are far more important than the minute syntax details:
- 🖥️ Is there a Display File (WORKSTN)?
- 🧱 Which Database Files are being used?
- ✍️ Is the DB access for “Update” or 👀 “Input (Inquiry)”?
Just by identifying these, you can grasp the basic skeleton of the program:
- Display the screen.
- Read data from the DB and display it.
- Validate the input data.
- If OK, Update the DB (or CALL another program).
🧾 3. I-Specs: Focus Only on “Input Fields” and “Key Fields”
I-Specs contain a massive amount of information. Trying to trace everything at once will only burn you out. For this first lesson, let’s keep it simple and focus on just these three points:
- 🔑 Keys (Search Criteria): What do you need to input to retrieve the data?
- 📝 Update Fields: Which fields are being entered to be written to the DB?
- 📋 Subfiles (if any): Does it involve list displays and record selection?
✅ “What is the key for this screen, and what does it update?”
Once you grasp this, reading the C-Specs suddenly becomes much easier.
⚙️ 4. C-Specs: Read in “Logic Blocks” (Don’t Trace Line-by-Line)
Trying to trace C-Specs line-by-line is a surefire way to get lost. Instead, I recommend breaking down the C-Specs into these four functional blocks:
- 🧊 Block A: Initialization (Before Displaying)
- Setting initial values.
- Clearing/Initializing display fields.
- Handling first-time display flags.
- 📥 Block B: Data Retrieval (DB Read)
- Reading PF/LF using keys.
- Moving data to display fields (MOVE operations).
- Building subfiles (if applicable).
- ⌨️ Block C: Input Processing (User Action)
- Receiving screen input.
- Determining Function Key (F-key) actions and exit conditions.
- ✅ Block D: Validation → Update (DB Update or CALL)
- Validating input data.
- Displaying error messages and returning if invalid.
- Executing UPDATE / WRITE / CALL if all checks pass.
🧨 5. Common Pitfalls (Where Beginners Get Stuck)
- 🧯 Pitfall 1: Scattered Initialization Logic Initial values are set in multiple places, leading to inconsistent display behavior.
- ✅ Key Mindset: Aim to consolidate all initialization logic in one place.
- 🧯 Pitfall 2: Over-reliance on “Implicit Order” via Logical Files (LF) Processing logic often depends entirely on the pre-defined key sequence of an LF.
- ✅ Key Mindset: When migrating to SQL, always define explicit sort orders and filtering conditions, or the results may differ.
- 🧯 Pitfall 3: Error Handling Built Solely on “Screen Loops” Implementations often assume the program will simply “loop back” to the same screen on error.
- ✅ Key Mindset: Always trace exactly when and where the error messages are triggered within the logic flow.
🚀 6. A Final Word on DX: Reading is the Gateway to Migration Design
Once you can read display programs, the conversation about DX (Digital Transformation) finally becomes a reality. You begin to see:
- 🧩 Which screens interact with which PF/LF.
- 🧩 Which specifications are currently “managed through manual operations” (workarounds).
- 🧩 Where the boundaries are for a safe, step-by-step migration.
In short: Code analysis is the design work for modernization itself.
