IBM Systems Magazine, Mainframe - July/August 2018 - 50
Container Pricing for IBM Z brings predictability to cost
ontainer Pricing for IBM Z* allows IBM to deliver a revolution in the
pricing of qualified solutions on z/OS*: pricing that's not affected by the
cost of unrelated software or whether the solution runs during a peak time.
IBM has designed a set of solutions around the framework, each of which targets
a key requirement of z/OS clients.
Andrew M. Sica
is a senior
Pricing and the
is a content
designer for z/OS.
Pricing for IBM Z?
Container Pricing for IBM Z is
a framework that allows z/OS
and the Sub-Capacity Reporting
Tool (SCRT) to understand
the characteristics of specific
workloads, such as which
resources the workloads are
consuming and the program
products that they're using.
Critically, this capability is
available without the monthly
"tagging and tracking" that's
associated with past offerings.
IBM provides a set of solutions
that take advantage of the
framework. A key characteristic
of each of the Container Pricing
solutions is that the application
or workload doesn't directly
impact the traditional rolling
four-hour average (R4HA)
because the metered container
50 // JULY/AUGUST 2018 ibmsystemsmag.com
workload is always subtracted
out and reported separately by
SCRT. This allows IBM to deliver
pricing that's predictable and
relevant to the solution without
impacting the cost of unrelated
software in a way that's not
affected by whether the solution
runs during a peak time.
One thing to note: Despite
its name, Container Pricing
for IBM Z has little to do with
Docker or any sort of technical
In this article, we'll explain
the value of two solutions that
take advantage of the Container
Pricing for IBM Z framework-the
Application Development and
Test (DevTest) solution and the
New Application solution. We'll
describe the problems they solve,
as well as how they exploit new
technology in z/OS and SCRT.
The DevTest Solution
The R4HA model has brought
value to z/OS clients; however, it
has some obvious problems. One
of those problems is that it causes
people to excessively focus on
that peak R4HA value and, under
business pressure, try to find ways
to reduce it, sometimes to the
detriment of other interests.
Different techniques are
employed to reduce the R4HA,
such as LPAR soft-capping or
restricting access to test systems.
Whatever the approach, it typically
brings a lot of non-productive time
spent managing the environment
to control costs, and it frequently
constrains resources. Development
and test often suffers, because
z/OS environments are restricted
during peak times to ensure that
they don't drive up the monthly
license charge (MLC) bill.