2. SAMPLE PLANNING APPLICATIONS › 2.1 z/OS Processor Planning › 2.1.1 Usage Guidelines

2.1.1 Usage Guidelines

 
The z/OS Processor Planning Sample Application provides a
capacity planning database file with the database elements
you need for basic tracking, reporting, and forecasting of
the processor workload.  The information for this application
is derived from either the DETAIL, DAYS, WEEKS, or MONTHS
timespan of the CA MICS CPU Processor Activity (HARCPU) File.
 
Note: If you select the CPU Time Adjustment option, some
additional data is used from the CA MICS Service Class
Resource Consumption (WLMSEC) File.

Consequently, the z/OS Processor Planning Sample Application
permits your data center to track and forecast processor
usage at a high level of summarization (that is, at the SYSID
and ZONE, HOUR, or DAYNAME level).  Because the data is
derived from the HARCPU File, this sample application
provides information about system-wide processor use, rather
than individual workload use.

In addition to providing basic information about processor
utilization, the z/OS Processor Planning Sample Application
also stores data concerning average batch, started task, and
active TSO users in the system.  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
batch, started task, and TSO user growth.  See Chapter 14,
Workload Forecasting, for more details on this technique.

NORMALIZATION
 
Another useful feature that the z/OS Processor Planning
Sample Application provides is the ability to normalize
processor utilization to a base CPU.  Processor busy time is
an indicator that is 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 looks more like a "saw-tooth" function than a
smoothly increasing function.  This is because more powerful
processors can process the same amount of work in less time
than their slower predecessors could, and therefore spend
less time processing.  This contradicts the fact that the
data center 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 processor busy time and processor
percent busy elements 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

If the CPU Time Adjustment option is chosen, both the
normalized and the unnormalized processor busy and percent
utilization elements are still stored in the database and are
available for reporting and analysis.
 
We recommend that you use this option to normalize workloads,
since trending and forecasting CPU utilization without
normalization is extremely difficult and often misleading.
NORMALIZATION EXAMPLE
 
Assume that a data center installed the z/OS Processor
Planning Sample Application.  They chose the optional CPU
Time Adjustment and specified an IBM 2064-2C1 as the base
CPU.  The number of processors is 1 and the service unit
coefficient is 14692.3.

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 HARCPU
File as the equivalent of an IBM 2064-2C1 processor.

Assume that one of the processors in the HARCPU File for this
data center is an IBM 2084-302.  During one week, this
processor had a CPU busy time of 48 hours in 40 hours of
operation.  Since the 2084-302 has two internal processors,
we can calculate the average percent busy for the 2084-302
for the week as:
 
    100*(48/(2*40)) = 60%.
The vendor has stated that the 2084-302 processor has a
service unit to CPU second conversion factor of 20752.2, and
we have chosen to use this factor for our normalization.
Therefore, the normalized CPU busy time is:
 
    48 * (20752.2 / 14692.3) = 67.79 hours
In other words, this technique estimates that a workload
requiring approximately 48 hours of CPU time on an IBM
2084-302 requires approximately 67.79 CPU hours on an IBM
2064-2C1.  Since the 2064-2C1 has only one internal
processor, the adjusted CPU percent utilization would be:
 
    100 * ( 67.79 / ( 40 * 1 ) ) = 169.47 %
While it is impossible for a processor to run at 169%
utilized, the calculation shows what the estimated
utilization would be if the workload were running on the IBM
2064-2C1 processor.  That is, we would need a minimum of two
2064-2C1 processors to process the work being done currently
by the 2084-302.
Note that the use of an actual, commercially available
processor as the base CPU is not required, and may not even
be desirable for the data center.  It would be perfectly
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 have trends and be
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 either be supplied by mainframe
manufacturers or established by the data center through
benchmark testing.