2. PERFORMANCE REPORTING ANALYSIS › 2.4 I/O Configuration Analysis › 2.4.8 FICON Channel Performance Analysis Inquiry › 2.4.8.2 Technique Tutorial

2.4.8.2 Technique Tutorial

To properly analyze the FICON channel measurements, data from
several CA MICS files is required.  The main source of
measurement data is the CA MICS HARPCA file, which is built
from the SMF type 73 record and a basic performance profile
can be built from this data alone.  However, to fully
understand the meaning of the metrics presented in the HARPCA
data, one must examine the LCU and device level data as well,
and combine it with the channel level measurements.  Two new
estimated metrics are needed: Open Exchanges, which is a
measure of I/O operations concurrency, and Credits, which are
a hardware controlled internal buffer that contain both the
channel program and data for a given operation.  The
methodology for obtaining the measurements is presented
below.

First, the HARCPU file is read up and the CEC Serial Number
is saved, along with some general information about the
processor complex.  This is done because FICON channels
typically operate in a shared mode across LPARs and the basic
HARPCA measurement includes a complex level set of
measurements along with those of the recording LPAR.  To
build a complete picture of channel performance, you must be
able to group all data for a given processor complex together
and the HARCPU file will provide the means to do this.

The main set of metrics is obtained from the HARPCA file.
Additionally, beginning with z/OS 1.5 executing on the z990
platform, a new facility was added called the Logical Channel
Control Subsystem or LCSS.  The purpose of this facility is
to permit more than 256 channels to be present on a given
platform and to permit LPARs to be mapped onto those
channels.  Each LCSS can contain up to 256 channels, so that
currently, a fully configured z990 system can contain 31
LPARs, using 32 central processors, and mapped against 512
channels.  The LCSS is identified by a one byte field called
the CSSID, or Channel Subsystem ID and this field resides in
the SMF type 73 record.  The FICON Performance Analysis
application will locate and save the CSSID value to ensure
that each FICON channel can be properly mapped against its
owning LPAR, and that its measurement data is correctly
summarized both at the LPAR and processor complex (CEC)
levels.

The Open Exchange metric is an estimate of channel I/O
operations concurrency and may be thought of as a channel
MPL.  It is a function of how busy the channel is during a
point in time and is driven by the combination of device
connect and disconnect times.  Normally, a channel is not
considered "busy" during disconnect times.  FICON channels,
however, generally do not disconnect during typical
operations but rather hold the Open Exchange until the I/O
operation has completed.  This is done to avoid the overhead
of freeing and rebuilding the Open Exchange, given that most
disconnect times are due to cache misses, are normally short
in duration and hopefully rare.  Certain types of I/O
operations actually can result in the channel disconnecting
and in those instances, the Open Exchange is terminated and
freed.  However, this is not typically seen in DASD
operations.

To compute the (estimated) Open Exchanges, you must first
summarize device level measurement data, specifically, the
DVACNN (Device Connect Time), DVADIS (Device Disconnect Time
and a new metric, DVACMRTM (Command Response Time).  The
Command Response Time is actually a subset of DVAPEN (Pending
Time) and represents the time from the first command being
sent to a given device until the device has indicated it has
successfully received the command. The Open Exchange
computation is essentially a variation of Little's law and is
performed by dividing the sum of the above measurements by
the duration of the measurements.  You can either compute the
Open Exchanges based on each device, or total all devices
within a Logical Control Unit (LCU) and perform the
calculation at that level, or even wait until all
measurements have been completed for the channel.  Given that
this is an estimate, any of the methods may be used with the
same degree of accuracy.

Channel-to-Channel devices do a variety of different
operations and can seriously impact measurement efforts on
FICON channels.  CTC devices issue a command called a
"Prepare" and then wait for a response. During this time, the
device is considered "disconnected" and disconnect time
continues to accumulate.  This can result in very large
values for disconnect time and will subsequently distort the
calculation for Open Exchanges.  Additionally, CTC devices
often use what is called a "Seldom Ending Channel Program,"
which causes a device to appear "busy."  To address this
issue, the FICON Performance Analysis application currently
will zero out the disconnect time values for any CTC device
encountered and compute the Open Exchanges based on device
connect and command respond times only.

An additional issue is in regard to non-MVS systems operating
on the same mainframe platform.  Remember that the SMF type
73 data contains both global (complex) level measurements and
all operating systems residing on the same complex will
contribute to these measurements even though only MVS-type
systems currently record any LPAR level measurements.
Moreover, non-MVS systems will not create any RMF type data,
so the sum of all LPAR data may not equal the totals
represented by the complex-level measurements.  Even MVS
systems that operate as "guests" under VM may not record
their measurement data completely and can impact FICON
channel measurements.  To address some of these issues, the
FICON Performance Analysis application will delete any
measurement data from any MVS system that appears to be
executing under VM.  It is thought to be better to discard
any data that is suspect rather than include it.

Once the device level data has been processed and summarized
by LCU, the SCPIOC data is then read up and merged with it.
The summarized LCU measurement data is then prorated among
all active channels by the IOCPT element, the Number of Times
Path Was Taken value.  This ensures that any channel not
active will be excluded from the prorating process and that
the prorated results will properly reflect the channel
activity.

The prorated results are merged with the HARPCA data so that
a complete picture of channel performance is available.  The
other estimated metric, Credits, can now be estimated since
it requires that an average I/O burst size be first
calculated and the result applied to the Open Exchanges.  The
average I/O burst size is simply the total bytes read and
written for the channel, divided by the total Start
Subchannel Count.  Since the Open Exchanges represent the
number of concurrent channel operations, the number of
Credits will be a function of this value and the average size
(in bytes) of each operation.  Again, these are only
estimates of these values, and while the methodology
presented is believed to be accurate, having these values
actually measured and reported through the RMF data would
obviously be more effective.

The complete measurement results are presented in a variety
of graphs and reports.