6. DATA SOURCES › 6.5 RMF LCU Summarized File

6.5 RMF LCU Summarized File

The Logical Control Unit (LCU) Activity File in CA MICS
provides a single, convenient location for summarized
input/output configuration-related measurement data.  The LCU
file consolidates RMF data that is spread across several
CA MICS files for improved usability and understanding of the
I/O subsystem measurements.

The LCU summarized file in CA MICS is created from the DAYS
level versions of the following files, summarized to the LCU
level:

HARDVA - Device Activity File
SCPLCA - Logical Channel/Channel Path Activity File
SCPIOC - I/O Queuing Configuration File

It contains all of the information related to configuration
dependent delays, summarized in one convenient file for
reporting and analysis.

The summarized DVA information in the LCU file can be used to
quantify configuration-dependent delays.  The summarized IOC
information in the LCU file provides data on the physical I/O
configuration itself.  The summarized device utilizations are
provided in the LCU file and can be distributed across the
configuration.  Information on device selection failures due
to configuration-dependent delays is also provided.

I/O configuration tuning involves changes to the I/O
configuration to minimize the amount of delay time associated
with configuration-dependent queuing.  In a well configured
system, channels, control units, heads of string and device
activity are distributed across the I/O workload to minimize
the delays.  RMF directly measures device and channel
activity, but control unit and head of string activity must
be derived from the basic measurements.

Devices are known to RMF only by their logical addresses, or
device numbers.  However, there is information on the
physical configuration at the logical control unit level in
the SMF type 78 (Monitor I Activity) record subtype 3.  The
IOC file of CA MICS, for instance, contains information on
the channels that are attached to each LCU, as well as the
physical control units that are attached to these channels.
In addition, control unit and head of string utilizations can
be derived from other measurement data by distributing the
connect time for devices across the heads of string and
physical control units to which they are attached.

I/O processing has been largely offloaded from the host
system to a dedicated channel subsystem.  This hardware
facility is called the I/O Processor (IOP).

During Initial Microprogram Load (IMPL), the channel
subsystem reads the I/O Configuration Data Set (IOCDS)
generated by the I/O Configuration Program (IOCP).  This file
describes the I/O configuration in detail, including
information related to the channel paths and physical
addresses of all devices connected to the system.  This
information is mapped to control blocks in a reserved area of
main memory (the Hardware System Area, or HSA) that is used
to manage the communication between the channel subsystem and
the host.

An I/O request that is initiated on the host is passed to the
channel subsystem via a Start Subchannel (SSC) instruction,
referencing a logical device number.  The channel subsystem
converts the device number to a physical address and
determines the paths to the device.  The channel subsystem is
responsible for initiating the I/O request over one of the
available paths.  It also provides measurement data directly
on the I/O event.

I/O request scheduling, queuing, and measurement are focused
on what is known as the logical control unit, or LCU.  An LCU
represents one to eight physical control units sharing common
devices.  Logical control units are defined by the IOCP based
on the specifications of devices and control unit
connections.  Each physical control unit is assigned to one
(and only one) logical control unit at that time.  At the
device level, the LCU specification is also unique.

Once the channel subsystem is notified of an I/O request, it
begins timing the operation, and maintains timers for pending
time, connect time, and disconnect time.

The first step of initiating the I/O operation is the
establishment of a path to the device or device selection.
The channel subsystem continuously polls the LCUs to
determine if any new I/O requests have been made for the
devices that are attached to the LCU.  If so, the LCU is
placed on the channel subsystem initiative queue.  All of the
time between the SSC request and the successful initiation of
the I/O request (establishing the path to the device), is
measured and maintained as pending time.

If the device is busy from another system, or the head of
string or control unit attached to the channel path is busy,
then initial selection fails and the request must be
requeued.  If device busy was detected, then the operation is
deferred until a signal (Device End) is received from the
device indicating that it has completed its prior operation:
the source of contention at the device level has been
relieved.  If control unit busy is detected, the channel
subsystem will attempt another path.

The channel subsystem counts the number of selection attempts
and keeps track of the delay reasons.  These data are
available at the LCU level.  The delay reason is associated
directly with the active device, with pending time broken
into component parts for delays that are due to control unit
and device busy conditions.  The delay reason counts are
reported only at the individual device level, and not for the
LCU.

Pending time also includes delays associated with queuing for
the IOP or the channel path, or contention within the LCU
itself.  Once the I/O is successfully started, the channel
subsystem keeps track of the amount of time that is used to
complete the I/O request, dividing the I/O service time into
time spent where only the device is busy (disconnect time)
and time where the device, control unit, and channel are all
busy (connect time).

The sections below detail the following:

    1 - I/O Queuing in the I/O Processor
    2 - Sample Data Elements in the RMF LCU Summarized File