Connect Your IBM i to Anything

Yes; that is the way our product suite was designed. When bundled together, they are highly complementary and supported by our in-house team members. Several customers leverage our connectors in conjunction with our CDC component for real-time, bi-directional integration capabilities.

Absolutely. Our service team is here to assist with product configuration and first use case implementation, and can also assist with defining tables, full installation of prod in sandbox/non-prod, and as well as corresponding connector configurations to ensure everything works from the IBM i perspective.

Compatible with both RPG and COBOL, our connectors use native IBM i libraries and low-level socket integration (cloud or on-premise) to call backend programs directly.

Many of our customers deal with large peak volumes and process hundreds or thousands of transactions per second leveraging our connector. The throughput of the product depends on several factors including (but not limited to) application design, connection speed between your platform and IBM i (AS/400) servers, and the number of connections in the connection pool.

Each OS update released by IBM is tested internally by our product engineering team to ensure compatibility. As of today, our connectors are compatible with IBM i OS 5.4 and higher.

Time stamps are not required, as the product does not poll periodically based on time stamps. infoCDC connects directly into DB2 journals, almost like how Kafka persistently logs data and events: whenever a change happens, one or more entries are pushed into a journal that is immediately made available for a process on our end.

The product supports multiple tables and multiple journals. infoCDC has one listener job per journal, with multiple tables that could be configured per journal and processed by a single job, making it rather lightweight and easy on the system. Generally, there’s no hard limit on the number of tables or journals that it can process simultaneously.

Overall, implementation will have minimal impact on IBM i system performance. Listening is handled by a specific job for each journal on IBM i, as opposed to a trigger-based solution. This approach is very lightweight, using filtering criteria to determine relevant events before sending them to a data queue for delivery to external systems.

In summary, performance and results largely depend on the combined configuration of system components, jobs, and processes within the environment.

No! You can implement our products on any number of environments, with no restriction on the number of logical partitions.