A batch job ran overnight and consumed three times its usual CPU. A CICS transaction that normally completes in 12 milliseconds is suddenly taking 200. A user account was used to access a sensitive dataset at 3am. A DB2 tablespace is approaching its storage limit.
None of these events sent an alert. Nobody was watching at the time. But every one of them left a record. Because on z/OS, almost everything that happens is written down.
That writing-down mechanism is SMF: the System Management Facility. It is z/OS's built-in telemetry system, collecting structured records of system activity, application performance, security events, and resource consumption continuously, from IPL until shutdown. The records SMF produces are the raw material for chargeback, capacity planning, performance analysis, security audit, and compliance reporting on every mainframe installation in the world.
This post assumes you have read Architecture: Mainframe. It covers what SMF is, how records are structured, which record types matter most in practice, how records are collected and processed, and where SMF fits in the broader z/OS observability picture.
What SMF Is
SMF is a z/OS component that provides a standardized mechanism for writing structured records of system events to a set of dedicated datasets. It is not a monitoring tool in itself: it is the collection layer. The monitoring, analysis, and reporting happen downstream, using tools that read and interpret the SMF records SMF has collected.
Every major z/OS subsystem writes SMF records: z/OS itself writes job accounting, dataset access, and system events. RACF writes security events. CICS writes transaction performance data. DB2 writes accounting and statistics data. RMF writes resource utilization data. z/OS Connect writes API invocation data. Each subsystem has one or more assigned record type numbers. A busy production mainframe may write millions of SMF records per day.
SMF has two complementary modes of record generation. Event-driven records are written when something happens: a job starts, a dataset is opened, a user logs on, a transaction completes. Interval records are written on a schedule: every 15 or 30 minutes, RMF writes a snapshot of CPU utilization, paging rates, and I/O activity, regardless of whether anything notable has occurred.
The SMF Record Structure
Every SMF record, regardless of type, has the same standard header. The header is a fixed-format binary structure whose fields are documented in the IBM manual z/OS MVS System Management Facilities (SMF). Understanding the header is the entry point to reading any SMF record.
The header contains:
- Record length: the total length of the record in bytes, including the header.
- Record type: a number from 0 to 255 identifying what kind of event this record describes. Type 30 is job/step accounting. Type 80 is RACF security. Type 110 is CICS performance.
- Record subtype: many record types use subtypes to distinguish between different events within the same category. Type 30 subtype 1 is job initiation. Subtype 2 is step initiation. Subtype 4 is step termination. Subtype 5 is job termination.
- Time: the time the record was written, in binary hundredths of a second since midnight.
- Date: the date the record was written, in packed decimal Julian format (YYDDD).
- System ID: the four-character name of the LPAR that wrote the record.
- Subsystem ID: the four-character name of the subsystem that generated the record (e.g. `JES2`, `DB2P`, `CICS`).
After the header, each record type has its own product section: the fields specific to that event. These sections are documented in the relevant subsystem's programming reference manual. A CICS type 110 record has sections for transaction identification, CPU time, elapsed time, file I/O counts, DB2 calls, and storage usage. A RACF type 80 record has sections for the user ID, the resource being accessed, the access level requested, and whether the access was permitted or denied.
The Key Record Types
There are over 200 defined SMF record types. Most installations use a subset. The ones that matter for the topics covered in this series are:
Type 14 and 15: Dataset Access
Type 14 is written when a dataset is opened for input (read). Type 15 is written when a dataset is opened for output (write or update). These records capture the dataset name, the job or address space that opened it, and whether the open succeeded or was rejected by RACF. They are the primary data source for dataset access auditing: which programs read which sensitive files, and when.
In high-volume CICS environments, types 14 and 15 can generate enormous volumes of records because CICS opens its VSAM files at region startup and holds them open. Many shops suppress types 14 and 15 for CICS started tasks to avoid the volume, using RACF type 80 records for file access auditing instead.
Type 30: Job and Step Accounting
Type 30 is the most widely used SMF record type. It captures resource consumption for every batch job, started task, and TSO session. Subtypes cover the full job lifecycle: subtype 1 at job initiation, subtype 2 at step initiation, subtype 4 at step termination (with resource consumption for that step), and subtype 5 at job termination (with totals for the entire job).
A type 30 subtype 4 record includes: job name, step name, program name, elapsed time, CPU time consumed on general CPs, CPU time consumed on zIIPs, DASD I/O count (EXCP count), peak storage in use, the return code, and the JES job ID. This is the data that feeds chargeback systems (billing internal departments for mainframe usage), capacity planning (identifying which jobs consume the most CPU), and performance management (trending job elapsed times over weeks and months).
Type 70-79: RMF Resource Utilization
Types 70-79 are written by the Resource Measurement Facility (RMF) at configured intervals, typically every 15 to 30 minutes. Each subtype covers a different resource domain:
- Type 70: CPU activity. Processor utilization by logical CPU, by LPAR, and by workload. The primary data source for CPU capacity planning.
- Type 71: Paging and swapping activity.
- Type 72: Workload Manager performance data. Goal achievement rates, service class response times, and transaction rates. Essential for validating that WLM goals are being met.
- Type 74: DASD device activity. I/O rates, response times, and utilization by device. The primary source for storage performance analysis.
- Type 78: Virtual storage utilization. Real storage frames in use, paging rates, buffer pool utilization.
RMF records feed the RMF postprocessor, which produces formatted reports. They also feed third-party performance management tools like IBM OMEGAMON, BMC MAINVIEW, and Broadcom IntelliMagic, which provide real-time dashboards and long-term trend analysis.
Type 80: RACF Security Events
Type 80 is written by RACF for every security-relevant event. It covers successful and failed logins, resource access checks (permitted and denied), profile changes, user attribute changes, and operator commands that affect security. It is the primary audit trail for mainframe security compliance.
The type 80 record is structured into sections that describe the event in detail: the initiating user ID, the terminal or address space, the resource class and resource name, the requested access level, the decision (permitted or denied), and any relevant profile information. Security auditors and SIEM tools consume type 80 records to detect anomalies: a user accessing resources at unusual hours, a burst of failed login attempts, or a program opening a sensitive dataset it has not accessed before.
RACF auditing is controlled at the profile level: each RACF resource profile specifies what to audit (successes, failures, or both) for accesses to that resource. A production environment typically audits all failures system-wide and selects successes for sensitive data classes.
Type 100-102: DB2 Accounting and Statistics
Type 100 records DB2 accounting data: per-thread resource consumption, SQL call counts, CPU time, elapsed time, lock waits, and buffer pool reads. It is written when a DB2 thread terminates. Type 102 records DB2 statistics at configured intervals: buffer pool hit rates, log write rates, and lock suspension rates. Together they are the primary source for DB2 performance tuning and capacity planning.
Type 110: CICS Performance and Statistics
Type 110 is the CICS record type. It has multiple subtypes covering different aspects of CICS operation. The most important for performance analysis is subtype 1: the performance class record, written at the end of every CICS transaction. It contains:
- Transaction ID and program name.
- User ID of the executing user.
- Elapsed time from task creation to task termination.
- CPU time consumed by the task.
- VSAM file I/O counts: reads, writes, rewrites, deletes, browses.
- DB2 call counts and wait time.
- MQ call counts.
- Peak storage in use.
- Suspend time: how long the task spent waiting for resources.
- Terminal or connection ID.
Subtype 2 is the statistics record, written at CICS shutdown or at the statistics interval. It captures aggregate counts for the region: total transactions processed, total CPU time, DSA utilization high-water marks, file open/close counts, and many more. The CICS statistics utility `DFHSTUP` processes type 110 subtype 2 records and produces formatted reports.
Type 123: z/OS Connect
Type 123 is written by z/OS Connect for every API invocation. It captures the API name, HTTP method, response code, user identity, elapsed time, and backend subsystem called. This record type was introduced to give operations teams the same SMF-based audit and performance visibility for REST API traffic that they already have for CICS transactions and batch jobs.
How SMF Collects and Stores Records
SMF writes records to a set of dedicated VSAM datasets named SYS1.MANx, where x is a letter or digit (typically 1, 2, and 3 in most installations). These datasets act as a circular buffer: SMF writes to the active dataset until it reaches a configured fullness threshold, then switches to the alternate dataset and begins writing there. While SMF is writing to one dataset, operators can unload the other.
More recent z/OS releases support SMF log streams as an alternative to the SYS1.MANx datasets. Log streams are managed by the z/OS Logger component and can be directed to either DASD or a Coupling Facility list structure. Log streams offer better performance for very high SMF write rates, and they support real-time reading by monitoring applications without requiring an unload step.
SMF collection is configured in the SMFPRMxx parmlib member. The key parameters are:
- `DSNAME()`: the SYS1.MANx datasets to use.
- `LSNAME()`: log stream names, with optional type filtering (e.g. route type 30 and 70-79 records to a performance log stream).
- `INTVAL(n)`: the global interval recording interval in minutes. Controls how frequently interval-based records (like RMF types 70-79) are written.
- `SYS(TYPE())`: which record types to collect for z/OS system records.
- `SUBSYS()`: which record types to collect for specific subsystem categories (STC for started tasks, JOB for batch jobs, TSO for TSO users).
Suppressing record types that are not needed reduces SMF volume and the processing overhead to analyze it. A shop that does not use types 14 and 15 for file auditing will suppress them to avoid the volume. A shop that uses RACF type 80 records for compliance will ensure those are always collected.
Processing SMF Records
SMF records are binary. They cannot be browsed directly in ISPF or read by a text editor. Accessing them requires either a utility that understands the record format or a program written to parse the documented field layout.
IFASMFDP: The Unload Utility
IFASMFDP (IFA SMF Dump Program) is the IBM-supplied utility for copying SMF records out of the SYS1.MANx datasets into a sequential dataset for processing. It can filter by record type, date, time, system ID, and job name. The output is a sequential file of raw binary SMF records that downstream tools can read.
//SMFDUMP EXEC PGM=IFASMFDP
//SYSPRINT DD SYSOUT=*
//INDD DD DSN=SYS1.MAN1,DISP=SHR
//OUTDD DD DSN=SMF.EXTRACT.TYPE30,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(100,50))
//SYSIN DD *
INDD(INDD,OPTIONS(DUMP))
OUTDD(OUTDD,TYPE(30))
/*This JCL dumps only type 30 records from `SYS1.MAN1` into a sequential output dataset. Adding `DATE(2026001,2026031)` would restrict the dump to the first 31 days of 2026 (Julian day 001 to 031). Adding `START(080000)` and `END(180000)` would restrict to records written between 8am and 6pm.
IFASMFDL: Housekeeping
IFASMFDL deletes records from the SYS1.MANx datasets after they have been unloaded. If the SYS1.MANx datasets fill up completely before being cleared, SMF has nowhere to write new records. This is a production emergency: the system continues running but SMF data is lost. Most installations run daily jobs that unload and clear the SMF datasets on a 24-hour cycle.
Analysis Tools
Raw binary SMF records are processed by reporting and analysis tools. IBM provides several:
- RMF Postprocessor: reads types 70-79 and produces formatted performance reports covering CPU utilization, DASD activity, and WLM goal achievement.
- CICS DFHSTUP: reads type 110 subtype 2 records and produces CICS statistics reports covering transaction rates, DSA utilization, and file activity by region.
- RACF report writer (IRRADU00): reads type 80 records and produces security audit reports.
Third-party tools extend this substantially. IBM OMEGAMON, BMC MAINVIEW, Broadcom SYSVIEW, and Rocket Software MFA all provide real-time dashboards, historical trending, and anomaly detection built on SMF data. Modern SIEM platforms (Splunk, IBM QRadar) ingest SMF records via agents and correlate mainframe security events with distributed system events for unified security monitoring.
Real-Time SMF
The traditional SMF model is batch-oriented: records are written to a dataset, unloaded daily, and processed offline. Modern monitoring requirements often demand near-real-time visibility. z/OS supports this through SMF real-time access: an application programming interface that allows a monitoring program to read SMF records directly from the active SMF buffer as they are written, without waiting for an unload.
Real-time SMF access is how modern APM (Application Performance Management) tools provide sub-minute CICS transaction dashboards. A monitoring agent subscribes to the SMF stream for type 110 records. As each CICS transaction completes and writes its performance record, the agent reads it immediately, aggregates the data, and updates the dashboard. Operators see transaction response time trends in near real time, enabling faster problem detection than the traditional daily unload model allows.
What SMF Is Used For in Practice
The practical uses of SMF data divide into four categories that appear in every production mainframe environment:
Chargeback and billing. Type 30 records provide the CPU time, DASD I/O, and elapsed time for every batch job and TSO session. Finance departments use this to allocate mainframe costs to the business units whose work consumed them. The chargeback model is typically built on zIIP vs CP CPU time (different cost rates) and MSU consumption.
Performance management and capacity planning. RMF types 70-79 provide the long-term trend data for CPU utilization, paging rates, and DASD performance. Type 30 records identify which jobs are growing in CPU consumption quarter over quarter. Type 110 records identify which CICS transactions are degrading. Capacity planning decisions (how many CPs to configure, when to add storage, whether a zIIP upgrade is justified) are built on this data.
Security audit and compliance. RACF type 80 records are the primary evidence for security compliance frameworks: SOX, PCI-DSS, HIPAA, and others all require demonstrating that access to sensitive data is logged and monitored. The type 80 audit trail shows every access attempt to every protected resource, who made it, and what the result was.
Incident investigation and root cause analysis. When a batch job ran unexpectedly long, when a CICS transaction started timing out, when an unusual dataset access is suspected, SMF is the first place to look. The records provide a timestamped, subsystem-level account of what happened. The combination of type 30 (what job did), type 110 (what CICS transactions ran), type 80 (who accessed what), and type 70-79 (what the system resources looked like at the time) gives a complete picture of any incident.
Summary
SMF is z/OS's built-in telemetry foundation. Every subsystem writes structured binary records to a shared collection facility, using assigned record type numbers and a common header format. The record types that matter most for day-to-day mainframe operations are type 30 (job accounting), type 70-79 (RMF resource utilization), type 80 (RACF security events), type 110 (CICS transaction performance), and type 100-102 (DB2 accounting). Type 123 brings the same discipline to z/OS Connect API traffic.
Records flow from subsystem to SYS1.MANx datasets (or log streams), through IFASMFDP unload jobs, and into the analysis tools that make them useful. The same data supports billing, performance tuning, capacity planning, security audit, and incident investigation, from a single collection stream that has been operating continuously on mainframes since the 1960s.
Part of the Mainframe Decoded series — IBM Z and z/OS, clearly explained for engineers.