Db2 utility detection

InfoSphere® CDC for z/OS® can detect the action of a Db2® utility (such as LOAD or RECOVER) on a table space containing source tables being mirrored. The Db2 Utility Detection feature will recognize when a utility action occurs that could result in source tables and target tables being out of sync. Db2 Utility Detection provides configurable options for automated resynchronization.

When a utility’s desynchronizing action is detected, the action of InfoSphere CDC for z/OS is determined by the value set in the ONUTILITYACTION keyword. The following list describes the possible actions:

• STOP—Ends the mirroring subscription in a controlled manner at the point in the Db2 log where the utility’s action occurred. You should resynchronize the affected source and target tables either by performing a refresh or taking action outside of InfoSphere CDC for z/OS before replication can continue for the subscription.
• REFRESH—Suspends the mirroring subscription, flags the affected tables for Refresh and resumes the subscription. The subscription will then refresh the flagged tables before it resumes mirroring.
• DFFRFRSH—Suspends the mirroring subscription, flags the affected tables for a Differential Refresh and resumes the subscription. The subscription will then refresh the flagged tables before it resumes mirroring.
• IDLE—Suspends the mirroring subscription, marks the affected tables as inactive and resumes the subscription if not all the tables have been marked Inactive. If all the tables have been marked Inactive then it ends the mirroring subscription in a controlled manner at the point in the Db2 log where the utility’s action occurred. You should resynchronize the affected source and target tables either by performing a refresh or taking action outside of InfoSphere CDC for z/OS before replication can continue for the subscription.
• IGNORE—Mirroring of the affected subscription is not affected; no action is taken other than issuing a notification message.
• CONSREQ—Suspends the mirroring subscription and issues a message to the z/OS console operator. The message will include the subscription name, the table name, the table space name, the type of action performed by the utility and the time at which it occurred. It will then request a reply specifying one of the above actions. When the z/OS console operator responds to the message request, the action they specified will take place as described previously.
• USEREXIT—Suspends the mirroring subscription and calls a user exit, if one was supplied. The user exit receives the subscription name, the table name, the table space name, the type of action performed by the utility and the time at which it occurred. The user exit sets a returned value specifying one of the above actions. When control is returned from the user exit, the action specified will take place as described previously. For a description of how to code and prepare the user exit that is driven when this keyword value is specified, see The Db2 Utility Detection user exit.

Note the following considerations before using Db2 Utility Detection:

• The Db2 utility detection feature is for use with IBM® Db2 utilities only. Third-party Db2 utilities are not supported.
• The value chosen using the ONUTILITYACTION keyword will be applied to all subscriptions. You cannot determine actions for specific subscriptions or tables unless you do so on a per instance basis using the CONSREQ or USEREXIT values of ONUTILITYACTION.
• Issuing the SETLOGPOS command when the ONUTILITYACTION keyword is configured to a value other than IGNORE could result in InfoSphere CDC for z/OS responding to an action taken by a utility more than once, or bypass responding for a section of the Db2 Log that has not been scraped.
• Some utilities that perform a desynchronizing action can be run with LOG YES specified. The LOG YES option does not provide logged data that will permit InfoSphere CDC for z/OS to avoid performing refreshes to resynchronize the source and target tables.
• Setting a table Idle in a subscription, then setting it active after a utility has been run will cause Db2 Utility Detection to miss the action of the utility for that table for the section of the Db2 Log that was not scraped