Db2 unavailability

When Db2® for z/OS® is stopped and becomes unavailable to applications, the response by InfoSphere® CDC for z/OS depends on the mode of the stoppage and on the status of current replication processing.

Db2 can be stopped at any time by an operator. The severity of the Db2 stop can be specified using the MODE keyword on the STOP command. Currently the following modes are available:

  • QUIESCE – The default. Allows currently executing programs to complete processing. No new program is allowed to start.
  • FORCE - Terminates currently executing programs, including utilities. No new program is allowed to start. This mode probably causes in-doubt situations.

Db2 might also abnormally terminate because of an internal error or an error in an external subsystem upon which Db2 depends.

All of these conditions of Db2 being stopped or abnormally terminating are referred to here as Db2 “becoming unavailable.” When Db2 is restarted, it is referred to as “becoming available.”

Db2 provides an interface for major applications that connect to it. The interface supports status when Db2 is not available, notification when Db2 becomes unavailable, and notification when Db2 becomes available again. InfoSphere CDC for z/OS uses this interface.

When Db2 availability changes, InfoSphere CDC for z/OS issues messages to the SYSLOG, the CHCPRINT SPOOL data set, and to the product administration log (viewable using the Management Console). Messages are sent if Db2 is not available, when Db2 becomes unavailable, and when it becomes available again.

InfoSphere CDC for z/OS starts even if Db2 is not available, although it cannot operate productively. InfoSphere CDC for z/OS waits for Db2 to become available so that it can become productive.

If Db2 becomes unavailable while InfoSphere CDC for z/OS is connected to it, InfoSphere CDC for z/OS does not shut down. If both Db2 and InfoSphere CDC for z/OS need to be brought down, then an explicit STOP or SHUTDOWN command must be issued to InfoSphere CDC for z/OS to bring it down as well.

If Db2 becomes unavailable while InfoSphere CDC for z/OS is connected to it, InfoSphere CDC for z/OS is able to determine the severity of the Db2 change of status and responds differently depending on the stop mode:

MODE(QUIESCE)
A MODE(QUIESCE) termination of Db2 affects subscriptions differently, depending on what they are doing:
  • A source-side subscription that is refreshing one or more tables continues with the refreshing of the current table until it is complete. It then ends without selecting the next table to refresh.
  • A source-side subscription that is mirroring does not request any more log data from Db2. It transmits any completed URs to the target, then ends.
  • A target-side subscription continues to apply changes until it receives or generates a COMMIT. It then issues the COMMIT, disconnects from Db2, and suspends execution. The target-side subscription does not end.

When Db2 is stopping with MODE(QUIESCE), it waits for applications to terminate their connections to Db2 before it completes the stop process. It is possible for InfoSphere CDC for z/OS to delay the stopping of Db2 if MODE(QUIESCE) was requested and a subscription is refreshing a large table, or if there is a large volume of data being mirrored that has been collected into completed URs but has not yet been delivered to the target. Additionally, poor performance at the subscription target can produce delays at the subscription source that can delay the stopping of Db2 when MODE(QUIESCE) is specified.

MODE(FORCE)
A MODE(FORCE) termination and an abnormal termination of Db2 are treated identically by InfoSphere CDC for z/OS. Source-side subscriptions are ended abruptly and target-side subscriptions are suspended.

If Db2 becomes unavailable while InfoSphere CDC for z/OS is connected to it and then becomes available again, InfoSphere CDC for z/OS resumes as much subscription work as it can. Subscriptions that were running when Db2 became unavailable can be reinstated under certain conditions:

  • Source-side subscriptions that have been marked Persistent will be restarted when the connection to Db2 is resumed. Source-side subscriptions that are not marked Persistent must be restarted manually.
  • Target-side subscriptions will have been suspended when DB2® became unavailable, and were not ended. At the source-sides of the target-side subscriptions, the subscriptions continue to run but appear to be stalled. When Db2 is available again, all target-side subscriptions resume replication where they were interrupted.