Skip to content
OPACKI
Get in touch

Change Data Capture for IBM i / DB2 for i

CDC for IBM i that understands more than row changes.

A Java-based CDC product, built on 40 years in data integration. It follows the data — and the file-lifecycle and structural changes behind it — from the journal into Kafka, Azure Service Bus, Azure Event Hubs and ETL targets.

Explore the productGet in touch
handles
  • INSERT
  • UPDATE
  • DELETE
  • CR (Clear member)
  • CT (Create file)
  • CG (Change file)

  1. origin

    IBM i / DB2 for i

  2. record

    Journal

  3. capture

    CDC Engine

  4. delivery

    Targets

    • Kafka
    • Azure Service Bus
    • Event Hubs
    • ETL
Pipeline diagram: journal entries — INSERT, UPDATE, CR, DELETE, CT, UPDATE, CG, INSERT — flow from IBM i / DB2 for i through Journal and CDC Engine to Kafka / Azure Service Bus / Event Hubs / ETL.

01 — The problem

Row changes are the easy part.

Conventional CDC pipelines are built around INSERT, UPDATE and DELETE. An IBM i journal also records what happens to the files themselves — and those entries change the real state and structure of the source.

What conventional CDC pipelines handle

  • INSERTA row is added.
  • UPDATEA row is modified.
  • DELETEA row is removed.

What the journal also contains

  • CRClear member

    A member is cleared — for example by CLRPFM. Every row is gone, but no DELETE was journaled for any of them.

  • CTCreate file

    A new file appears on the source. There is no target table waiting for it.

  • CGChange file

    The file’s definition changes. Rows that follow may no longer match the structure the target expects.

Ignore them and the pipeline quietly stops telling the truth.

  • Schema drift

    Source and target structures diverge without anyone being told.

  • Stale targets

    A member cleared on the source is still full on the target.

  • Broken pipelines

    The next row change arrives in a shape the target cannot accept.

  • Manual reconciliation

    Someone writes the script that puts things back — usually on a Saturday night.

02 — The product

Treat lifecycle events as data.

The CDC engine reads CR, CT and CG entries as first-class events — not noise to be filtered out — and applies their meaning to the target. Structure stays in sync alongside the rows.

  • CRClear member

    1. SourceCLRPFM CUSTOMER
    2. CDCCR (Clear member)detected
    3. TargetTRUNCATE CUSTOMER

    CLRPFM on source → target truncates.

  • CTCreate file

    1. SourceCREATE FILE ORDERS
    2. CDCCT (Create file)detected
    3. TargetCREATE TABLE ORDERS

    New file appears → new table provisions itself.

  • CGChange file

    1. SourceALTER / CHANGE FILE
    2. CDCCG (Change file)detected
    3. TargetSchema evolves

    Source schema evolves → target evolves.

Your Kafka, Azure Service Bus, Event Hubs and ETL targets don’t break, don’t drift, and don’t need a Saturday-night reconciliation script.

03 — How it works

From the journal to modern infrastructure.

A Java CDC engine reads the IBM i journal and forwards both row-level and file-lifecycle changes to event-driven and ETL targets.

Source

  • IBM iOperating environment
  • DB2 for iDatabase
  • JournalRow + lifecycle entries

CDC

Java CDC EngineReads, interprets, applies
  • INSERT
  • UPDATE
  • DELETE
  • CR (Clear member)
  • CT (Create file)
  • CG (Change file)

Targets

  • KafkaEvent streaming
  • Azure Service BusMessaging
  • Azure Event HubsEvent ingestion
  • ETL / downstreamWarehouses, pipelines, systems
  • row changes
  • file-lifecycle events
IBM i, DB2 for i and its journal feed a Java CDC engine, which forwards row and file-lifecycle changes to Kafka, Azure Service Bus, Azure Event Hubs and ETL targets.

04 — Event awareness

Your journal says more than INSERT, UPDATE and DELETE.

Between the row changes sit entries that describe what happened to the file itself. A CDC engine that recognizes them can keep the target’s structure honest, not just its rows.

journal entries
  1. UPDATECUSTOMER
  2. INSERTORDERS
  3. CR (Clear member)TEMP_ORDERS
  4. CG (Change file)CUSTOMER
  5. CT (Create file)ARCHIVE_2026
  6. INSERTARCHIVE_2026
  7. DELETEORDERS
7 entries · 3 lifecycle
  • CR (Clear member)

    CR means the data is gone

    No individual DELETE entries follow a clear. A target that only reacts to row changes keeps serving rows that no longer exist.

  • CG (Change file)

    CG means the definition changed

    Rows journaled after a file change may carry a different structure. Without acting on CG, the next UPDATE can be the one that breaks the pipeline.

  • CT (Create file)

    CT means something new exists

    A new file on the source has no counterpart downstream until someone creates one — or until the CDC engine does.

05 — Experience

40 years of data integration.

The product comes from decades of dealing with real enterprise data systems — not from a theoretical understanding of CDC.

Built by

Cezary Opacki

Timeline

  1. IBM mainframes
  2. AS/400
  3. DB2 for i
  4. Java
  5. Event-driven systems
  6. Modern cloud

40 years in data integration — IBM mainframes, AS/400, DB2 for i, modern cloud. One observation keeps repeating: most CDC tools for IBM i fall over the moment something other than a row change appears in the journal. I build the one that doesn’t.

— Cezary Opacki

Engineering philosophy

Most CDC problems don’t happen when everything goes according to plan.

They happen when objects change, schemas evolve, files are cleared, or new structures appear. A pipeline that only knows about rows has nothing to say in those moments. This one was designed for them.

06 — Contact

If your IBM i CDC pipeline breaks every time DDL touches the source — talk to me.

Send a message