Learn the rationale
behind soft capping
to find software savings
PRACTICE SAFE CAPPING
While many organizations are enjoying the benefits of IBM’s sub-capacity pricing model in order
to lower Monthly License Charges (MLC), fewer have embraced the financial opportunity offered
via the optional ‘soft capping’ features – Defined Capacity and Group Capacity. This paper will
explore their rationale and propose solutions to allow their full exploitation.
Background
IBM. The SCRT obtains the peak R4HA value for the month
One of the most costly operating expenses in the datacenter
products from the SMF 89 record to determine the invoice
is the IBM Monthly License Charge (MLC) for software. This
amount for the installation. Using the example of the above
covers the license and support costs of the majority of IBM’s
chart, the invoice would be based on the R4HA peak of just
core technologies such as z/OS, CICS, IMS, DB2, etc.
under 300 MSUs, rather than the usage peak of almost 450,
Previously, this charge was calculated relative to the full
or the full capacity of the machine.
from the SMF 70 as well as the installed IBM software
capacity (MSU/MIPS) of the machine (CPC) where the
software was running. Back in 2000, IBM introduced the subcapacity pricing option and most organizations quickly
adopted this usage-based method of billing.
The usage is calculated via a value known as the Rolling
4-Hour Average (R4HA). This value is calculated and stored in
memory every 5 minutes on each LPAR as the average MSU
consumption on the LPAR over the previous 4 hours. For
reference, the variable is stored by RMF in the SMF type 70
record as SMF70LAC and is illustrated in the example below
('MSU Consumption') by the red line (R4HA).
Capping
While the usage-based method of Sub-capacity Pricing
brought a level of fairness to software billing, sustained high
workload demand could still eventually drive the R4HA up to
the maximum capacity of the machine. There was no
obvious method to limit, for example, a looping job or jobs
driving up the peak demand and resulting MLC invoice.
While capping at the LPAR weight, initial or “hard” capping
was available, this method was (and still is) considered to be
too inflexible for most installations. To
address this, IBM also introduced WLM
Soft Capping support. This feature allows
an installation to define an explicit MSU
limit for a single LPAR known as its
Defined Capacity (DC). A few years later,
support was expanded allow to groups of
LPARs on the same CPC to share an MSU
pool known as Group Capacity (GC).
Either of these “soft cap” options limits
the maximum MLC charge to the DC or
GC value. Further, unlike hard capping,
the instantaneous workload demand can
exceed the cap level with no
repercussions, providing great flexibility
Under the sub-capacity pricing model, the user is obligated
compared to hard caps. If the R4HA exceeds the cap
to generate a sub-capacity report via the Sub-capacity
however, there will be an effect, which is discussed below.
Reporting Tool (SCRT) for each CPC and submit the report to
8300 Woodbine Avenue, 4th Floor
Markham ON Canada L3R 9Y7
Tel: (905) 940-9404 Fax: (905) 940-5308
Email: [email protected]
THE LEADER IN BATCH AUTOMATION
www.thruputmanager.com
PRACTICE SAFE CAPPING
So why isn’t everyone capping?
Soft capping provides excellent financial benefits. While the
R4HA may exceed the soft cap limit, the installation will be
billed based on the peak R4HA OR the peak DC/GC limit –
whichever is LOWER. While IBM will not charge you for
exceeding the limit, they will not allow you to exceed it
unhindered. If the R4HA exceeds the DC or GC limit, WLM
signals PR/SM to cap the LPAR(s) at the level of the DC/GC.
The R4HA may continue to rise (depending on the demand
patterns of the previous 4 hours) but the instantaneous
demand will not be allowed to exceed the limit until the
R4HA is back below the limit. The effect of capping is that
PR/SM will not consistently dispatch the LPAR(s) on demand.
There will be short “time slices” when the LPAR is denied
access to CPU resources. This penalty will be maintained until
the R4HA drops back below the DC/GC level.
In the example, the LPAR was under the effect of capping for
about three hours. During this time, the interval demand will
not be allowed to exceed the cap level, and application
performance and throughput will almost certainly be
affected. For most installations, this impact would be
unacceptable. To avoid this, capping is either set to very high
levels, or avoided altogether.
Consider the table below; let us say we have defined a cap
level that is equivalent to 80% of the CPU capacity. “Cap
utilization” can move from 80% to
CPU% CAP %
90%, even to 99.9% of the limit
and still experience unhindered
80.8%
101%
performance, since the CPU is not
80%
100%
greater than 80% even at the
72%
90%
peak. Once the R4HA exceeds the
64%
80%
cap however your applications
will instantly feel the effects of
56%
70%
PR/SM capping if their demand
48%
60%
remains high, even though the
40%
50%
CPU utilization remains relatively
low. You effectively have no warning.
Where are we today?
Some organizations are exploring creative means to better
exploit soft capping and avoid the potential impacts
described above. In z/OS 2.1, IBM enhanced the Capacity
Provisioning Manager (CPM) to allow for automated control
of DC/GC limits. These updates allow for dynamic changes
on a scheduled basis and/or in reaction to a change in
workload conditions. For example, if the Performance Index
(PI) of a high priority Service Class rises to a specified
(unacceptable) level, the limit will be
automatically raised by a specified
amount.
In the chart on the next page ('Raising
the Cap'), the cap was raised in
response to the R4HA hitting the original
cap level. Application performance is
protected but the MLC bill will now be
based on the R4HA peak. There is
actually no value in reducing the cap for
the remainder of the billing cycle
(monthly) once it has been raised.
Cap level vs utilization level
Percentage of cap level is not the same as percentage of
system utilization. As system utilization grows, applications
can ‘feel’ the effect gradually. Depending on the application,
the slowdown may be felt as low as 70% CPU utilization and
increase gradually until saturation (and timeouts) are
reached. Since it would be pointless to set a soft cap level at
the full capacity level of the machine, the cap will more
logically be set at a lower point to allow for future growth.
ThruPut Manager® Practice Safe Capping
2
Techniques such as this provide
on-demand capacity to meet the
performance needs of applications. Unfortunately, increasing
the DC/GC limit – even briefly – establishes a new highwater mark for MLC billing; defeating the purpose of capping
in the first place.
Manual Capacity Management
As we have demonstrated, holding the line on a strict cap
for an entire LPAR or group with no additional controls can
be harmful to application performance and the services they
PRACTICE SAFE CAPPING
Automated Capacity
Management
While we might know exactly how we
want our systems to react at any given
instant, we simply can’t take in the vast
amount of information available, make
decisions and implement the plan at
machine speed. Even if this were
possible, the environment will very likely
look different a few seconds later and
this change is constant.
The goals of this automated system
should be to maximize throughput and
provide for the organization. On the other hand, raising the
cap surrenders the financial benefit of capping.
performance, limit only non-critical
workloads, and manage the overall demand within the
One technique is lower the multi-programming level (MPL)
of the system by controlling the available batch initiators.
chosen capacity levels to avoid, or at least limit, the entire
LPAR (or LPARs) being capped.
Batch is generally a better choice than online when looking
To achieve these goals, this system should constantly track
for donors to slow things down. Specified classes can be
all of the key utilization and performance variables in order
selected rather than all batch. Halting or draining initiators
to make intelligent decisions at the right times.
during peak periods will reduce the multi-programming level
These should include but are not limited to:
and resulting MSU consumption of the system(s).
Another option is to limit the consumption of executing
•• Full capacity of the machine (physical CPs, memory,
auxiliary storage use, etc.)
workloads with WLM. Fine tuning of Service Classes and
•• Current and trend of CPU utilization on all LPARs
selective use of Resource Groups allows the organization to
•• Current and trend of overall CPC utilization
limit the consumption of any workload (not just batch).
Applying these techniques to lower priority workloads during
•• Available cycles to each LPAR according to CPU weights
and LP assignments
peak periods can lower the interval demand and resulting
•• Business importance and goals of all workloads
R4HA with only the specified workload(s) being affected.
•• Relative achievement of goals (PI) as well as types and
severity of delays
It is not necessary to apply the above techniques to the
highest consumption workloads in order to reduce MSU
consumption. ALL workloads – regardless of priority –
consume MSUs and thus contribute to the MLC bill. A modest
deferral of low to medium priority workloads during the
monthly R4HA peak can lead to substantial savings while
maintaining full service for the higher priority workloads.
•• Current and trend of R4HA on all LPARs
•• Current and trend of instantaneous MSU consumption
on all LPARs
•• Limit of all caps (initial, DC, GC)
•• Group member share of Group Limit (in GC
environments)
The chart on the following page is from an actual z/OS
The limitation of the above methods is that they are
environment that has implemented some of these
manually controlled. You don’t want to permanently run
techniques. Note how the slope of the R4HA gradually tapers
work using under-achieving Service Classes during non-peak
off to “skim” the cap.
periods and you don’t want to drain too many initiators
The lowest priority workloads are gradually slowed down as
either. WLM initiators are a step in the right direction but
R4HA peaks approach, slowing additional low to medium
they would very likely continue to add work to a capped
priority workloads as utilization continues to rise and
system because of the relatively low CPU utilization (per the
increasing the level of constraint. The effect is to flatten out
CPU vs Cap utilization discussion above). To fully exploit this
the R4HA growth via chosen workloads only to avoid the
type of capacity management, it needs to be automated.
potentially dramatic effects of PR/SM capping. As the peak
ThruPut Manager® Practice Safe Capping
3
PRACTICE SAFE CAPPING
passes, the constrained workloads are gradually be returned
to their original Service Classes and Initiator structures.
In short, the system combines features similar to the
automated CPM enhancements that dynamically react to
changes in the system, with the Resource Group and Initiator
functions that can control selected workloads rather than the
entire system.
References
IBM Sub-Capacity Pricing
http://www-03.ibm.com/systems/z/resources/swprice/
subcap/index.html
Shanly, Selby (MVS Solutions). Automated Capacity
Management whitepaper.
www.mvssol.com
Sinram, Horst (IBM). z/OS Capacity
Provisioning Introduction and Update for
z/OS V2.1.
Share Boston, 2013. Session 14210
https://share.confex.com/share/121/
webprogram/Handout/Session14210/
S14210_CapacityProvisioning.pdf
Share Pittsburgh, 2014. Session 15719
https://share.confex.com/share/123/
webprogram/Handout/Session15719/
S15719_Capping%20capping%20
capping%20AllCharts.pdf
Sinram, Horst (IBM). Capping, Capping,
and Capping: A Comparison of Hard and
Soft-capping Controls.
Summary and
Recommendations
The mainframe is the platform of choice for so many
organizations because they know that the availability,
scalability, and security of the platform is unmatched.
Unfortunately the mainframe suffers from a perception that
it is too expensive. While we can argue total ROI with some
success, the ability to substantially reduce monthly operating
expenses via capping should be vigorously pursued.
All of the tools and techniques described in this paper are
available with today’s technology. Automated Capacity
Management provides a method to exploit the financial
opportunities provided by capping while maintaining the
performance and availability of applications for which the
mainframe is so well known. Whether an organization
decides to buy or build, the ability to control costs while
maintaining performance has rarely been so readily available
to System z. Properly designed and implemented, such a
system can meet both the capacity and financial needs of
the organization with little to no manual effort.
Walsh, Kathy (IBM). z/OS Performance:
WLM Support for Sub Capacity Workload License Charges.
WSC Flash 10099
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/
PubAllNum/Flash10099
ThruPut Manager – The leader
in batch automation
ThruPut Manager is the only batch software solution in its
class. It optimizes and automates the total z/OS JES2 batch
workload, managing every job from submission to end of
execution. It complements your job scheduler by ensuring
the jobs it submits are managed as efficiently as possible.
This solution addresses every point of manual intervention
previously required. It overcomes the legacy of a 40-year-old
design, incorporating best practices and modernizing today’s
dynamic and complex mainframe batch environment.
With ThruPut Manager, you can modernize the batch service
you offer and reduce your costs to provide that service. It’s
an industrial strength solution for today’s datacenter.
Only certain highlights of ThruPut Manager have been discussed here. For further information, please contact us as noted on the first page.
ThruPut Manager is a registered trademark of MVS Solutions Inc. Other trademarks are the property of their respective owner.
© MVS Solution Inc. 2015. All right reserved.
ThruPut Manager® Practice Safe Capping
4
O05a