Whenever somebody talks about software pricing on the mainframe or tuning to save on their monthly mainframe bill, I always wonder just exactly what they are talking about. Are they aware of all their company’s licensing agreements and all the intricacies therein?
Before we move on, let me just state that the mainframe still makes good economic sense. The total cost of ownership (TCO) for the mainframe, when you add up all of the cost components (such as hardware, software licenses, storage, network, labor, power, and cooling), is similar to or lower than comparable platforms.
So, don’t get me wrong, the mainframe is a great place to run your enterprise applications. And I am all in favor of tuning your code, infrastructure, and environment. But there are many reasons for doing so. Of course, the first reason is to improve the experience of your end users. The more efficiently tuned your software and the system it runs on, the more optimal and pleasant the experience of your end users will be. So, improving your customer experience is always a valid reason for tuning and optimizing your software.
That said, sometimes, the intention of tuning efforts is ostensibly stated to reduce costs. And that is a noble goal. But quite frequently, it seems, people undertaking the assignment to tune for cost optimization do not have enough information on achieving that goal!
What must be understood if you want to reduce mainframe costs by tuning? Well, I think the first thing you need to understand is what comprises your mainframe cost.
At a high level, the cost of the IBM Z hardware must be taken into account. Of course, there is little that you can do to reduce hardware costs once you have purchased your mainframe. That said, by tuning your workloads to avoid reaching the peak utilization capacity of your mainframe, you can avoid the need to upgrade to a new machine (a costly endeavor, indeed). This can be achieved by tuning activity to reduce CPU requirements or by moving workload around to smooth out the peaks. This is something that capacity planners should always be looking at and taking measures to achieve.
Next, you need to understand the mainframe software licenses you have in place. This is not as easy as it might sound. Let’s start with the pricing metrics IBM offers for Monthly License Charge (MLC) products. The IBM MLC products include operating systems, middleware, compilers, and other system software offerings. Examples of MLC products include z/OS, z/TPF, CICS, Db2, IMS, COBOL, and so on. These products have a recurring charge that is applied each month for the right to use the product and also access IBM product support. Fair enough, and so far, not overly confusing.
But you also must know the specific MLC pricing metric used by your organization. And there are multiple, including:
• Advanced Workload License Charges (AWLC)
• Country Multiples License Charges (CMLC)
• Variable Workload License Charges (VWLC)
• Flat Workload License Charges (FWLC)
• Advanced Entry Workload License Charges (AEWLC)
• Entry Workload License Charges (EWLC)
• Tiered Workload License Charges (TWLC)
• System z New Application License Charges (zNALC)
• Parallel Sysplex License Charges (PSLC)
• Midrange Workload License Charges (MWLC)
• zSeries Entry License Charges (zELC)
• Growth Opportunity License Charges (GOLC)
Each of these metrics has specific requirements and conditions for how MSU usage is charged. Some of these metrics, such as AWLC and VWLC, offer sub-capacity licensing. That means the software charges are based on the utilization capacity of the logical partitions (LPARs) on which the product runs. There are many nuances to how this actually works, but the bottom line is that if you can tune workloads that run during a peak rolling four-hour average (R4HA) period for the month, you can likely reduce your monthly bill.
Of course, there are also full-capacity metrics, where all software charges are determined by the full IBM-rated capacity (MSUs) of the CPC in which a product runs. Examples of full capacity-based pricing metrics are PSLC and zELC.
With the sub-capacity pricing metrics listed above, your monthly bill can vary, sometimes substantially, from month-to-month. IBM introduced Tailored-Fit Pricing (TFP) for organizations looking for a predictable monthly bill. The general approach of TFP is to provide a predictable cloud-like pricing option for IBM z software. At a high level, your overall usage for the last year is reviewed, and an estimated increase is factored into the usage. Your monthly bill for the upcoming year is 1/12 of last year’s total usage (plus the increase).
Then we have to consider International Program License Agreement (IPLA) products, which have an up-front license fee and an optional annual maintenance charge. IPLA products include tools for managing Db2, CICS, IMS, and others. To further complicate matters, at least when trying to tune for cost reduction, some mainframe IPLA products can be licensed at a sub-capacity level.
And let’s not forget Container Pricing for IBM Z, where certain defined workloads can scale without impacting other workloads, either within an existing LPAR, separate LPARs, or multiple LPARs.
The Bottom Line
Given this general information, you can see how the choice of pricing metric will impact the efficacy of your tuning to reduce costs. Before undertaking any mainframe cost optimization effort, be sure you understand your organization’s different licenses for IBM Z software. Furthermore, it is essential that you have effective tools for monitoring your CPU utilization, including identifying monthly peaks. Armed with sufficient information and proper tools (including tuning and modernization tools), your chances of achieving cost reduction will increase greatly!