A CAPACITY-COSTING METHODOLOGY

Michael S. Zambruski, Boeing Computer Services Company

ABSTRACT
This paper describes a hybrid technical-financial procedure for allocating cost in a large
data center. It is designed as a modeling tool to permit IIWHAT-IF" analyses for various
configurations, levels of costing. etc. The use of modular programming, independent tables,
and matrix output allows the modeler maximum flexibility in allocating cost according to
changing technical and financial considerations.
The first segment of the procedure focuses on a technique for determining primary system
capacity. The second segment generates the cost-allocation mechanism, which assesses cost to
users based on their individual impact on capacity.
1. INTRODUCTION
One of the key problems in developing OP
costing systems has been to find a common
ground between technology and finance such
that a methodology acceptable to both parties
would arise. On the one hand, technical
considerations such as performance tuning
have led to costing algorithms which
financial circles have dismissed as overly
complex. On the other hand, the type of
accounting information traditionally sought
by financial offices has left data center
managers very skeptical. This paper
describes a decision-oriented procedure which
hopefully makes reasonable progress in
resolving this dilemma.
The basic philosophy of this method
identifies flexibility, simplicity, and
usabil ity as the ultimate criteria of success
in a cost-allocation system. The system must
be relatively easy to modify so that it does
not become obsolete in the face of new
technological and economic developments. It
must be simple, though in a responsible
sense; that is, its complexity must be
tempered with practical judgment. Finally,
no matter how purportedly accurate or
comprehensive the system is, it must be
user-oriented.
In an attempt to develop such a it
was necessary to make many assumptions and
draw some relatively controversial
conclusions. These are clearly discussed,
however, together with the vari ous
alternatives considered, so that the reader
can appreciate how expandable--rather than
limited--the method is.
The technical section considers a capacity
projection tool in which the key diagnostics
are CPU time, real memory, and I/O activity.
Regression analysis is used to define
predictable relationships among these
diagnostics for each of the user groups which
comprise the system load (e.g., batch, CICS,
interactive, etc.). These relationships are
used to project maximum productive CPU
time--and the associated memory and I/O
necessary to sustain that CPU level--for each
of the user groups. Further refinements are
made to accommDdate time of day (prime,
non-prime, weekends) and boundness (CPU,
memory, I/O) as they affect capacity and cost
projections. At this point, it is shown how
a specific user's impact on capacity can be
determined.
The financial section first considers several
types of system-level costs as candidates for
distribution. A variable-load/variable-cost
concept is then selected to produce a basic
cost rate. An individual user's cost is
finally calculated using this basic rate,
adjusted according to the user's impact on
capacity (i.e., time of day, boundness, type
of service, host configuration, etc.).
The analysis presented in this paper deals
exclusively with MVS and it is
developed within the framework of the MVS
Integrated Control System (HICS*). Since
MICS is written in SAS, so are the programs
which form this model.
2. TECHNICAL SECTION
In constructing a technique for defining
primary system capacity, an initial deciSion
was made to limit the key diagnostics to CPU,
memory, and I/O. This is not to say that
processing was the sale area of concern.
Rather, it was assumed that high-level usage
of CPU, memory. and I/O in most cases
corresponds to high-level communications
activity, DASD occupancy, etc. Further, it
was recognized that major capital asset
decisions are usually driven by two
performance criteria: interactive response
time and batch throughput, both of which are
extremely sensitive to the central processor
configuration. In short, by analyzing CPU,
memory, and I/O as diagnostics of total
system activity, it appeared that a minimum
number of resource types could be studied and
still yield valid conclusions for
system-level technical and financial
'decisions.
*M-ICS is a product of Morino Associates,
Inc.
In spite of this effort at simplification, it
should be noted that the methodology to be
discussed is inherently flexible, so that it
can easily accommodate refinements to
include, for example, separate segments for
network activity, DASD occupancy, and other
pertinent aspects of performance. At the
outset, however, the three key elements
discussed above provide a sound and
digestible point of departure and possess a
significant degree of validity on their own.
In analyzing these
i
key diagnostics, the
following strategy was employed:
a. determine current consumption of TCB
time, main memory, and total EXCPs at
the system level and at the
individual user level.
b. investigate the relationships among
these three major resources.
c. project maximum productive TCB time
as a portion of wallclock time.
d. project maximum main memory and
EXCPs from (b) and (c).
TCB tim"--as opposed to SRB or total CPU
time*--was selected as the most efficient
measure of user processing time for both
capacity and costing purposes. {For example,
the ratio of TeB to SRB produced a relevant
insight into a userls I/O boundness--a key
technical concept to be applied later in the
finanCial section.} Real memory usage was
calculated at the step level: average
working set size (expressed in pages)
multiplied by the corresponding residency
time. This yielded a two-dimensional
variable (page-seconds) which was very
effective in portraying finite memory usage
under actual operating conditions. Total
EXCPs were used as the most consistent
indicator of user I/O intenSity. Included
were measurements of disk, tape, mass
storage, unit record, communications, and
virtual I/O activity.
Current consumption measurements were made
from SMF, RMF, and TSO/MON** data accessed
directly from the MICS data base. Separate
measurements were made according to
configuration, user group, and time period.
Configurations were distinguished according
to number of processors (Up vs. AP),
essential tuning differences, etc. Three
user groups were defined: batch,
interactive, and transaction--which included
CICS, IMS, etc. (The model will allow
further breakdowns; for example, separate
*TCB = Task Control Block time; SRB
Service Request Block time. I TCB+SRB' is
commonly referred to as Itotal CPU time
l
for a program (obviously excluding
operating system CPU time, or 'overhead').
2
categories for CICS and IMS.)
periods, or zones, were used:
zone 1
zone 2
zone 3
zone 4
0800-1800
1800-2400
2400-0800
weekends.
Four time
Extensive statistical analYSis was then made
in order to isolate and verify predictable
relationships among the diagnostics. For
example, the SAS procedure PROC SYSREG was
used to develop independent and simultaneous
regression equations for the following
combinations of variables:
main memory vs. TCB seconds
total EXCPs vs. TCB seconds
main memory vs. total EXCPs
Various other SAS PROCs (e.g., REG.
UNIVARIATE, RANK, PRINCOMP, & RSQUARE) were
employed to analyze residuals, test for
collinearity, and verify the rationality of
variable combinations chosen. The goal was
to predict the level of memory and I/O
activity which would be necessary to sustain
a particular level of CPU activity--both at
the system level and at the user-group
level. For this -purpose, it was found that
the simultaneous regression equations
provided the best solutions for interpreting
the independent and mutual variability among
the diagnostics.
The next step was to project maximum CPU
time. Since commands are processed
non-concurrently within each processor, it
was decided that maximum CPU time would be
defined in terms of percentage wal1clock
time. This would provide a frame of
reference which is technically reasonable and
yet readily acceptable to a non-technically
oriented audience, such as finance or
management. Also, this fundamental concept
of a CPU/wallclock relationship would allow
direct measurement {rather than a standard
capture ratio} to be used in finding
I productive I capacity--i .e.. that non-
overhead portion of system capacity which is
available to users for batch, interactive,
and transaction work.
The approach taken to this task is depicted
in Figure I, which shows overall CPU activity
(TCB, SRB, and system overhead) for
Configuration A. In this case, individual
time zones were broken down into three
categories, each of which expressed overall
CPU time as a percentage of total possible
wallclock time for that zone:
**TSO/MON is a product of Morino Associates,
Inc.
PEIICENI SUM

