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 productFree journal assessment
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 — Capabilities

One product, one console.

Capturing changes is one part of keeping a target trustworthy. Loading it, checking it and proving it still matches are the rest — and they are in the same product, under the same console.

  • Change Data Capture

    Row changes and the file-lifecycle entries behind them — INSERT, UPDATE and DELETE alongside CR, CT and CG — read from the journal and applied to the target.

  • Full initial-load refresh

    A complete reload of a table from the source, so a new or re-synchronised target starts from a full copy rather than from the next journal entry.

  • Online source/target reconciliation

    Compare source and target while replication keeps running — no outage window to find out whether the two still agree.

  • Field-level diff checking

    When something does differ, the check narrows it to the row and the field, instead of reporting that a table is out of sync.

Reconciliation is the part that earns trust

It answers the question every migration eventually runs into: how do you know the target matches the source? Not by assumption — by a check you can run while the pipeline is live.

Four capabilities, one product — not four tools to license, deploy and keep in step with each other.

04 — Configuration

A hundred tables, a hundred rows.

Configuration for a hundred replicated tables fits in a hundred rows of one column in one control table. No per-table XML, no metadata scattered across a filesystem, no consulting engagement to onboard a new schema.

One control table

TABLE

  • PRODLIB/CUSTOMER
  • PRODLIB/ORDERS
  • PRODLIB/ORDERLINE
  • PRODLIB/ARTICLE
  • PRODLIB/STOCK
  • PRODLIB/INVOICE
  • …94 more rows
One column. One row per replicated table.

What this usually looks like

  • cdc-config/
  • customer.xml
  • orders.xml
  • orderline.xml
  • article.xml
  • stock.xml
  • invoice.xml
  • …94 more files
A file per table, each with its own mapping to keep in step.

  • Add a table

    Add a row.

  • Onboard a new schema

    Add rows.

  • Audit what is replicated

    Read one table.

05 — 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.

06 — 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.

07 — How it compares

The rows where the difference shows up.

Every CDC tool replicates rows. The question worth asking a vendor is what happens when the journal contains something else — and how much work each new table costs you.

Typical IBM i CDC tool compared with OPACKI CDC
CapabilityTypical IBM i CDC toolOPACKI CDC
INSERT / UPDATE / DELETETypical IBM i CDC toolHandledOPACKI CDCHandled
CR (Clear member)clear memberTypical IBM i CDC toolUsually ignored; target keeps the old rowsOPACKI CDCTarget truncates
CT (Create file)create fileTypical IBM i CDC toolUsually ignored; target table created by handOPACKI CDCTarget table provisions itself
CG (Change file)change fileTypical IBM i CDC toolUsually ignored; pipeline breaks on the next rowOPACKI CDCTarget schema evolves
Initial loadTypical IBM i CDC toolOften a separate tool or a hand-written unloadOPACKI CDCFull refresh, same product
Source/target reconciliationTypical IBM i CDC toolOften a script someone maintainsOPACKI CDCOnline, same product
Field-level diff checkingTypical IBM i CDC toolRarely availableOPACKI CDCDown to the row and the field
Configuration effort per tableTypical IBM i CDC toolA configuration file per tableOPACKI CDCOne row in a control table

No vendor names: the point is the shape of the gap, not a scoreboard. Bring this table to whoever you are evaluating and ask them to fill in their own column.

08 — 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.

09 — Contact

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

Start here

Free journal assessment

Send a journal sample and find out which entries your current CDC is silently dropping.

Or a 30-day proof of concept on your own system.

Or reach me directly

Send a message