2. SAMPLE PLANNING APPLICATIONS › 2.2 WLM Workload Planning › 2.2.1 Usage Guidelines

2.2.1 Usage Guidelines

 
The WLM Workload Planning Sample application provides a
capacity planning database file with the database elements
you need for tracking, reporting, and forecasting of the
workloads on your system.  The information for this
application is primarily derived from either the DETAIL,
DAYS, WEEKS, or MONTHS timespan of the CA MICS Service Class
Resource Consumption (WLMSEC) file. The WLM Workload Planning
Sample application also acquires additional planning elements
from the CPU Activity (HARCPU) and the Paging Activity file
(SCPPAG).
The WLM Workload Planning Sample application permits your
installation to track and forecast resource consumption and
transaction activity at a high level of summarization (that
is, at the SYSID and ZONE, HOUR or DAYNAME level) for
workloads.  Because the data is derived from the WLMSEC file,
this sample application provides information about individual
workloads based on Service Classes.
In addition to providing basic information about workload
processor utilization, the WLM Workload Planning Sample
Application also stores data concerning application busy
time, storage occupancy, I/O rates, and paging activity.  You
may find these elements useful in tracking and reporting.
Also, you can sometimes make certain correlations between
these elements and total processor utilization, thereby
providing a technique for forecasting processor utilization
on the basis of average workload growth.  See Chapter 14,
Workload Forecasting, for more details on this technique.
SERVICE CLASS WORKLOADS
 
The WLM Workload Planning Sample Application allows you to
divide your service classes into groups, or workloads.  For
each defined workload, the application stores measures such
as the number of ended transactions, CPU time consumed by the
workload, total service units consumed by the workload, and
DASD I/O statistics into the capacity planning database file.
You define Service Class Workloads by using one of two
methods. The first method is to create a Workload Mapping
Table in an 80-byte, fixed block data set or PDS member. The
second method for creating Service Class Workloads is to
write a CAPAPU exit using SAS code to specify the workloads
to which each Service Class belongs.
 
Once defined, you can modify the workload definitions as
often as necessary without having to respecify other Goal
Mode Planning parameters.

NORMALIZATION
 
The WLM Workload Planning Sample Application provides the
ability to normalize processor utilization to a base CPU.
Processor busy time is an indicator commonly used in capacity
planning for reporting and forecasting.  However, as systems
are saturated and upgraded to more powerful processors, a
graph of processor busy time looks more like a saw-tooth
function rather than a smooth, monotonically increasing
function. This is because more powerful processors process
the same amount of work in less time than their slower
predecessors and therefore spend less time processing. This
contradicts the fact that the installation has really
increased its processing capability with the upgrade.
You can circumvent this situation by normalizing all
processor busy time to the equivalent of a base CPU. You can
optionally request that the Goal Mode busy time be adjusted
to a base CPU of your specification. To use this feature, you
must supply the following information:
 
o  The base CPU model type or name
 
o  The number of internal CPUs contained in the
   processor
 
o  The base CPU service unit to CPU second conversion
   factor (service unit coefficient)
If the CPU Time Adjustment option is chosen, both the
normalized and the unnormalized Goal Mode busy elements are
still stored in the database and are available for reporting
and analysis.
It is recommended you use this option to normalize workloads,
since trending and forecasting workload CPU utilization
without normalization is extremely difficult and often
misleading.
NORMALIZATION EXAMPLE
 
Assume an installation installed the WLM Workload Planning
Sample Application. They chose the optional CPU time
adjustment and specified an IBM 9121-742 as the base CPU. The
number of processors is 4 and the service unit coefficient is
1351.68.
These parameters, entered on the CPU Time Adjustment
Parameters control screen, are then used to normalize CPU
time values for any processor appearing in the CA MICS WLMSEC
file to the equivalent of an IBM 9121-742 processor. Assume
that one of the processors in the WLMSEC file for this
installation is an IBM 9672-RY5 (4 engines). During one week,
one workload had a busy time of 50 hours in 100 hours of
operation.

The vendor has stated that the 9672-RY5 (4 engines) processor
has a service unit to CPU second conversion factor of
2902.76, and we have chosen to use this factor for our
normalization. Therefore, the normalized Goal Mode busy time
is:
 
    50 * (2902.76 / 1351.68) = 107.38 hours
In other words, this technique estimates that a workload
requiring approximately 50 hours of CPU time on an IBM
9672-RY5 requires approximately 107.38 CPU hours on an IBM
9121-742.
Note that the use of an actual, commercially available
processor as the base CPU is not required, and may not be
desirable for the installation.  It is acceptable to specify
a hypothetical processor.  For example:
 
    Base CPU Model = MY_CPU
    Number of Processors = 1
    Service Unit Coefficient = 100
These parameters adjust all processor busy elements to the
equivalent of a hypothetical processor having one internal
CPU with a performance rating of 100 service units per CPU
second.  The fact that such a processor may not actually
exist is not important, but rather that all processor time is
being converted to a common unit that can be trended and
examined smoothly and consistently over time.
Also note that these calculations make no attempt to apply
any analytic queuing formulas or benchmark estimates to
compare one processor to another.  The basic comparison of
processors is calculated as the ratio of the service unit to
CPU second conversion factors for the respective processors.
These numbers can be supplied by the mainframe manufacturers
or can be established by the installation through benchmark
testing.