Controlling data collectors

Data collectors

The z/OS data collectors are programs that extract system information from z/OS control blocks for use by both MainView for z/OS and CMF MONITOR.

At least one data collector exists for each aspect of system performance. For example, the PGDS collector collects only data associated with paging delays, while the ASEV and ASTM collectors focus on data related to address space activity.

Here is how the data collectors work:

1. At the beginning of every CMF Extractor interval, an interval record is created for each category of data to be collected. An interval record is what data collectors use to store the data collected during the Extractor interval.
2. Each category of data has its own uniquely named record: the LPAR collector stores its data in the LPRE record, the CPTH collector uses the CXRE record, and so on.
3. As soon as the interval begins, each collector collects its data from z/OS control blocks, from the CMF Extractor, and from other collectors.

4. Subsequently, each collector periodically collects its data. The times at which collectors gather data are determined by a preset rate called a sample rate (also called a collector rate). Each collector has its own associated sample rate.

   A sample rate is simply a multiple of the base cycle, which is preset by MainView for z/OS at a second. Therefore, if a collector’s sample rate is 15, the collector gathers its data once every 15 seconds.

5. The data collectors deposit the data in their records. Data for interval views is deposited in fields called interval counters; real-time data is placed in a delta counter. Each counter treats its data a little differently. If you are interested in these differences, see How the counters work.

6. At the end of the CMF Extractor interval, every interval record--one for each collector--is written to the historical database. Then a new set of interval records is created, and the process begins again.

   In general, the MainView for z/OS product terminates a recording interval at the frequency specified by your CMF Extractor REPORT control statement. However, Workload Management (WLM) resets its data when a service policy is activated by the system command

   VARY WLM,POLICY=

   MainView for z/OS then immediately terminates the current recording interval and starts a new interval.

How a view is created

It is important to understand how collected data relates to what you see on your screen.

When you request a view from CMF MONITOR, the following actions occur:

1. CMF MONITOR checks the view’s definition to determine the data that the view requires. For example, the CHANNEL view definition tells CMF MONITOR to get data from the CXRE record (which stores data gathered by the CPTH collector).
2. CMF MONITOR accesses the applicable record (in this example, the current CXRE record). Because CHANNEL is an interval view, CMF MONITOR takes the data from the CXRE interval counter.
3. CMF MONITOR formats the data according to the specifications in the view definition. This formatted data is now considered a complete view.
4. The view is displayed on your monitor.

How the counters work

Each interval record contains interval counters that are accumulated over a single interval.

For example, suppose a collector’s sample rate is 5 seconds and the interval is 15 minutes. At the beginning of the interval, the collector gathers its initial data. This data is written to the interval counter and is immediately reflected in the associated interval views. Five seconds later, additional data is gathered. The collector adds this new data to the initial data that was already in the interval data.

This process is repeated five seconds later and continues for 15 minutes (the end of the interval), at which point a new interval record is created with new interval data fields reset to zero. Views display interval data as average values over all of the samples accumulated during the interval.

How z/OS data collectors work with the Extractor

Both the z/OS data collectors and the CMF Extractor run in the MVS PAS.

Although the Extractor can be run separately from the data collectors (through the DC=STOP parameter), the opposite is not entirely true. Many collectors depend on data supplied by the Extractor.

The following table lists the CMF MONITOR data collectors that depend on data supplied by the Extractor and the required CMF Extractor sampler.

Data collector	CMF Extractor sampler
DEVX	DEVICE class="DASD" and DEVICE class="TAPE"
CPU	CPU
SPAG	PAGING
CACH	CACHE
PGDS	ASMDATA

If you are planning to use any views that fall into these categories, you must keep the Extractor active with the appropriate samplers.

Despite these dependencies, the z/OS data collectors and the Extractor are actually discrete entities that can be controlled separately, as shown in the following table.

To perform this action	Follow this procedure
Start or stop all of the z/OS data collectors at once	Specify the DC=START or DC=STOP parameter in the JCL used to initialize the MVS PAS. If the PAS is already active, issue MVS MODIFY DC=START or MVS MODIFY DC=STOP against the PAS.
Start or stop individual z/OS data collectors	Use the DCSTAT view as described in Controlling-z-OS-data-collectors.
Change the CMF Extractor samplers before PAS initialization	Specify a new control statement member suffix on the CPM or IPM parameter in the JCL used to initialize the MVS PAS.
Change the CMF Extractor samplers after PAS initialization	Use the MVS MODIFY CPM=xx or IPM=xx command against the PAS, where xx is the suffix of another CMF control statement member containing a different set of samplers.

These parameters are described in more detail in section of the Managing the z/OS product address space (PAS).

This section contains the following topics: