Exception conditions overview

DASD MANAGER PLUS provides a robust set of statistics and conditions for monitoring DB2 objects. The exceptions define conditions that are related to typical DB2 utility needs such as collecting statistics, making image copies, and performing data reorganization.

You should review the exceptions that BMCTRIG monitors to determine which exceptions to check against threshold values, either for reporting or for automating corrective actions. After reviewing the exceptions that BMC Software provides, determine whether there are other site-specific conditions that you want to monitor. To create your own exceptions (called user-defined exceptions), you need to provide REXX routines to perform the evaluation and define your exceptions for DASD MANAGER PLUS. For more information, see Creating-user-defined-exceptions .

For the exceptions that you decide to monitor, you also need to provide threshold values that indicate when a problem occurs. BMC Software supplies recommended thresholds, but you can set the thresholds to values that are appropriate for your environment.

You can specify exception conditions as follows:

• Exceptions without system triggers (with the command syntax)

  If you do not use system triggers, you must define exceptions in the BMCTRIG command syntax. Use the Override System Trigger Exceptions options on the BMCTRIG service syntax dialog to define these exceptions (and specify System Triggers N, which is the default value). BMCTRIG uses these thresholds to analyze all objects that this BMCTRIG job processes.

• System-level triggers (without command syntax overrides)

  To use system-level triggers, select Thresholds, Corrective Actions, and Priorities from the DASD MANAGER PLUS Main Menu. System-level triggers allow you to set different threshold values for different objects in your subsystem. For example, each application might have a different tolerance level.

• Command syntax with system-level triggers

  If you do not set the SYSTRIGS installation option to F (that is, FORCE), you can specify thresholds in your command syntax in addition to the system-level thresholds. To specify thresholds in the command syntax, use the BMCTRIG Override Thresholds product panels.

  Thresholds that you specify in the command syntax override corresponding thresholds that are specified in the repository. Also, you can use override thresholds to specify thresholds for exceptions that are not defined in the system triggers repository. When you override a system threshold, BMCTRIG ignores the priority values that are defined in the repository for that threshold.

Threshold priorities

When you set different thresholds for different objects in your subsystem, you can assign a priority (0–255) to a threshold to indicate the severity of the condition.

BMCTRIG uses priorities to order work and to limit generation of corrective action work. The following example shows a possible way of defining exceptions, thresholds, and priorities:

In this example, an object with 55 extents receives an exception with a priority of 50. An object with 80 extents receives an exception with a priority of 100. BMCTRIG considers these priorities when determining which objects to process first in the generated jobs. Prioritizing ensures that BMCTRIG addresses the most severe conditions first when executing the generated jobs.

BMCTRIG allows you to define thresholds at a subsystem level based on object names, patterns, or sets. BMCTRIG also allows you to define thresholds in the syntax. Defining thresholds at the subsystem level gives a central point to administer exception handling. If you decide to administer thresholds at the subsystem level, you can also decide whether to allow threshold overrides in the command syntax.

For information about how to define your own exceptions or define thresholds at the subsystem level, see Setting-exception-thresholds.

Corrective actions for exceptions

After you determine which exceptions to monitor, you need to define the corrective actions that address the problems that BMCTRIG identifies.

Typically, you define a corrective action for each category of exceptions that you want to monitor. For example, you can create a corrective action that runs a BMCSTATS service when the product encounters a NOSTATS exception, or an action that generates a AMICOPY service if the product encounters the DIRTY exception.

However, if you are defining thresholds and corrective actions at the subsystem level, you set the appropriate corrective action for each exception that you monitor. Additionally, you can determine whether to use different corrective actions for different sets of objects. BMC Software supplies a set of initial corrective actions that you can use, or you can set up your own actions to meet your particular needs.

If you are using subsystem-level thresholds and corrective actions, you can establish priorities for objects when a particular corrective action occurs. The priority on the object-action occurrence takes precedence over the threshold priority, which allows you to establish work priority for a combination of objects and actions. For example, critical objects that need a reorganization might have a high priority while test objects that need a reorganization might have a low priority. BMCTRIG orders the corrective action work by priority and optionally limits work generation by priority.

For information about creating and editing actions, see Maintaining-and-generating-Service-Actions. For information about linking corrective actions to exceptions, see Managing-corrective-actions.