Potential considerations of ownership and support to Ignore the DB2 re-org(refresh) at table/subscription level

We are facing severe latency issue ( goes up to 3 hours ) in production.

Source - mainframe DB2 ( cdc agent installed db2 for zOS)

Target : Kafka

We have two subscriptions, one is having only cdc/mirroring and other having refresh +mirroring. Whenever refresh is going on for 2nd subscription then 1st subscription is also showing the latency.

We are looking to ignore the re-org/REFRESH at subscription level ( here for 2nd subscription. We don’t want CDC to pick any REFRESH, which triggers via re-org (ignore at subscription level).

We came to know from IBM(Robert Philo) that

The action to take in response to a DB2 utility is defined at agent level according to the ONUTILITYACTION parameter, not subscription level as documented at https://www.ibm.com/docs/en/idr/11.4.0?topic=db2-onutilityaction

But the problem with above is that
it will mean all tables if a destructive utility is used will not be refreshed or resynced and so data will differ between source and target for every table. If we run a recovery and have to backout some application issues then no refresh. If we run adhoc reorg with discards or load resumes for key tables the data will not flow to kafka. All tables and all subscriptions.

The option of refresh for utilities should be defined by the product and should be defined at the table or at the very least the subscription. Providing the REFRESH Option for the whole product and an exit to control the use is very old fashioned and not good practise. I would suggest IBM create a PTF to allow more customer options that just at the product level.

Therefore NatWest would strongly advised IBM to go for potential considerations of ownership and support of this cdc product.