Skip to main content

Leveraging SMF Data With (or Without) REXX

A review of Systems Management Facilities concepts and terminology; how to process SMF records using REXX.

Technological blueprint design in teal with blue lines.

Editor’s note: This article is the first in a series exploring how to process Systems Management Facilities (SMF) data using the REXX programming language.

SMF is IBM’s data-collection facility for accounting and performance data on z/OS. Different SMF records are created for all functions within the z/OS system and its related subsystems. The information within each SMF record is extensive, and covers most aspects of task and system functions.

Several programs use SMF data, such as the IBM z/OS Resource Measurement Facility (RMF) component, SAS and MXG. Although these programs provide the functionality to eliminate much of the need to write programs to process SMF data, they have their limitations and as such there are times when programming is preferable.

This series on using REXX to process SMF data, will touch on the following topics:

  1. An introduction to SMF terminology and data structures
  2. REXX building blocks
  3. More on the SMF record structure
  4. How to process commonly used SMF record types

This first installment reviews a few SMF concepts and terminology to lay the groundwork before delving in to how to process SMF records using REXX.

Standard SMF Record Header

The z/OS system collects statistical data for each task when certain events occur in the life of the task. SMF formats the information that it gathers into system-related (or job-related) records. System-related SMF records can include information about the configuration, paging activity and workload. Job-related records include information on the CPU time, SYSOUT activity, and data set activity of each job step, job, APPC/MVS transaction program and TSO/E session. SMF data is written to the SYS1.MANx data sets.

Each record written to the data set by the SMF writer routine contains the standard SMF record header. It contains information about the record, such as type, subtype (if the record includes subtypes), length, and the time and date the record was written to the data set.

Record subtypes are used to group related data and control record types. For example, one record might contain three separate subtypes, each reporting different kinds of data. By using those subtypes you can eliminate the need for three separate record numbers.

Each SMF record is assigned a record type where types 00-127 are reserved for IBM products and types 128-255 are available for user records. The SMF record header can be either 18 bytes (if no record subtype exists) or 24 bytes (if one does exist).

Looking closer at the SMF record header, Figure 1 shows the format of the 24-byte header per the SMF documentation (SA22-7630).

Feb13mfex2art1FIG1.jpegFigure 1

From a graphic data structure perspective, the SMF record header would look like Figure 1A.

Figure 1A

The fields in Figure 1A represent a standard header present in all SMF records. The remainder of the record is interpreted according to the record type SMFxRTY.

Viewing SMF Records

You might occasionally find it necessary to view the SMF records that are produced. Printed SMF records are useful, for example, when designing and implementing a user-written record-processing program or when diagnosing problems with RMF reports. There are two ways to print the records:

  • The RMF utility program ERBSCAN running under Interactive System Productivity Facility (ISPF), which can format all SMF/RMF records in record-type-specific sections
  • The standard utility program IDCAMS, which can print all SMF records in dump format


ERBSCAN is a utility that when issued against an SMF dataset, presents a list of SMF records and some very high level information gleaned from the record header. This includes the date and time the record was cut, the SMF ID and the record type and subtype. Figure 2 shows a typical ERBSCAN display.

Feb13mfex2art1FIG2.jpegFigure 2


Among its many functions, the data set utility, IDCAMS, can also be used to view SMF records using the following JCL fragment:

//PRINT     EXEC  PGM=IDCAMS            
//SYSPRINT  DD    SYSOUT=A              
//SYSIN     DD    *                     
  PRINT INFILE(RMFREC)                

Because you don’t specify the format on the PRINT statement, the format defaults to DUMP. The records are printed in a dump format. Figure 4 is an example of the SMF record dump format output.

Feb13mfex2art1FIG4.jpegFigure 4

The offsets are shown in the leftmost column of Figure 4, and the right side of the dump contains a printable section to help find fields of interest. Note that the PRINT utility doesn’t include the record length and segment descriptor fields in its output. As a result, a field shown at offset 4 in an SMF record per the defined SMF record header (see Figure 1) would appear at offset 0 in the IDCAMS formatted dump.

Being cognizant of adjusting the offsets accordingly, so as to refer back and forth from the formatted dump to the SMF offset definitions in the SMF documentation, brings us one step closer to a programmatic solution.

Mapping the IDCAMS Dump Output

While the dump output shown in Figure 4 is "readable" to some extent, in and of itself, it's still in dump format that contains hexadecimal characters, which are seemingly indecipherable without some sort of structural context. That structural context is provided by the defined record format as shown in Figure 1 (and the SMF documentation).

A quick walkthrough of a single record in the IDCAMS dump output will help you tie together the concepts discussed here and understand how the dump output maps to the defined SMF record formats. Specifically, let’s look at the first 20 bytes in the second record shown in Figure 4:

Recall that because the PRINT utility doesn’t include the record length and segment descriptor fields in its output, what appears at offset 0 in the IDCAMS formatted dump is actually defined at offset 4 per the defined SMF record header. These first 20 bytes are broken down as follows in Figure 5.

Feb13mfex2art1FIG5.jpegFigure 5

Each field needs to be translated according to its format (e.g. binary, packed, EBCDIC, etc.) and the question marks in Figure 5 represent the values that we need to translate.

Figure 6 summarizes how the first 20 bytes of the IDCAMS formatted dump output map to the SMF record header format, and how their respective dump values are translated.

Feb13mfex2art1FIG6.jpegFigure 6

Note that the translated values match the information shown in the ERBSCAN display example in Figure 3.

Figure 3

Moving Beyond Manual

The first part of this series is designed to increase your understanding of the SMF record header and the various, manual ways to view individual SMF records. Using the IDCAMS formatted dump output you can map the hexadecimal data to the SMF record header. Likewise, there are a few techniques for translating the header fields into a more human-understandable format.

Now that you’ve seen the tedious manner in which SMF records can be analyzed, part two will examine some REXX building blocks you can use to build your own tooling.

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →