Compuware Supports IBM’s Container Pricing for IBM® Z
Overview: This post will help you build a better understanding of Container Pricing for IBM Z and explain exactly how Compuware is supporting it for our customers.
For many businesses running z/OS, achieving a low-cost and high-capacity development environment for the IBM z/OS platform has been difficult due to the many and continually evolving IBM z/OS software pricing policies. Many customers have struggled with IBM pricing policies that seem to add more administrative paperwork for questionable gain. However, that may change with the recent introduction of Container Pricing for IBM Z.
Compuware has reviewed Container Pricing for IBM Z and discussed it with IBM personnel, both technically and through executive discussions. The following paragraphs review the particulars that affect our Compuware solutions.
The Pricing Problem
Customers found that introducing new workloads or increasing usage of current workloads affected their software bill, causing them to pay much more attention to when workloads were run.
DevTest workloads tend to be sporadic in that resource and CPU usage widely varies from one minute to another. When run during peak times during the day and together with the usual production workloads, large DevTest workloads tended to force spikes and peaks in the R4HA, increasing costs for the customer. This led to a reluctance to move or develop applications on z/OS.
An alternative to get both workloads running at the same time is to run them in separate LPARs, one for production and another for DevTest. This works well to get both workloads executed, but in doing so, the ability to run DevTest cycles during a R4HA low point was lost and the software bill was still higher than desired.
So, over the past few years, IBM introduced many different options and implementations to run workloads and reduce customer costs. These turned out to be administrative nightmares and quite disliked by our customers. Many caused customers to manually change their business runs, adjust when to run programs during the day and also seek alternative software solutions of various sorts. Some examples are:
- Value Unit Edition versions of IBM products, like language compilers, which implemented a “usage type” scenario that somewhat impacted a customer’s IT environment, licensing and affected ISV products.
- A separate LPAR for “IBM Solution Edition” products.
- Moving compilation to a dedicated LPAR that serviced all other workloads on other LPARs. This compilation LPAR could then be given a smaller MSU rating and hence reduce the MLC charge that occurred each month. The customer then determined what resources and how fast these compiles could be executed.
Ultimately, the customer was forced to make business processing choices to reduce the monthly software bill and also deployment choices that they might not otherwise take.
IBM actually announced three different container pricing options. Only one, the Application Development and Test Solution, applies to Compuware. The other two, the New Application Solution and the Payment pricing solution, are not applicable to Compuware products as they are strictly application workload containers.
It’s important to note that IBM works with customers to evaluate the workloads that would be eligible for a Container Pricing for IBM Z solution. This means that IBM will identify and approve every application that runs in the container, including ISV products. ISVs, like Compuware, are then responsible for developing a pricing for their solutions in the proposed container.
To help with ISV pricing, IBM provides an ISV SCRT release that allows ISVs to provide identification of usage of the ISV solutions in the container. The customer must run the ISV SCRT program each month for each ISV. So, if there are ISV products used in the container from four different ISVs, the customer must run four ISV reports each month, in addition to the IBM SCRT report for IBM products.
As previously stated, the DevTest container is where Compuware solutions live, and many customers actively use our solutions 24×7, every day of the year. Our focus is specifically on the LPAR dedicated DevTest containers. Dedicated LPAR containers for ISV products do not require any additional z/OS changes or any need to run ISV SCRT, as there is no impact to the R4HA spikes.
We also evaluated the work that a customer needs to provide for pricing and have concluded that use of the ISV SCRT would add more administrative work to the customer’s workload, which is the one thing we want to avoid.
We have known that most customers run DevTest applications in a dedicated LPAR or set of LPARs. So, from a pricing perspective, any use of the ISV SCRT program is excessive, and we have decided to do without the report.
Instead, Compuware will work with customers to evaluate pricing for their LPAR based DevTest implementations. We believe that this will give our customers the most DevTest cycles they need without the extra ISV SCRT administration.
The value to the customer is they are no longer forced to run Value Unit Edition versions of IBM products, like language compilers, which impact a customer’s IT environment and business processes.
Compuware pricing does not have to change for LPAR based DevTest containers.
See your Compuware account team for any other particulars regarding DevTest containers
For more information on what exactly IBM has been doing with Container Pricing for IBM Z, check out these resources:
IBM Announcement letter (November 14, 2017):
- Describes the Application Development & Test Solution, aka, DevTest
- Applies to all the Compuware solutions
- Provides a way to give DevTest the CPU cycles they need without any dreaded MLC R4HA overage charges
IBM Techdocs Library document (updated frequently):
- Updated frequently as container pricing evolves
- Describes technical content and implementation
IBM DevTest Simplification Announcement letter (October 2, 2018):
- Reaffirms support for DevTest
- Introduces an easy way to evaluate eligible workloads
- Allows IBM IPLA software programs to be eligible in a DevTest container