4. EXCEPTION REPORTING › 4.1 Philosophy and Requirements

4.1 Philosophy and Requirements

The technique of exception reporting has always had value for
data processing management.  The increase in growth and
complexity of data processing data centers, however, makes
exception reporting a necessity for even the smallest sites.

At z/OS data centers, the CPU processor or processor complex
operates many types of systems software -- for example, SCP,
TSO, JES2, batch, and TCAM.  Each of these must frequently
perform a significant level of processing.  This combination
of functions, and the processing of large and diverse
workloads, results in a complexity and workload that make
management control extremely difficult.  It is because of
this increased complexity and activity that an exception
reporting process should be used as a diagnostic filter.

The concept of exception reporting is analogous to an
automated medical system.  By processing the monitored
responses of a patient and matching them against previous
patterns of illness and certain definable thresholds for
blood pressure, blood counts, and other symptomatic
conditions, it is possible to diagnose the illness.

The exception reporting system described in this chapter
operates similarly.  By using data from available monitoring
sources (for example, RMF, CA TSO/MON PM, SMF) and comparing
this activity against user-defined thresholds, the reporting
process provides an integrated exception list that can help
diagnose the data center's potential problem areas.

CA MICS exception reporting reduces the number and frequency
of the reports that systems programmers, performance
analysts, security officers, and other people have to
interpret.  Furthermore, reporting the exceptions from all
the installed CA MICS products in an integrated manner
reduces the time spent tracking problems, resulting in
increasing the effectiveness of the systems and performance
teams.