Can infoConnect products be leveraged together?

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.

Do you offer POCs to customers?

Absolutely. Our service team is here to assist with product configuration and first use case implementation. We can also help define tables, perform full installation of the product in sandbox or non-production environments, and configure corresponding connectors to ensure everything works from the IBM i perspective.

How do your connectors work?

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.

How many transactions can your connectors handle?

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.

Does infoCDC require timestamps on the table?

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.

Does infoCDC have a limit on the number of tables you can capture?

The product supports multiple tables and 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.

How much CPU or memory is needed for the infoCDC to run on the IBM i?

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.

Let’s Build Your Modernization Roadmap Together

Contact us for a free strategy session with IBM i experts.

Talk to an IBM i Expert