IBM Support

Configuring and monitoring the incremental update process

Product documentation


This document describes methods to detect and avoid log reader outages and introduces the log cache as a means to recover quickly from a log reader outage.


The incremental update function of IBM DB2 Analytics Accelerator for z/OS is continuously reading the DB2 log. It is important that the log reader is not stopped for an extended period of time (for example, for more than one hour) because this increases the chance that the log reader cannot keep up with the number of incoming updates. The following consequences are likely to occur in such a situation:

  • Data latency problems
  • The log reader requires DB2 log data sets that are not available anymore or available on slower devices only (archive)

In both cases, the only solution is to fully reload the affected tables by running the SYSPROC.ACCEL_LOAD_TABLES stored procedure or the corresponding function in IBM DB2 Analytics Accelerator Studio.

This document describes methods to detect and avoid log reader outages and introduces the log cache as a means to narrow the latency gap in case of a log reader outage.

Verifying the CDC for DB2 z/OS Configuration

The incremental update function is based on the log reading component of Infosphere Change Data Capture (CDC). Configure the log reading component as described in the IBM DB2 Analytics Accelerator for z/OS: Installation Guide (see

The following configuration settings must be in place, otherwise, there is a risk of product malfunctioning.





   ONUTILITYACTION=IDLE,                      /* see note   */
   ONDECOMPRESSIONERROR=(300,IDLE),           /* see note 2 */
   ONSCHEMACHANGE=IDLE,                       /* see note 3 */
ONTABLEERROR=IDLE,                         /* see note 4 */
   REPLTEMPORALTABLES=DECOUPLE,               /* see note 5 */




Note: ONUTILITYACTION=IDLE will not work when you use the High Performance Storage Server (HPSS).
Temporarily set ONUTILITYACTION=IGNORE before archiving or restoring partitions - this requires a restart of the CDC capture agent. Or, permanently run the agent with ONUTILITYACTION=IGNORE and handle data changes not captured with the help of DB2 utilities on your own.

Note 2: ONDECOMPRESSIONERROR=(300,IDLE) was introduced in IBM DB2 Analytics Accelerator for z/OS V4.1.0 (CDC V10.2). It must not be used with IBM DB2 Analytics Accelerator for z/OS V3.1.0 (CDC V6.5).

Note 3: Use ONSCHEMACHANGE=IDLE if you have installed the fix for CDC APAR PI65350 (UI43865 or higher). If you run an earlier version, use ONSCHEMACHANGE=STOP. Schema changes (except ALTER TABLE and ADD COLUMN) for incrementally updated tables can put the CDC agent into a situation that it cannot restart until the table has been redefined for incremental updates. To avoid this situation, set ONSCHEMACHANGE=STOP. This causes the incremental update process to stop so that administrators can immediately take corrective actions before proceeding. If you have installed the fix for CDC APAR PI65350 (UI43865 or higher), this restriction is lifted and ONSCHEMACHANGE=IDLE is the recommended default.

Note 4: ONTABLEERROR=IDLE was introduced with IBM DB2 Analytics Accelerator for z/OS V4.1.0, maintenance level PTF-5 (it requires installation of the fix for CDC APAR PI26807, UI27018 or higher). It must not be used with earlier maintenance levels or versions.

Note 5: REPLTEMPORALTABLES = DECOUPLE was introduced with IBM DB2 Analytics Accelerator for z/OS V5.1.0 (it requires installation of the fix for CDC APAR PI49337, UI31507 or higher). It must not be used with earlier versions. Its use is mandatory in V5.1.0.

Attention: With this configuration, the CDC STC may allocate up to 2.2 GB (2GB staging space + 200 MB L1 cache) of z/OS storage resources (above the bar storage), which might be paged to auxiliary storage. Make sure that there are sufficient system resources for this configuration. The paging might reduce the incremental update throughput significantly.

Own message class for CDC spooled output

We recommend to define a MSGCLASS in JES that keeps the output for a minimum of 10 days across address space restarts. In the example, a MSGCLASS F is defined.

Refer to the MSGCLASS in the CDC startup JCL:


Configuring alerts for system state changes

In case a warning or error is reported by the accelerator hardware, IBM DB2 Analytics Accelerator for z/OS writes DSNX881I messages to the SYSLOG and the DB2 for z/OS MSTR address space. For details see It is strongly recommended that you capture such messages with the help of system automation software.

The DSNX881I message with ID 20 is related to the incremental update function. It includes situations in which the log reader was stopped due to an error.

If you want to be notified of log reader stops (including user-initiated stops triggered by a manual Stop Replication command), use the following configuration statement:



As a result, all messages dealing with user-initiated or error-driven stops of the log reader are written as CHC012xI messages to the SYSLOG.

Monitoring replication latency

If you want to be informed regularly of the current position of the log reader, you can use the following configuration:



This will cause a message to be written to CHCPRINT that informs about the log reader position every 5 minutes. For example:

2013/05/20 08:15:33 SDT IDAA0002   CHC0129I The latest scraped data was written at 2013-05-20- 2,066,793 changes were sent. The current Log Read Position is X'CB634BD828860001'

Current replication latency metrics can be retrieved using the <getAcceleratorInfo/> command of the ACCEL_CONTROL_ACCELERATOR stored procedure. Here is an example of the corresponding output XML:

<replicationInfo state="STARTED" lastStateChangeSince="2012-11-11T10:33:42.487678" latencyInSeconds="38">
<sourceAgent insertCount="5"   updateCount="100" deleteCount="3" />
<targetAgent insertCount="105" updateCount="0"   deleteCount="103" />

Implementing a log cache that covers one day of DB2 log activity

Implementing a log cache has two advantages, and is generally recommended for all installations of IBM DB2 Analytics Accelerator for z/OS starting with V4.1.0. If a log cache is in place, the log must not be read multiple times in case data is incrementally updated on more than one accelerator. In addition, a log cache significantly increases the ability of the log reader to catch up after an interruption of the incremental update process when IFI filtering is used.

Make the VSAM cluster for the log cache so large that it can hold approximately one day of DB2 log data. Note that there is currently a maximum of 4GB for the log cache size.

For information on how to create the VSAM cluster for the log cache by running the CHCCRCCH job, see:

Note: The log cache VSAM cluster for the VSAM cluster in CHCCRCCH must be shared by the active instances and the standby instances. Use SHAREOPTIONS(3 3). See the next section.

Apply maintenance to use IFI filtering

IFI filtering reduces the log processing work of CDC, and will automatically be used by IBM DB2 Analytics Accelerator for z/OS V4.1.0 on DB2 11 for z/OS.

On DB2 10 for z/OS, the fixes for the following APARs are required to enable IFI filtering for IBM DB2 Analytics Accelerator for z/OS V4.1.0: PM90568 (UK97013) for DB2 and PI08186 (UI13632) for CDC.

Implementing automatic fail-over (high availability) support for the Capture Agent

Use a high-availability setup for the CDC Capture Agent, so that task outages or LPAR outages do not lead to a standstill of the incremental update log reader process. How to implement a high-availability setup is described in the following document:

Original publication date


Cross reference information
Segment Product Component Platform Version Edition
Information Management InfoSphere Change Data Capture InfoSphere Change Data Capture for z/OS z/OS 6.5.2, 10.2, 11.3 All Editions

Product Alias/Synonym


Document information

More support for: DB2 Analytics Accelerator for z/OS

Software version: 4.1.0, 5.1.0

Operating system(s): z/OS

Software edition: All Editions

Reference #: 7039147

Modified date: 19 May 2017

Translate this page: