topic Re: DB2 z/OS REORG DISCARD (IFCID 306 / Utility Subtype 83) – CDC Gap Handling in Qlik Replicate in Qlik Replicate

DB2 z/OS REORG DISCARD (IFCID 306 / Utility Subtype 83) – CDC Gap Handling in Qlik Replicate

shyamkatika — Thu, 09 Apr 2026 06:47:46 GMT

We are using Qlik Replicate with IBM Db2 for z/OS as the source, and we encountered the following informational message in the task logs:

DB2z utility (subtype 83) variation 5 (REORG DISCARD) at LSN '00E27D35291AA89C8000'
was detected for table 'AAAAA'.'BBBBBBBB'.
The operation is ignored based on the endpoint configuration.

Is there any way to capture or handle REORG DISCARD deletes in Qlik Replicate?
Can Advanced Resume using LSN help in recovering these missing deletes?
Are there any endpoint configurations or parameters that can help process such utility operations?
What are the recommended best practices to handle this scenario in a PROD environment?

We are looking for guidance or suggestions from the community on:

Handling REORG DISCARD scenarios
Minimizing data inconsistencies between source and target
Any proven approaches used in similar setups

Thanks in advance for your support!

Re: DB2 z/OS REORG DISCARD (IFCID 306 / Utility Subtype 83) – CDC Gap Handling in Qlik Replicate

stuart012broad — Fri, 10 Apr 2026 03:56:51 GMT

Hello, They can’t be captured or recovered using Advanced Resume/LSN. There aren’t endpoint settings to process them directly. MyLoanCare com

Re: DB2 z/OS REORG DISCARD (IFCID 306 / Utility Subtype 83) – CDC Gap Handling in Qlik Replicate

shyamkatika — Thu, 09 Apr 2026 09:47:16 GMT

Hi @stuart012broad

Thanks for the clarification. We also observed the same behavior in our environment using Qlik Replicate with IBM Db2 for z/OS — that REORG DISCARD operations cannot be captured or recovered using Advanced Resume (LSN), as there are no row-level DELETE records generated in the logs.

For other utilities (for example, LOAD RESUME), we understand that certain approaches like:

Using Load Resume Process is Running utilities with SHARELEVEL CHANGE can help ensure CDC continuity and avoid data gaps.

In a similar context for REORG DISCARD: Do we have any equivalent workaround or utility-level strategy that can help avoid CDC gaps?

For example: Can REORG be executed with specific options (similar to SHARELEVEL CHANGE) to make changes visible to CDC?

Is there any way to capture discarded rows externally (e.g., DISCARD dataset) and integrate with Replicate?

Are there any best practices from Qlik or Db2 side to handle this scenario without requiring full table reload?

Re: DB2 z/OS REORG DISCARD (IFCID 306 / Utility Subtype 83) – CDC Gap Handling in Qlik Replicate

Mohammed_Messaoudi — Thu, 09 Apr 2026 12:19:08 GMT

Hello,

Unfortunately, Qlik Replicate cannot capture REORG DISCARD deletes. This is a known limitation documented in Qlik's Db2 z/OS source guide: Subtype 83 REORG DISCARD operations are not captured and are ignored by default based on endpoint configuration. The log message confirms Replicate detected but skipped it.
A warning message will be generated, with the following text (example):
DB2z utility (subtype 83) variation 5 (REORG DISCARD) at LSN=0000000000123abc0000

https://help.qlik.com/en-US/replicate/November2025/Content/Global_Common/Content/SharedReplicateHDD…