Beginning RPG — Part 3: Brewing Your First File Update

 Today’s Coffee: Death Wish Dark Roast — bold, intense, with notes of dark chocolate and a caffeine kick that could power an overnight compile marathon. Like this coffee, updating records in RPG isn’t for the timid — it’s strong, decisive, and delivers immediate impact.

---

Why This Matters Now

In Part 2, we learned how to read a file in RPG — the equivalent of smelling the coffee and taking that first sip.
Now, it’s time to pour our own: writing new records and updating existing ones.

Modern IBM i shops still rely on native RPG file I/O for performance, legacy integration, and transactional control. Even in an SQL-heavy world, knowing these native operations is like knowing how to brew coffee without a machine — it makes you a more versatile developer.

---

The File Layout

Physical File Name: CUSTFILE
Purpose: Stores basic customer information.

DDS (Data Description Specifications):

 

     A          R CUSTRECORD

     A            CUSID         10A        

     A            CUSNAME       30A        

     A            CUSPHONE      15A        

     A            CUSCITY       20A        

     A            CUSSTATE       2A        

     A            CUSJOIN         L        

 

     A          K CUSID

Field Descriptions:

• CUSID — Unique customer ID (key field)
• CUSNAME — Full customer name
• CUSPHONE — Contact phone number
• CUSCITY — City name
• CUSSTATE — Two-letter state abbreviation
• CUSJOIN — Date the customer joined (L = DATE type in DDS)

---

Updating a Record (Native RPG)

Read CustFile CUSID;

 

If %Found(CustFile);

   CUSPHONE = '555-4321';

   Update CustFile;  // Writes back changes to the same record

Endif;

Key point: You can only update the current record — the one you just read.

---

Writing a New Record (Native RPG)

CUSID    = 'CUST1009';

CUSNAME  = 'Latte Lover';

CUSPHONE = '555-1234';

CUSCITY  = 'Seattle';

CUSSTATE = 'WA';

CUSJOIN  = %date();

 

Write CustFile;

---

SQL Example for Comparison

Updating with SQL:

Exec Sql

   Update CUSTFILE

      Set CUSPHONE = '555-4321'

    Where CUSID = 'CUST1001';

Inserting with SQL:

Exec Sql

   Insert Into CUSTFILE

      (CUSID, CUSNAME, CUSPHONE, CUSCITY, CUSSTATE, CUSJOIN)

   Values

      ('CUST1009', 'Latte Lover', '555-1234', 'Seattle', 'WA', Current Date);

---

Native I/O vs Embedded SQL — Quick Comparison

Feature	Native RPG I/O (READ/UPDATE/WRITE)	Embedded SQL
Best for	Single-record keyed access, high performance	Multi-row operations, complex queries
Syntax Style	RPG opcodes (CHAIN, UPDATE, WRITE)	SQL statements inside RPG (Exec SQL)
Legacy Integration	Perfect for older RPG III/IV programs	Requires SQL precompiler
Performance	Excellent for indexed reads	Excellent for set-based updates/inserts
Maintainability	Familiar for RPG-only developers	Easier for SQL-fluent devs
Commitment Control	Supported via native opcodes	Supported via COMMIT / ROLLBACK
Learning Curve	Lower for RPG veterans	Lower for SQL-experienced devs

---

Real-World Scenario

**free

Dcl-f CustFile usage(*update:*output) keyed;

 

Dcl-s CUSID     Char(10);

Dcl-s CUSNAME   Char(30);

Dcl-s CUSPHONE  Char(15);

Dcl-s CUSCITY   Char(20);

Dcl-s CUSSTATE  Char(2);

Dcl-s CUSJOIN   Date;

 

// Search for customer

CUSID = 'CUST1001';

Chain CUSID CustFile;

 

If %Found(CustFile);

   CUSPHONE = '555-9876';

   Update CustFile;

Else;

   CUSNAME  = 'New Brew Co.';

   CUSPHONE = '555-2468';

   CUSCITY  = 'Nashville';

   CUSSTATE = 'TN';

   CUSJOIN  = %date();

   Write CustFile;

Endif;

 

If %Error;

   Dsply 'Error during file operation';

Endif;

*inlr=*on;

Return;

---

Leadership Angle

From a team lead perspective, knowing both read and write operations is crucial for onboarding junior developers. Too often, new hires only learn to read data and leave updates to “the experienced folks.” Breaking that barrier early — with controlled test files — builds confidence, reduces bottlenecks, and makes your dev team more self-sufficient.

---

Pro Tips & Cautions

• Test updates on a copy of the file before touching production.
• Use commitment control for transactional safety (COMMIT / ROLLBACK).
• Avoid mixing heavy file I/O loops with expensive calculations — it will hurt performance.
• Keep field names meaningful; CustomerPhone says more than Phone1.

---

Final Sip

Death Wish Dark Roast isn’t for casual sipping — and neither is file updating for casual coding. Both require a steady hand, precision, and respect for the strength of what you’re working with. In leadership and in RPG, bold actions have lasting effects — so make them with care, intention, and the skill that only comes from practice.

☕ All example code from this series lives on my GitHub repo so you can explore, run, and learn from real RPG programs — one sip at a time.

📖 Read more articles like this on my blog: The RPG Blend — Real Code, Real Coffee, No Nonsense.