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 !!..