How to read RMF 74.1 DASD response time: CONN, DISC, PEND, IOSQ

RMF 74.1 DASD response time is the average time an I/O to a disk volume takes on z/OS, split into four parts: IOSQ, pending, disconnect and connect time. Read the four together: the largest one tells you whether the delay is in z/OS, on the path to the storage system, or inside the storage system.

The total alone rarely explains anything. Two volumes with the same response time can have opposite problems, and the fix for one would do nothing for the other. This article explains where the numbers come from, what each component measures, and in which order an experienced analyst reads them.

Where RMF 74.1 data comes from

RMF Monitor I measures every device at each interval and writes the result as an SMF type 74 subtype 1 record (device activity). The RMF Post Processor turns those records into the Direct Access Device Activity report, one line per volume and per interval. BMC CMF MONITOR writes equivalent records and prints its own DASD activity report.

A minimal Post Processor step for disk looks like this:

//RMFPP    EXEC PGM=ERBRMFPP
//MFPINPUT DD DISP=SHR,DSN=YOUR.SMF.DUMP
//SYSIN    DD *
  REPORTS(DEVICE(DASD))
/*

For each volume, the report gives the device number, volume serial, LCU, device activity rate and the response time with its components. Those columns are the subject of the rest of this article.

The four components of DASD response time

RMF computes the average response time as a sum:

Response time = IOSQ time + pending time + disconnect time + connect time

Each component covers one stage in the life of an I/O, from the request in z/OS to the end of the data transfer.

IOSQ time

IOSQ time is spent inside z/OS. The I/O Supervisor holds the request because the device is already busy with another request from the same system. Parallel Access Volumes (PAV, HyperPAV and SuperPAV) exist to reduce it, by letting several I/Os run against one volume at the same time.

High IOSQ time on a volume usually means its alias capacity is short for its activity, or that one volume concentrates too much of the workload.

Pending time

Pending time starts when z/OS starts the I/O and ends when the device accepts it. The request waits for a free channel path, a switch port, the control unit and the device. RMF also shows two of its parts: AVG CMR DLY (command response delay) and AVG DB DLY (device busy delay).

Device busy delay often points at sharing: another system holds the volume, for example with a reserve. Command response delay points at a control unit slow to answer.

Disconnect time

Disconnect time is spent inside the storage system while the channel is free. The classic cause is a read cache miss: the data must be staged from the back end before it can be sent. Synchronous remote copy also adds disconnect time to writes, because the write completes only when the secondary has it.

To tell these causes apart, read the RMF Cache Subsystem Activity report (SMF 74.5) for the same interval, and check which volumes are in a synchronous copy relationship.

Connect time

Connect time is the actual transfer of commands and data between the channel and the storage system. It grows with the amount of data per I/O and falls with faster links and with zHPF channel programs.

High connect time is not a fault in itself. A volume that moves large blocks will always show more connect time than one serving small random reads.

Read the components in the right order

An analyst does not read the report line by line. A short method keeps the attention on what matters:

1. Weigh the volume first. Multiply the activity rate by the response time. A slow volume with almost no I/O costs little; a slightly slower volume with heavy activity can cost a lot.
2. Find the dominant component. The largest component decides where to look next: z/OS, the paths, or the storage system.
3. Work by interval, not by day. Daily averages hide the batch window and the online peak. Look at the intervals where the volume is busy.
4. Group before you conclude. Compare volumes of the same LCU, storage group or LPAR. A problem shared by a whole LCU is not a volume problem.
5. Compare with a baseline. The same interval on previous days tells you whether a value is new or normal for that volume.

A worked example

Example values, for illustration: the figures below are not taken from a customer system. They show one volume at three intervals of the same day; the I/O rate is per second and the times are in milliseconds.

During the day, connect time dominates and the volume is healthy. At 02:00, during batch, response time is five times higher. Two components explain it: IOSQ (requests queue in z/OS, so alias capacity is short for that load) and disconnect (likely sequential reads that miss the cache). Pending time barely moves, so the paths are not the issue. The next step is the cache report and the alias configuration for that interval, not a faster channel.

Common pitfalls

• Trusting the total. A stable total can hide a shift from connect to disconnect time after a configuration change.
• Ignoring idle volumes with high response time. A volume with a handful of I/Os per second can show a high average for reasons that do not matter.
• Forgetting shared DASD. Each system reports its own view of a volume. A reserve on one LPAR shows up as pending time on the others.
• Mixing RMF and CMF layouts. The components mean the same thing, but column titles and report sections differ.

How zPulse reads the report

zPulse Disk reads the printed RMF Direct Access Device Activity report, or the CMF DASD activity report, as text files. It does not read raw SMF records, and nothing is installed on z/OS.

From those reports, zPulse charts the response time and its components (IOSQ, pending, disconnect, connect) per interval and per LPAR, with filters on LPAR, volume serial, storage group and LCU. It averages them by period for each LCU, storage group, volume and LPAR, and ranks the worst volumes by I/O rate, response time and each component, with IOSQ and pending alerts.

The same study reads the Cache Subsystem Activity and I/O Queuing Activity pages, so the cache misses and HyperPAV use that explain disconnect and IOSQ time sit next to the response time. A scheduled study can send a daily DASD mail that charts up to 60 days of history. See the zPulse overview for the other modules, or our expertise if you would rather have an expert read the results with you.

The quickest way to apply this method is on your own data: a free study runs your RMF or CMF reports through zPulse, and a Technical Storage expert walks you through the components that matter on your volumes.