RMF and putting SMF to work

RMF measures system performance in three monitors: long-term recording, snapshots and near real-time delay analysis. Its Postprocessor turns SMF data into reports such as CPU Activity and Workload Activity, and SMF as a whole supports chargeback, capacity planning and audit.

Three monitors, three time scales

RMF (Resource Measurement Facility) is IBM's performance monitor for z/OS. It is a separately priced z/OS feature, and BMC and Broadcom offer alternatives; BMC's CMF MONITOR, for example, can produce RMF-compatible records, so reports look similar across sites.

Monitor	Time scale	Typical use
Monitor I	Long-term: intervals, often 15 minutes	Gathers data continuously and writes SMF types 70 to 78; the basis for history and capacity planning
Monitor II	Snapshot: now	Point-in-time views of address spaces and resources; can write type 79
Monitor III	Short-term: last minutes to hours	Delay analysis: what each job or service class is waiting for, viewed in an ISPF dialog or web interface

Monitor III is what you open during an incident. Reports such as SYSSUM (system summary against goals), DELAY (jobs and their main delays) and JOB (one job's delays) show whether work is waiting for processor, I/O, storage, enqueues or something else. Monitor I data is what you use the next day to understand the incident properly.

The Postprocessor

The RMF Postprocessor is a batch program that reads SMF records, usually from the daily dump, and produces reports for chosen intervals and systems. Control statements select reports: for example REPORTS(CPU) for CPU Activity and SYSRPTS(WLMGL(SCPER)) for Workload Activity by service class period. Output can be printed text or XML for viewing in a browser or z/OSMF.

From records to reports

Monitor Igathers samples

SMF 70-78recorded and dumped

Postprocessorselects intervals and reports

ReportsCPU, Workload, DASD, Paging

CPU Activity report

Shows how busy each processor was over the interval, separately for general processors and specialty engines such as zIIPs. Its Partition Data section shows every LPAR on the machine: its weight, how much it used, and capacity figures including the four-hour MSU average and any defined capacity, which link directly to software cost.

Workload Activity report

Organised by service class period and report class. For each it shows the goal, what was achieved (average response time or velocity), the performance index, transactions ended, and resource use such as CPU and zIIP service time and APPL% (the percentage of one processor the work used).

Workload Activity extract (illustrative, layout simplified)

SERVICE CLASS=CICSHI   PERIOD=1  IMPORTANCE=1
  GOAL: RESPONSE TIME 0.250 SEC FOR 90%
  ACTUAL: 94.1% WITHIN GOAL       PI: 0.8
  ENDED: 1,284,511   AVG RESP: 0.081 SEC
  APPL%  CP: 38.2   IIP: 4.6

Putting SMF to work

Use	Main records	What is produced
Chargeback	30, 101, 110, 116	CPU and I/O by account code, application or department, converted to cost
Capacity planning	70, 72, 74, 113	Peak and average usage trends per LPAR and workload, to forecast upgrades
Performance analysis	72, 74, 30, 101	Which workloads miss goals and why
Security audit	80, plus product records	Who accessed or tried to access protected resources
Software licensing	70, 89	Sub-capacity usage reports for IBM and other vendors

Chargeback depends on good accounting data. If jobs carry meaningless accounting fields on the JOB statement, or CICS work is not attributed to applications, the bill cannot be split fairly. Many sites charge back only for 'showback' (reporting cost without actually billing), which still drives better behaviour.

Three monitors, three time scales

The Postprocessor

CPU Activity report

Workload Activity report

Putting SMF to work

Common mistakes

What you will see at work

Key terms