Skip to Main Content
IBM Data and AI Ideas Portal for Customers

This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Data & AI Roadmaps ( - Use this site to view roadmaps for Data & AI products.

IBM Employees should enter Ideas at

Status Future consideration
Created by Guest
Created on Sep 9, 2014

stop offloading queries to IDAA when incremental update is no longer updating a table

need to accelerate OLTP DBs for IDAA. As we keep telling that we can now merge both OLTP-Operational queries together on Z., this is something that is already in our way to resolve.

First thing they came up with was the fact that they need a way to load DB2 tables into an IDAA and start replication without putting the table in Lock mode (RO), so we came up with the solution in IDAA v4.1 PTF2 to allow CDC to conduct adaptive-apply (catch up with the log), and load the table in ROW mode to allow OLTP to continue updating the OLTP DB.
We can also resolve the issue of the delays in the update in the IDAA through the new stored procedure "WaitforReplication" function, so we get the same answer regardless of where the query gets served (DB2 or IDAA).

Having pictured all this in the above paragraph, the customer now wants to know what would happen in the event of a 'disconnection' between CDC (z/OS part) and IU (IDAA part). I guess we can resolve the issue on the CDC side by having CDC setup in a highly available configuration (multiple CDC standby tasks with DVIPA in a DB2 DSG), and TCPIP with VIPA,

I guess a possible error in IU portion of this puzzle would be a failure of the IDAA, where the customer would then have to have IDAA configured in a high availability configuration as well, having multiple IDAAs with the same table, being updated. Then, it would make sense to have 'that' table enabled for replication in IDAA #1 to go into disabled state while the surviving IDAA #2 copy of the same table stays enabled, so results don't vary between DB2 and the IDAA(s) version of the table. But like you say, the table will continue to be available for offload into the IDAA even though it has stopped getting updates from z/OS-CDC,,, that doesn't sound right to me !!..