IBM i CDC: system journaling versus RPG triggers

On IBM i (AS/400), change capture usually comes down to Db2 for i journal-based CDC versus RPG (or other) triggers. Journals are the platform-native audit trail. Triggers are application-invasive and easy to underestimate in maintenance cost.

Gluesync’s IBM i path is journal CDC via QjoRetrieveJournalEntries. QSQJRN is journal-name context you will see in libraries—not the retrieval API itself.

System journaling and QjoRetrieveJournalEntries

IBM i journals record changes to journaled objects. Receivers hold the entries; retention and receiver management determine how far back you can catch up.

Gluesync reads journal entries through the QjoRetrieveJournalEntries API—the supported programmatic retrieval interface—then decodes and maps them for downstream targets.

Operational pillars:

• Journal and receiver strategy (size, retention, delete/detach policy)
• Object journaling actually enabled on the tables you care about
• Restart positioning after outages without replaying the entire history blindly
• Character encoding—EBCDIC (and CCSID) decoding done correctly, or your “CDC” becomes corrupted strings

Docs:

• IBM i journal CDC
• IBM i character encoding Q&A

RPG triggers: when teams reach for them

Triggers fire on insert/update/delete and can push events to queues or staging files. They look simple in a POC.

Trade-offs:

• Extra CPU and I/O on every write path (interactive and batch)
• Every schema change risks trigger drift
• Easy to miss tables, logical files, or programs that bypass expected paths
• Dual maintenance: business RPG + trigger programs + promotion procedures

Triggers can still be right for narrow, controlled cases. They are rarely cheaper than journals once you count promotions and incident load.

Journaling vs triggers

Topic	System journaling + QjoRetrieveJournalEntries	RPG triggers
Invasiveness	Journal objects; no per-row trigger program required	Code on each table/event
Capture completeness	Tied to journaling coverage	Tied to trigger coverage
Recovery	Receiver retention + entry positioning	Custom staging/queue design
Encoding	Must decode journal payloads (EBCDIC/CCSID)	Still your problem if you stage text wrong
Maintenance	Receiver ops + API consumer	Trigger source + promotions
CPW / CPU	Journaling has cost; avoid marketing “zero CPW” as a universal measured guarantee	Trigger cost sits on the write path

Soft claim on resources: impact depends on journaling scope, receiver rates, and retrieval pattern. Do not treat “zero CPW” as a blanket measured promise. Platform materials may also position low end-to-end latency (including sub-45ms class figures); that depends on topology and LPAR load—positioning from product materials, not a measured guarantee for every deployment.

Build vs buy

Dimension	AI-generated / custom	Gluesync IBM i journal CDC
Entry retrieval	You wrap QjoRetrieveJournalEntries correctly	Documented journal CDC agent
Receivers / retention	Your runbooks	Docs + operational guidance
EBCDIC / CCSID	Easy to get subtly wrong	Encoding guidance in product docs
Triggers alternative	You own RPG forever	Prefer journal path; avoid trigger sprawl
Ownership	IBM i specialists on your payroll	Product + support

FAQs

Is QSQJRN the CDC API?

No. QSQJRN is a common journal name/context. Programmatic retrieval for Gluesync-style CDC is QjoRetrieveJournalEntries.

Why not only RPG triggers?

They couple capture to application code, add write-path cost, and age poorly across releases. Journals are the system of record for Db2 for i changes when objects are journaled.

What about EBCDIC?

Treat encoding as a first-class requirement. See the character encoding Q&A.

Can AI generate an IBM i connector?

It can draft API call sketches. Production needs receiver policy, restart semantics, CCSID correctness, and IBM i security/exit-point realities.

Next steps

• Journal CDC
• Encoding Q&A
• If you want to validate journaling on your LPAR, start a free trial or reach out—I am around.