4. EXCEPTIONS › 4.1 Introduction To Exception Reporting
4.1 Introduction To Exception Reporting
The Exception Reporting process uses available monitoring
sources (for example, RMF, SMF, CA TSO/MON PM) to compare an
activity level against predefined thresholds and to provide
an integrated exception list of potential problem areas.
Figure 4-1 illustrates the operation of the exception reports
process. The database, Exception Test Routines, Standard
Exception Reports, and the Online Exception Inquiry are
standard parts of this process. User-defined values allow
you to tailor and modify the exceptions in order to uniquely
address your data center's requirements.
+-----------+
| |
| Database |
| |
+-----------+
|
|
+-----------+
| User- |
| Defined |
| Exception |
| Analyzer |
+-----------+
|
+-----------+
| Database |
| Exception |
| File |
+-----------+
|
+-----------------------+
| |
+-----------+ +-----------+
| Standard | | MICF |
| Exception | | Exception |
| Reports | | Inquiry |
+-----------+ +-----------+
Figure 4-1. Exception Reporting Operational Flow
On a daily basis, the appropriate files contained in the
database are processed to detect the defined exception
conditions. The Exception Analyzer performs this task by
using individual test routines to identify the exceptions.
Each test routine requires the necessary user-defined values
that tailor the exception test to your data center's
requirements.
An exception test completely defines the tests made to
determine the exception condition and the definitions that
define and classify the exception for reporting. You can
asily modify values or, in some cases, even add values to
adjust the exception criteria to better meet your data
center's requirements.
These tests are called Exception Test Routines, and they are
stored in the source library prefix.MICS.USER.SOURCE in the
member DYxxxEXC, where xxx represents the applicable
Information Area, such as DB2 for the DB2 Analyzer. An
exception group exists for each unique file that is to be
processed by the Exception Analyzer, and it consists of the
exceptions that are to be processed by using a specific
file.
Figure 4-2 lists the range of DB2 Analyzer Exception Numbers
that can be defined for each data group and file. The
exception code is organized sequentially by exception number
within the DYDB2EXC member, and it consists of standard
identification definitions (for example, severity level),
exception-dependent criteria (for example, amount of CPU time
used), or standard selection facilities (for example,
selection of prime-time hours only).
The exception to be modified may be located easily, since its
name and number delineate the beginning of its definition.
The value to be modified can then be located and changed
directly within the SAS code.
+----------------+-------------------------------------+
| Member Name | Descriptive Title |
+----------------+-------------------------------------+
| DYDB2EXC | Standard DB2 Exceptions |
+----------------+-------------------------------------+
| Exception | Database File Name |
| Number Range | |
+----------------+-------------------------------------+
| 10000-10049 | DETAIL.DB2DSY01 |
| 10050-10094 | DETAIL.DB2DSD01 |
| 10095-10106 | DETAIL.DB2DSY01 |
+----------------+-------------------------------------+
Figure 4-2. DB2 Exception Number Definition Table
