SOLUTION · IBM i MODERNIZATION
IBM i (AS/400) change data capture and data replication
Real-time CDC from Db2 for IBM i journals, without turning your AS/400 into a polling target.
Gluesync by MOLO17 captures committed changes from IBM i (AS/400) system journals with a dedicated source agent, then delivers them continuously to the databases, warehouses, lakes, and event streams your teams already use. Manage pipelines from the Core Hub web UI, the Gluesync control plane.
WHO THIS IS FOR
IBM i teams moving operational data into modern systems
- IBM i / AS/400 modernization architects moving operational data toward cloud warehouses, lakes, or event platforms
- Teams replacing or extending legacy replication tools that already read IBM i journals, including Syniti Replicate and DBMoto-style estates
- Platform engineers evaluating commercial CDC versus DIY SQL journal readers, DISPLAY_JOURNAL-style approaches, or generic Db2 connectors not built for IBM i journaling
- Operations leads who need source and target roles on Db2 for IBM i, plus clear documentation for firewall ports, journal prerequisites, and agent tuning
THE PROBLEM
AS/400 data that only moves in batches becomes stale
Batch extracts and table scans leave analytics and applications working from stale copies. On IBM i, heavy SQL journal readers and per-table polling also compete with production CPW. Buyers searching for AS400 data replication, IBM i CDC, and Db2 for i replication usually need low source impact, journal-native capture, and heterogeneous targets beyond another Db2 LPAR.
Gluesync addresses that pattern with per-agent CDC: an IBM i source agent reads journals; target agents write to the destination you choose. Each supported system has its own agent and native change stream.
DOCS-TRUE ARCHITECTURE
How Gluesync does IBM i journal CDC
Native journal APIs, not file scans
On Db2 for IBM i, Gluesync uses native IBM i Journal APIs for CDC,
including QjoRetrieveJournalEntries. The agent connects with
the bundled IBM JTOpen JDBC driver and can operate as source and target
for Db2 for IBM i. Supported versions start at 7.1.
- Source CDC through native Journal APIs, journal receivers, and log parsing
- Target writes to Db2 for IBM i over JDBC, with secure transport supported
- DDS discovery and Gluesync metadata schema generation
- Full-table snapshots for initial loads
- Bulk-load workflows when mirroring into Db2 for IBM i as a target
- Connection pooling across pipelines
- Source-side persisted internal cache in Standard reading mode
- Journal parsing that forwards committed changes
- Truncate-like operations detected on read and supported on write where applicable
Two journal reader modes
- Standard Journal Reader Mode, default: shared reader grouped by journal, with local disk-persistent cache and fan-out per entity.
- Dedicated Journal Reader Mode: isolated per entity, with a direct stream from journal to target that bypasses the shared cache path.
Standard mode multiplexes retrieval for entities that share a journal, including documented behavior when more than 300 entities share one journal. Entity delivery from local cache does not re-hit IBM i for every target write loop.
Journal prerequisites that matter in production
Journals must be configured with IMAGES(BOTH) so Gluesync can
use before-images and after-images for accurate deltas, primary-key changes,
and target streaming. Standard mode invokes journal APIs through IBM Toolbox
for Java and follows journal receiver and sequence position. It does not rely
on DSPJRN or an RCVJRNE exit program for that path.
Architecture around Core Hub
Lightweight agents sit close to each system. Core Hub is the central orchestrator for the web UI, APIs, and routing between source and target agents. Pipelines group a source agent, target agent, and entities. Documented deployments include Docker, Docker Compose, and Kubernetes.
TARGETS AND TOPOLOGIES
Keep IBM i in the path while modernizing destinations
Use the integrations directory to pair IBM Db2 for IBM i (AS/400) as source or target with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams, subject to each agent’s documented source and target role.
- Offload reads from IBM i to another database or cache
- Feed a cloud warehouse or data lake continuously
- Publish database changes to an event-streaming platform
- Keep Db2 for i as a source, target, or both in a hybrid estate
Exact latency, throughput, and sizing depend on journal volume, reader mode, polling settings, and target capacity. Evaluate those conditions in a trial or with MOLO17 Professional Services.
FAIR, HIGH-LEVEL COMPARISON
Where Gluesync fits among IBM i CDC approaches
| Approach | What buyers usually get | Where Gluesync fits |
|---|---|---|
| DIY SQL / CL journal readers | Full control with high build and operations cost; naïve polling can overload IBM i | Productized Journal API reader, agent and Core Hub operations, heterogeneous targets |
| HVR-class commercial CDC | Mature replication portfolios; IBM i support varies by product generation | Native Journal API agent; read Gluesync vs HVR on IBM i |
| SQDR / Stelo / QMirror-class tools | Often strong for IBM i-centric replication estates | Heterogeneous CDC across RDBMS, NoSQL, lakes, and streams under one Core Hub |
| Generic Db2 CDC | May assume Db2 LUW APIs rather than IBM i journals | Dedicated IBM i Series (AS/400) agent and documentation |
| Syniti Replicate / DBMoto estates | Journal CDC heritage many teams already trust | Syniti to Gluesync migration hub |
RELATED CONTENT
IBM i CDC research and implementation detail
- Gluesync vs Fivetran HVR on IBM i
- IBM i (AS/400) real-time data replication with native CDC APIs
- IBM Db2 AS/400 CDC, system journaling, QSQJRN, RPG, and triggers
- Gluesync CDC for Db2 AS/400 and modern targets
- MYO IBM i and Couchbase Mobile case study
- Gluesync 2.2.4 IBM i API journal reading safeguards
- IBM i Series agent overview ↗
- IBM i journal data capture architecture ↗
FAQ
IBM i and AS400 CDC questions
What is IBM i / AS/400 CDC with Gluesync?
Change data capture from Db2 for IBM i by reading system journals through native Journal APIs, then delivering inserts, updates, and deletes to configured targets via Gluesync agents and Core Hub.
Is AS400 the same as IBM i here?
Yes for search and buyer language. IBM i is the current platform name; AS/400 and AS400 remain common terms. This page covers Db2 for IBM i journal-based replication with Gluesync.
Does Gluesync poll entire IBM i tables for CDC?
Supported IBM i source CDC uses journal APIs and journal receivers rather than repeatedly scanning full tables for change capture. Snapshots are available separately for initial loads.
Which IBM i versions are supported?
The IBM i agent supports Db2 for IBM i starting from version 7.1.
Can Gluesync write back to IBM i, not only read?
Yes. The agent supports both source and target roles for Db2 for IBM i.
What journal setting is required?
Journals must use IMAGES(BOTH) so before-images and after-images are available for correct CDC behavior.
Standard vs Dedicated journal reader mode: which should we use?
Standard mode is the default shared reader grouped by journal. Dedicated mode isolates a high-throughput path per entity without the shared cache. Check the journal architecture documentation for CPU and polling guidance.
How does this relate to Syniti Replicate end of support?
Teams running Syniti Replicate or DBMoto-style IBM i journal CDC can start from the Syniti to Gluesync hub, then use this page for IBM i product details and documentation.
Evaluate Gluesync with your IBM i journals
Start a trial on your infrastructure, or talk to MOLO17 about sources, targets, prerequisites, and sizing.