I .... ..
900'" .... .
. I
800'"
i
.I[)II
I :::::
6110 +
i

I
. +
i
.300 .. :::::
i
200 +
I
. 100+ ..
i
.....
.....
.....
.....
.....
.....
.....
.....
T1TH
TUU
HHT
11111
III II
III II
III II
11111
11111
0000.
00008
00008
0000'
<::OHPAAIIION Of <::1'0 UrllI7ATlOH " HllXIHUH VS. TOTAL VS. USERS
REfERS TO IOTAl POSSI8lE WAll-<::lIX:K TlHE
<::ONfiOURMlllN A -- roo OII[ MORTII
. ....
.....
.....
. ....
.....
.....
.....
.....
.......
.....
.....
.....
.....
.....
BAR CII ....1I1 or SUHS
HTH
11111
11111
D0888
.0000
,0000
80088
888D8
.....
80008
. ....
.....
-,
. ... .
. ... .
. ... .
. ... .
.....
.....
....
.....
TlTTT
11111
B8888
BBBUB
OoODO
DOOOB
OBB08
8B808
00000
. ... .
. ... .
.. .. .
. ... .
. ... .
. ... .
.....
.....
.....
.....
.....
.....
.. .. .
. ... .
. ....
.....
. ... .
. ... .
HTTT
nTH
III I I
.....
.....
DOD80
D0880
OBODO
B0888
80888
, ....
-------------------------------------------------------------------------------------------------------------------------------
'"
"" '"
.. ,
"" '"
."
CAHGCRY
t--------- , ---------1
1--------- 2 --------- t 1--------- , ---------1 1--------- ,,---------1 Z(lftE
SYMBOL SERVICE SYMIOl SIIV ICE SYMBOL SERVICE SYMIOL SERVICE
,
IIfTEItACT TRA>lSACT
F [ G U REI
COMPARISON Of CPU UTILIZATION = MAXIM .... vs. TOTAL VS. USERS
PERCENT REfERS TO TOTAL POSSI8lE WALL-CLOCK TIME
MIN: TIN: (0800-18001 fOR Oft[ ,.,NT"
CONfiGURATION A
BAR c.tIART Of SUMS
PEIK:UT


..
I
I
.. .. .. .. .. .. .. .. .. ..
I
..
.!l00

.. .. .. .. .. .. .. .. ..
I
.. .. .. .. ..
I
.. ..
....

..
"
..
!
.. .. .. .. ..
.. .. . .
. r ..
I
.. .. .. .. .. .. .. .. .. .. . . . .
I ..
I . . ..
.... ... .. .. .. .. .. .. . . .. . . ..
j
.. .. .. .. .. .. .. . . .. .. .. . . ..
.. .. .. .. .. .. .. .. ..
.. . ...
. ,.,
I
.. .. .. .. .. .. ..
I
.. .. .. . . ..
I
.. .. .. .. .. .. .. . . .. .. :: . . .. .1t00
i ::
.. .. .. .. .. .. .. . . ..
.. .. .. .. . . ..
n
"
..
.. .. .. .. .. ..
n
.. .. .. ..
n
. . ..
. ,,.
..
.. .. .. .. .. .. ..
n
. . ..
n
..
n
.. ..
n
. .
n
.. .. .. ..
I
.. .. .. .. .. TT .. ..
"
. . ..
n
.. ..
n
.. ..
"
. . ..
n
.. ..
n
.. ..
I
.. .. ..
n
.. 1T
"
....
"
.. ..
"
.. ..
"
.. ..
"
.. ..
n
.. ..
n
I
....
"
II
" " " "
"
..
"
n
. ,,.

.. .. .. ..
"
.. II .. ..
"
....
"
.. ..
"
.. ..
"
., ..
"
.. ..
"
.. ..
"
I
.. ..
n
.. ..
"
.. II .. ..
"
....
"
.. ..
" " "
..
"
.. ..
"
"
.....
"
II
"
" " " " "
"
I
..
"
.. ..
"
.. ... II ..
"
. ...
..
.. ..
" " "
.. ..
"
.. ..
"
....

..
"
.. ..
"
.. II ..
"
..
. ...
..
.. ..
..
..
"
.. ..
"
.. ..
"
. ..... ..
I
..
..
.. .. .. ..
:: 80
.. ..
..
.. ...
..
.. ..
..
.. .. .. . . .. .. . .
..
. .... ..
I
.. ..
..
..
"
..
..
. .
..
.. . .
..
.. ..
..
.. .. .. .. .. .. .. ..
..
.. ... ..
I
..
..
.. ..
"
.. ..
.. .. ..
.. .. . . .. .. .. .. .. ..
"
.. ..
"
.. ..
..
" ---------------------------------------------------------------------------------------------------------------

, ,

r
"

,

r
"

,

,
"

r

r
"

"

r
A
, , , , ,
A
, , , ,
A
,
A
, ,
A
, , , ,
A
, ,
A
,
CATEGORY
X r
,
x r
,
x
,
x r
,
x
,
x r
,
x r x r
,
x
, ,
x r
1-- -I 1-- \I -I
'"
"
" " "
"
..
"
HOUR
SYMBOL SERVICE SYMBOL SERVICE SVMDDl SERVlcr
SEAVICE
BATCH INTERACT TRANSACT
F I G U R E 2
3
a. flAX
b. TOT
c. USE
total time for which the CPU
was available.
total time during
was actua 11y
instructions.
which the CPU
executing
total attributed to
executing user programs (i.e.,
'productive' time), as opposed
to system overhead activity.
This was further subdivided into
the three user groups--batch,
interactive. and transaction.
In attempting to project maximum productive
capacity, the following logic was applied to
Figure 1. The between the MAX and
TOT columns represents total unused capacity;
the difference between the TOT and USE
columns represents system overhead. Based on
this, we can grow the TOT columns to some
level at or below f.1AX to signify maximum
practical CPU, and then grow the USE columns
to show the corresponding maximum productive
CPU. In this regard. it was assumed that a
basically linear relationship exists between
TOT and USE, so that any growth projected for
TOT would yield linearly proportional growth
in USE. To test this assumption, zone 1 was
profiled for an entire month on an
hour-by-hour basis (Figure 2). This gave
more visibility to average peak periods and
their associated TOT-USE profiles. The
results appeared to support the assumption of
basic linearity. Accordingly, the TOT
columns in Figure 1 were grown to the 90%
level (above which any linear predictions
would probably be invalid), and the USE
columns were increased proportionately.
Thus, when TOT for zone 1 was grown from 70%
to 90%, USE for that zone was increased from
33% to 43%:

Each of the USE columns were similarly
increased, with the results representing the
maximum productive CPU capacity for each
zone.
Because the USE columns are subdivided into
the three user groups, the overall capacity
prOjections had to be prorated among these
subgroups. Figure 3 outlines this concept,
termed I reserved capacityl. In this case, it
was decided to project a separate maximum for
each subgroup in relation to its existing
impact on the system. In essence, this
assumed that the future status of these
subgroups would reflect the present status.
However, should it happen that--by accident
or by design--the workload mix changes
dramatically, then the model need only be
changed to reflect the new reserved capacity
for these subgroups, and the process will
continue accordingly. This makes it possible
to play 'WHAT-IF' games with various workload
types, time distributions, etc.
or "II.(SEII.VrO CA'ACITV"
MaXIIlIl. U.er level
,'131 or c.plclQ<1
Cllrf<mt UU'r Leval
1111 of cap.clty)
(WHERE GIUIWTH 1& I'RO.lECJED fRDN CURRENT LOMI
OVO ..... , PrgJ .. <"lon Re.erYed" by Service
- -
+_.-.-----._-----+
1/
TRANSACT I ON
- -
TRAIISACTION
V

I HTERACTi VE
BATCH
!lATCH
FIGURE 3
4
HVS C.\P.\C I TV 'MPACT PRtlF ILE
UStR X fOR ONE MONTI'
------- -- -- --- -- ---[7\)--- y,- T -- -- -- rC r T fiT ---- - "" n 'f'" ( !' j' , ''''-'t G T -- -- -- [If)-- ---n r ---- -- -p r ----(l()-- -- -{rr-
'fB HM H l [ (
5 Til T EE M r)()( M
( C B HC H M A H C C A C
R II P AD V P )( V P I' )( P
r H H
C NAT CA AT H A A T C A
E ED l OX 0 l V )( 0 l r X
DAlen
,
9,'188 .312 5"3.l62 .017 . I. (162, 613, 26 I 3.167. 1106 .357 111.121.12:0 .02:4
DAICn
,
1.633 .0'" 316,36'1 .004 e,175,6H .085 474.784,156 .n18 1,195.530 .135 105,7U9,1161 .011
DAICn
,
951 .03_ 711 .002 151,132 .050 686,188,80] ,1)08 953,749 ,108 153,0419,929 .006
1<1\1&11
,

.1100 578,95i!' .000 196,736 .002 7i!'9,O%.Sl0 .1)00 11.125 .ono 162,610,2(,0 .noo
INTERACT
,
12,8117 ,'150 116,498 .073 5,092,261 .049 141,963,832 .0311 2,856.151, .322 43,216.276 .066
INIERACT
,
,,"
,U21 311,813 ,017 351,279 .003 23,353,3'13 ,DIS 91,139 .010 3,620,835 .025
lNnRACT
,
.. .0(1] 11,102 .008 2111,420 .DUl 22,U60,923 ,Oil 21,689 ,002 l, 8111" 327 .006
IN' tRACt
, 11,97h 31,117 ,'18C) 2,7
'
11,62'1
TRANSACT
,
fl'H .167 65.916.847 .639 35/i.l01.S47 . 315,629 .016 3.16'.,164 .08'1
TRANSACT
,
"
.um 9,058 .002 3:;3,547 .003 34,5'18,618 .010 .000 8,9
'
18,108 .000
TPANSACT
,
'"
.n09 3,418 .018 1,691,010 .016 150.671,998 .011 257,0118 .07.9 924,066 .278
TPANSACT
, ,
."flO
3,862 .001 '125,'156 .00" 159.167.326 .001
'" '""
.001
----------- --.. _--------
-----------
28,546 2.316,610 103,2118,961 1.e78,303,8H 8,867,21] 6<'0,0'12,096
_________________________________ -- -- -- -- ----- -- ---- - SYSTEM I DENT If, CAT ,ONo<D - -- -- -- -- -- -- -- .-------- ---- -- -- - -- -- -.- --- -- -- - -- - ---
,
o
,
BAICIt I
BAICII 2
BArCIl 3
BAICII "
INTtRII.CT 1
INTRACT 2
INHRACT 3
,NTERACT 4
lRANSACT I
lRAHSACT 2
lRANSACT 3
TRANSACT "
5'1'SID
,
'-
o
,
o

"
21,0'19
8,985
12,233
'15,5"9

2,212
2,
2,376
60,625
25,931
22,189

104.942
133,1188
,
c-
o
,
,
,
,
.()69
.0<'9
.040
.1,9
.061
.1101
.OU8
.008
.199
.!l85
.073
.265
,
" '-
0
, ,
'- .
o
.113
281,353 .032
.029
.081
309,047 .066
64,222 .014
39,467 .060
63,168 .031
132,185 .459
34,608 f49
55,951 .397
156,113 .519
1 2,"65,283
2
"
,
"
,
,
"

o
16.966.475
22.151,310
15,970,912
51.311.811

1,679.019
687,110
300,794,018
112, flU,HI
a,5U,412
72.132.296
551.869.299
.............
651.IIe,"61
"
,
"
,
,
,
,
.011

.029
.103
.013
.002
.003
.001
.541
.U//
.026
.130
"
" ,
. " , ,
"
, ,
" . , .
326,239,963
6011,909,843
591.232,168

13l1.886,609
42,421,000
i!'3,1118.88"
32,14'1.455
1,166,838,613
51,061,19'1

41e.123.073
.052
.018
.021
.016

.023
.013
.021
.258
.149
.Oll
.113
1 _.602,1110,881
=.=
,
,
'-
,
,
o

o
3,028,911
3.278,916
4.732,395
8,5n.q1)0
3.111.158
1114

519,697
10,920 ,953
'1,961,'199
2,069,032
7.541,316
49.609,525
,
,
'-
,
,
,
,
.061
.066
.095
.17:>
.063
.007
.011
.010
.220
.100
.042
.152
2
"
,
,
,
'-
,
45.103,900
92,2U,92D
1111,990,979
11>5.:>4:>.805
69,012,569
9,211.578
10,313,033
13,410,965
21,113,314
6,658,7l5
1.129,713
1'1.944.243
754
1,169.517,850
. ()67
.036
.041
.059
.045
.018
.051
.019
.511
.1'1"
,293
,505
FIGURE 4
At this paint, the maximum productive CPU
capacity reserved for each subgroup and zone
was translated into TeB seconds. This was
done by comparing TCB time usage with total
CPU time usage by subgroup and zone, and then
applying these actual ratios to the projected
capacities (which were expressed as
percentages of wa 11 clock time). The
resulting new percentages were multiplied by
total possible wallclock time to yield TCB
seconds. All that remained was to use the
regression equations discussed earlier to
establish the maximum main memory and EXCP
levels associated with the newly-defined
maximum productive TCB times, A
three-dimensional profile of productive
system capacity was thus complete_
It was now possible to establish a specific
userls impact on productive system capacity
by comparing measured resource consumption
with the calculated capacity_ Figure 4 is
one example of how this can be portrayed.
The matrix format demonstrates the visibility
and control which the model affords in
analyzing an individual user:
5
a.
b.
c.
separate statistics are
each configuration
identification), service
time frame (zone).
shown for
(system
type, and
the user's load amounts (columns A,
E, I) are direct measurements of the
key diagnostics used in the
methodology. The associated '-PARTl'
fractions (col. B, F, J) represent a
service-by-zone breakdown of the load
within each configuration.
The MAXTCB, MAXMEMY, and MAXEXCP
amounts (col. C, G, K) are the
system's productive maxima as
determined by the reserved capaci ty
concept discussed earlier.
d. the I MAXI variables (col. D, H, L)
depict the user's fractional impact on
the maxima defined above in (c).
This matrix
as the basis
will be used in the next section
for the costing vehicle.
cost-Allocat on Methods
2S
20
- SYS-111:
------ C<'I'-AVE
.. _ .. CURLOADI
--- CURLOAD2
RESOURCES
FIGURE 5
3. FINANCIAL SECTION
As mentioned early in the last section, CPU,
memory, and I/O are evaluated as diagnostics
of total system activity in this method-
ology. Accordingly, overall costs--rather
than mere processing or mainframe costs--were
used as the basis for cost allocation. Three
distribution options were considered:
system-incremental, capacity-averaged. and
current-load (Figure 5).
In the system-incremental option, baseline
costs are allocated only to the existing
workload, whereas system-level delta costs
are passed on only to future users. The idea
is to assess the marginal impact of upgrades,
etc,. on the potential user. The problem is
that true cost comparability (past to
present) and data base accuracy become
questionable.
The capacity-averaged alternative uniformly
allocates both baseline and incremental
costs. It states that maximum utilization
and costs will be estimated at the beginning
of a period a year), and all usage
during that period will be casted at a
constant rate. If the predictions for the
period are very this method can be
most desirable. However, due to the nature
of capital asset planning, it is very likely
that the anticipated levels of cost and
utilization will not coincide as intended.
To the extent that this disparity exists, all
6
usage during the period will have been under-
or over-casted, and retroactive adjustments
will have to be considered. Al any
interim management decisions which were made
may have to be reexamined.
The current-load option also
fixed and incremental costs. However, ln
this case all distribution is made according
to the prevailing user load and system
costs. This means that an individual userls
costs are determined not only by his
workload. but also by the workloads of all
the other users on the system. As the total
load changes, each user is affected. The
same applies to the system costs: each
incremental change in the system cost profile
affects each user to some extent. The idea
here is that true cost absorption is a
non-static situation. Attempts (like those
cited above) to simplify the distribution
mechanism by using a fixed rate or some
limited portion of total cost can potentially
confuse more than clarify the issues. In a
large data center with heavy user activity,
the current-load method offers a dynamic
solution to a dynamic problem. For this
reason, it was used to generate the basic
cost rate described below.
Before proceeding, it is
mention that any of
allocation alternatives can
appropriate to
the above three
be used with the
USER X fOR ONE MOHlll
BAICII
,
.011 .215 .0011 .Inll .2111 .01111 .0211 .211 .01J5 0.9'1 1. 1. 11
nATCIi
,
.OUII .162 .001 .018 .122 .0412 .011 .110 .01J2 1.21 2.711 6.18
/lAICIi
,
.OU2 .?lS .000 .171
"0>
.0(,(, .2117 .0112 1.:>2 1.11
" 6.\ICII
,
.000 ."',0 .000 .000 .168 .0410 .000 .262 .0(10 111.6 1.9'1 28.6
I Nl[RACT
,
.Oll .016 .01J6 .OlQ .0111 .0411 .066 .010 .01l5 0.211 0.83 0.20
I N I [RACT
,
.017 .n15 . OttO .015 .006 .000 .025 .[)06 .01l0 0.3"
0.21
INI[RIIC!
,
./J/J8 .1105 .000 .Oll .006 .001l .006 .1l06 .01l0 1.911 0.92 1. 7q
INIERAG!
,
.1108 .008 .0(/11
1 RANSAGT
,
.161 .110/ lUll . HI) .1192 .011 .08'1 .0(>6 .0111
"'.9
0.,,5 0.6"
1 RANSACT
,
.002 .11011 .000 .009 .000 .0111 .000 III. 3 0.89 12.7
U .... N.<:AI:T
,
.016 .1101 .000 .011 .OJ9 DOll .216 .001 .000 1. 16 3.51 13.11
TMNSACT
,
.001 .002 .000 .001 .0111 .000 .001 .001 .000 50.2 O. ]2 16.2
SYSIO
_______ ._ __________________ ._. ________ ___ SYSI[H 10[Hr I f ICAI ---------------
SlRVla ZONE fCIII'AIITH TCllfACTR H[H,,-HAX H(MPAlUH
DAICII . III .1)6? .0119 .052
aA1Cli .. 0Jl' .1"11 0114 .038
DAICII .029 .16'1 .00'> .027
IMICII .081 .232 .020 .016
1",(!lACI .066 .136 .009 .05"
INTERACT .034 .028 .0111 .023
INIERACT .060 .017 .001 .013
IN1L1IAGI .0]1 .U28 .OU1 .021
1 RANSACT .459 .U56 .021 .258
TRANSACT .7119 .fl15 .011 .7119
fMNSACT .397 .025 .010 .033
TftANSACT .519 ."69 .036 .113
SVSIO
,
,
model. In fact. depending on the purpose of
the analysis, it may be logical to make
separate runs for each method and then
compare the results. Also, the model can
accommodate other distribution concepts. For
example, the three options just discussed
share a common premise: All costs are
completely applied to productive capacity,
with no costs separately apportioned to
system overhead activity; therefore. each
user impl icitly shares in absorbing the cost
of system overhead. However, the methodology
allows the modeler to change this premise and
address system overhead as a separate entity,
apart from the cost distribution system.
Such a change would require only minor effort
to implement_
Continuing with the current-load concept,
total present system cost (C) ;s divided by
total present user load (T) to produce a
basic usage cost rate (R), expressed as
dollars per TCB second:
C / T R.
If a user is not CPU-, memory-, or liD-bound,
then his individual cost (c) is determined by
his TCB load (t) multiplied by the basic cost
rate:
c = t * R.
However, if the user is resource-bound in one
of the three key diagnostic areas, a premium
(p) is established which increases his total
cost by increaSing the basic cost rate:
c = t * (R*p).
The magnitude of the premium depends on how
much the user's boundness adversely impacts
capacity. An example of how this boundness
.071
.nl
.uo
.161,
.029
.009
.005
.fW7
.25"
.012
.091
.091

F I G
MEHfACTR EXCP _HA)( EXCPARTH XCPFACTR HrMY_TCII [XCP_TCIl PRf.HI UH
DUll .067 .0112 .006 O. ,,0 0.59 0.21,
.00'> .036 .168 .(1)6 1.25 1.50 1.a6
.oul .0111 .2Q9 .on9 D.6'1 1.59 1.02
.012 .059 .26'i .016 0.62 0.77 0.J18
.002 .U'.5 .126 .006 0.18 0.63 0.11
.000 .036 .017 .Olll 0.22 0.65 0.14
.000 .051 (J19 .001 0.35 0.91 D.l2
.000 .039 .1t01 \1.111 0.90 0.13
.065 .517 .038 020 2 ..... O.7Q 1. 81
.009 .7116 .012 .009 0.81 0.19 0.611
.003 .293 .011 .Ooq O. ]2 0.39 0.12
.016 .505 .027 .014 0.411 0.36 0.11
,
U R E 6
7
is determined and then translated into a cost
premium is shown in F1gure 6 and described
below_
The basic structure of the premium table
derives from the capacity matrix described
earlier--viz . a breakdown of the three key
diagnostics by configuration, service type,
and time frame. The '-PARTM' var1ables (col.
B. E, H) are tied to the reserved capacity
concept outlined in the prior section: each
value refers to that part of maximum
productive capacity which is allocated or
reserved for the associated service and zone
within the configuration. For example,
column B for Config. A shows that 23.5% of
the total productive rGB capacity for that
configuration is allocated to prime time
(zone 1) batch service. Another 16.2% is
allocated for zone 2 batch service, and so
on. Obviously. each of the I-PARTM
1
columns
adds to 1.0 for each configuration. The
, MAX' variables (col. A, D, G) represent
fractional impact on the capacity allocated
by the '-PARTM' variables.
The purpose of the I-PARTM-' variables is to
normalize the I MAXI variables in order to
ascertain the true relative impact on
capacity. The following example illustrates
how this process works.
Column B for Config. A shows that the
productive TCB capacity allocated for zone 1
batch service is 23.5% of total productive
TCB capacity available for the
configuration. Column A shows that User X
consumed 1.7% of this allocation. The user's
relative impact on TCB capacity here is
therefore 1.7% * 23.5%, or .004--as shown in
column G, called the TCBFACTR. If the Sdme
calculations are performed for columns G and
*------------------------------------------------------------------
* COST WEIGllllNG TABLE
*-...;----------------------------------------------------------------

* THE fOLLOWING TABLE ACCEPTS OR OVERRIOES TIlE PREMIUMS APPLICABLE
* TO HIE BASIC T C BOO L n RATE (fOR INDIVIDUAL USER COST).
* 11"11111'11,
*------------------------------------------------------------------
* SYSIDI ZONE 1 I ZONE 2 I ZONE 3 I lONE 4
*------+-----------------+-----------------+------------+----------
I I
* IICHLOAD*ICIJRAll I
I I
1(lf CPU-BOUND) I
I I


I I
I -OR- TCOlOAD * TCBRATE * 0.5
* A I 1
TCBLOAD*
TCBRATE*
0.25
I I


I TCBlOAO*TCIJRATE* I
I PREMIUM I
I I

IIlf 1/0- OR MEMy-1 I
I IJOUND) 1 1

I I I
I I I * ______ + _________________ + _________________ t __________ --+----------
* 1================

* I TCBLOAD*TCBRATE*
* I 1.3
I
I elf CPU-BOUND)
I -OR-
* I TCDlOAO*TCI)RATE*
* I PREMIUM*I.l
: Ie If 1/0- OR MEM'(-I
* I BOUND) 1
I I
* I
* tBATCH & TRANSACT I
* 1================ I
I I
* I SAME AS fOR I
SAME AS ZONE 1
fOR CONfIG. A
/\
II
SAME AS
CONr IG.
A
n
AS
COHFIG,
A
* I COOf!G. A I I
*------------------------------------------------------------------
H, we find that the user's relative impact on
I/O capacity for this zone and service is
.005 (column I. or XCPFACTR). By comparing
the XCPFACTR to the TCBFACTR. we conclude
that the relative impact on I/O capacity is
125% of the relative impact on TCB capacity
(column K).
On the other hand. if we had merely compared
the' MAX' values (.024 for EXCP and .017 for
TCB).- we would have concluded that I/O impact
was 141% (.024/.017) of TeB impact. This
would have been an oversimplification, since
it would have failed to consider that the I/O
allocation (column H) 1s actually smaller
than the TCB allocation (column B) for this
zone and service. Using the I-PARTM
1
values
takes this into consideration and thereby
normalizes the impacts initially suggested by
the I MAX I values. It thus provides a much
more -realistic portrayal of whether a user is
'bound
l
in a particular direction of resource
and to what relative degree.
The premium table performs this analysis for
each service type and zone of each
configuration. The MEMFACTRs and XCPFACTRs
are compared to the TCBFACTRs in each case
(columns J and K) to determine whether there
is memory-boundness or I/O-boundness, or
FIG U R E 7
8
both. If there is both, the table assumes a
geometric rather than arithmetic relationship
and multiplies the comparison factors
together (column L). The result is a premium
which is then used to increase the user's
basic cost as described earlier. In
this way, any unusual impact on capacity (due
to boundness) is directly translated into
higher cost.
It should be noted here that the capacity
amounts correspondi n9 to the I -PARTM I
fractions were determined by the regression
analysis and reserved capacity assumptions
mentioned earlier. One of the primary
virtues of this methodology is the ability to
change these basic amounts as experience
and/or corporate strategy dictates. If, for
example, it is decided to allocate more of
the existing system's capacity for the
TRANSACT workload and less for the INTERACT
workload, the model need only be changed and
the premium tables will develop values based
on the new criteria.
One additional refinement is made to the
premium before the user's cost profile is
finally generated. This consists of a
cost-weighting table (Figure 7) which
!
,
I1Vli GAPACI fY-CO::nlt4G PROfilE
USER X fOR Ot4E MONIU
COST TCBlnAD. fiAsrRATE PREMIUMCOR OVERRIDE)
------------------------------------------_._--------
SYST[M I DENT I ON=A ---.--------------------------------------------------
SERVICE ZONE TCaLOAo TCD.MAX MEMYlOAO EXCPlOAO tXCP.MAX rRE.."UM COST COSHAflT
DAICII

9.IIB8 _011 14_9111.1111 .014 3.161.406 .024 1.11 11,8110 .Ol6
DAfCII
,
1.611 6. .018 I, .011 1:1. (H
'"
.003
&ATCII
,
'"
.002 5,151.332 .006 951,1'19 .006
"
,"'
,002
BAICII
, ,
.000 196.136 .1100 .000 26.6
,
.OCIO
INfERACT

12,6111 .OB 5.092.261 .01/1 .066 .191 .O'll
INTERACT
, ,,,
.011 357,219 .015 91.139 .025 .208
""
.001
'UU{A(;I
,
"
261.'120 .013 21,689 .006 1.1"
"
.000
INIERACT
,
315.629 .0611 6.611 .059
TRANSACT

2.6116 .161 65.916.641 .165
TRANSACT
,
"
.002 .010 1.5tJ6 .000 12.1
,
.ono
TRANSACT
,
'"
.078 1.691,010 .011 251,046 .218 111l .000
TRANSACT
"
,
.001 "2<;,11<;(; .003 on
.00'
16.2

.000
-------_.--
SVSID 2&.5116 103,21j8.961 8,861.2U 116,075 .U6
__________________________ __ __ __ __ _ ______ __ ________ SYSTEM I DlHT I fiCA T - -- ---------- -- -- -- -- -- -- -- - - - -- --- ----- -- -- - -- - -- -- --
SERVICE ZONE TCBlOAD TCD.WJ< MEMYlOJlD
BATCII

21,0119 .113 16,966,1115
BATCII
,
6.985 ,032 22,151.310
DA1GII
,
12.233 .029 15,910,91:>
BATCIC 4 115.5'19 .081 51,S17,611
INfEMeT

20.4/6 .066 1.326.331
1111[11/1(;'
,
2.?1? ,034 9'15.106
INTERACT
,
2.361 ,060
INfERACT
,
2.316 ,031 661,110
TRANSACT

60.625 .1159
TRANSACT
,
25,931 . 1119 42,130,371
THANS",CT
,
2?,169 .391 14.51B.1I12

,
6U,9511 .519 12,132.296
---------_.
SYSIO 30'1.942 551.669,299

333,1188 657, 118,261
F I
double-checks whether the premium is rational
for the time of day when the service is
performed. For example. Figure 6 shows a
premium of 28.6 for weekend (zone 4) BATCH
work on Configuration A. This is not
realistic, since weekends are traditionally
low-load periods; assessing a cost premium of
29 to such work would unnecessarily skew the
true capacity impact of that workload.
Consequently. the cost-weighting table allows
the modeler to override the premium. In this
case. Figure 7 shows that zone 4 work is
uniformly 'discounted ' at the rate of 75%,
and the premiums are ignored. Zones 2 and 3
are treated in much the same way. Zone 1 is
treated differently for the two
configurations since they are tuned
differently--i.e.. Configuration B is
designed to provide better response time for
interactive work. Accordingly, INTERACT
activity is assessed a 30% additional
Ipenalty' on top of any appropriate premium.
Once again, these choices are entirely up to
the modeler. Any changes made will carry
through the remaining processing which the
model performs.
The final result of this process is a user
cost profile, where cost impact is a function
of capacity impact (Figure 8). The familiar
matrix format shows user load and effect on
MEMY_MAX

.016
.021
.076
,0511
,023
.011
.021

1_9
.Oll
.113
G U R
9
E
EXCPlDAD rxCP_MAX COST COST PART
3,028,'1H ,U61 ,215 22,3110 ,011
3.276.916 ,036 1.68 11.912 .051
".132.19S .0111 1.02 6,503 .021
8.521,460 .059 12,101 .038
.0115 ,110 26.1Dli .090
346,1',J, .036 .14_ 2.35-1
"" 524,019 .051 .320 1,255 . DUll
519,691 ,039 .128
'"
.002
10.'120,'15' ,511 1.111 116,Dge ,HI
11,981.499 ' 746 ,642 21,571 ,061
2,089,032 .293 ,125 11.196 .037
1.5111.315 .505 .168 21,518 ,068
269.221 .35"
56,1176,138 315,296
8
capacity in the three key diagnostic areas
arranged by configuration. service, and
zone. The premiums are indicated (although
they are overridden in certain cases as
outlined above) together with the resultant
cost calculations. The last column.
COSTPART, allows the user to see how the
model is ultimately distributing costs. In
this example, the majority (37.1%) of this
user's cost is coming from zone 1 TRANSACT
activity on Configuration B. The model will
generate this type of output for each user
and for the entire system, thus allowing
total visibility and control over the outcome
of all the assumptions and decisions made up
to this point. Higher level by
zone and service (Figures 9 and 10) then
become a simple task which nevertheless
produces very informative results.
Further information on
be obtained from the
address:
this methodology may
author at the following
Boeing Computer Services
7980 Gallows Court
Vienna. VA 11180
(703) 8174116
ZONE
2
,

S[RVICE
BATCI!
INTERACT
TRANSACT
TCBlOAIJ
127,132
39,3G6
38,098
128,892
333,1188
TCBUJAD
99,901
'10,952
192,634
TCB_MAK
.0'
.05
.0'
.10
TCB_MAX
.0'
.00
.'7
MVS CAPACITY-COSTI NG PRon LE
USER X FOR ONE MONTH
SUMMARY BY TIME PERIOD (lONE)
MEMYlOAO MEMY_MAX EXCPLOAD
411,103,4111 .13 23,407,017
75,963,332 .00 9,898,7311
39,292,105 .02 8,577,933
nO,759,409 .00 16,593,055
",,,,=,,,=,,,,,,,,,,,,:=
==========
657,118,261 58,476,738
FIGURE 9
MVS CAPACITY-COSl'INC PROf I1-E
USER X fOR ONE MONTH
SUMMARY BY SERVICE TYPE
MEMYlOAD MEM''-MAX EXCPLOAD
142,017,703 .0' 211,888,518
16,418,539 .0
1
1 7,'118,601
498,622,018 .18 26,109,619
======"'==== ="'="''''=======
657,118,261 58,476,736
FIG U R E 10
10
EXCP_HAX COST COST PART
.07 211,759 .07
.0'
1
19,02
1
1 .10
.03 20,253 .00
.05 3",260 .11
315,296
EXCP_ "AX COST COSTPART
.03 72,120 .2'
.05 46,562 .15
.111 196,613 .02
315,296