Mainframe Cost Optimization: Full Capacity, Sub-Capacity, and Tailored-Fit

Mainframe cost optimization is a current buzzword being applied to many different processes and techniques. But let’s face it, optimization in this context inevitably means reduction. The general idea is that companies are looking for ways to reduce the cost of their computing infrastructure. And who can blame them? If you can pay less for something, why not do it?

So, what types of things get lumped into mainframe cost optimization? Generally speaking, you can reduce the cost of the hardware and/or the software. Of course, there are other cost aspects, such as personnel, office space, and energy costs, but we will ignore those for today’s discussion.

The hardware is basically a sunk cost. It includes all costs associated with acquiring and maintaining the hardware and peripherals necessary to deploy and run the mainframe workload. Of course, the capacity of the machine factors into the next item, which is software cost, so upfront capacity planning to ensure that you purchase the right mainframe for your needs is required. Additionally, by tuning your workloads to reduce their resource consumption, you can help delay the next hardware upgrade. And that can reduce hardware costs… or at least pushes them into the future.

But over time, the hardware cost pales compared to the software cost. By some estimates, the cost of mainframe software is more than double that of the hardware. The good news is that there are things you can do to reduce software costs.

Optimization and Tuning Techniques

So how can you go about optimizing or reducing the cost of your mainframe software? What are the optimization and tuning techniques that can be applied?

Well, there are many tactics, and we cannot really dive into a detailed analysis of these techniques in today’s article. But let’s briefly outline some of the most popular techniques.

Capping: One approach is to use soft-capping to set the capacity for your system such that you are not charged for the entire capacity of your machine but at a lower, defined capacity. This can reduce your monthly R4HA peak, but the downside is that you are setting limits on the usage of your hardware. But capping can reduce MSU consumption and thereby reduce your monthly software bill.

Workload Adjustment: Another popular technique is to review your monthly peaks and adjust the workload that runs during that window. This does not involve tuning, simply adjusting the schedule for when processes are run. Moving workload around can reduce or change where your monthly peak occurs, thereby impacting the monthly bill.

Tuning: Identifying long-running, resource-consuming programs that run during your peak periods and then identifying ways to reduce resource consumption. This can be done by improving algorithms, removing redundant processes, improving data structures, and if using Db2, tuning techniques such as indexing, rewriting queries, reorganization, and so on.

zIIP Enablement: Any process that runs on a zIIP does not impact your software bill. Anything you can do to take advantage of zIIPs by offloading work from general-purpose processors can reduce costs. For example, look for ways to use features that are zIIP-eligible or possibly convert COBOL programs to Java (Java programs can run on 
the zIIP).

Understand Your Software License Agreements

If your goal is to reduce cost, before attempting any of the optimization and tuning techniques you must understand the software license agreements in place with IBM (and your other vendors).  A license, sometimes referred to as a license agreement, is a legal agreement that authorizes the use of proprietary information, in this case, software.

From an IBM perspective, you will likely have software that falls into multiple different categories, including:

· Full Capacity
· Sub-capacity
· Tailored-Fit

Full-capacity licensing bases charges on the capacity of the entire machine that is available to the licensed program, rather than on just one or more partitions. You pay for the right to use the software as much as desired on the entire machine complex for which it is licensed. The primary way to reduce full-capacity software costs is via a discount when the software is purchased or renewed.

Cost optimization efforts will not have an immediate impact on full-capacity software charges, but it is common for renewal agreements to take into account actual usage. If you can reduce your usage using any of the techniques discussed above, it can help you to negotiate a discount for your next renewal cycle.

Subcapacity licensing bases charges on the partition capacity where the licensed program is used rather than on the machine’s or CPC’s total capacity. There are several different sub-capacity licenses for mainframe software, including variable workload license charging (VWLC) and advanced workload license charging (AWLC). There are others, and there are nuances to each, but, for the most part, they function the same way at a high level.

IBM mainframe sub-capacity software licensing is designed to match software cost more closely with its usage. Some of these models’ benefits include growing hardware capacity without necessarily increasing your software charges, paying for key software at LPAR-level granularity, experiencing a lower cost for incremental growth, and managing software cost by managing workload utilization.

Cost optimization efforts can have an immediate impact on sub-capacity software charges, if by immediate you mean “next month.” You are charged monthly based on the peak rolling four-hour average (R4HA) of the LPARs where the product runs. There is a little more complexity to this, which I have discussed before (here and here) if you are interested in the details. The trick to cost optimization for sub-capacity licensed products is to concentrate on reducing MSU consumption during your peak four-hour periods. This iterative process can be time-consuming, but it can reap financial gains.

Then we need to discuss IBM’s most recent popular mainframe licensing metric, tailored-fit pricing (TFP). The benefit of TFP is that you pay a predictable monthly bill for your IBM MLC products based on your MSU usage for the prior year plus your estimated yearly growth. The amount is locked-in, and you pay that same bill every month (with a possible additional year-end bill if you exceed the estimate).

So, what is the impact of cost optimization efforts for TFP-licensed software? No matter where or when every MSU saved will save on next year’s bill. There are no immediate cost savings as your monthly software bill is agreed upon at the beginning of your contract. That said, the eventual saving is based on the total of your MSU consumption during the year. No more worrying about tracking monthly peaks and tuning the four-hour period for each peak.  Every MSU saved can result in cost savings when your baseline is calculated for the following year.

ISV Software

Although we have not discussed anything besides IBM software in this article, keep in mind that your mainframe software from other ISVs can also benefit from cost optimization techniques. Each ISV has different licensing conditions and policies; some even work with sub-capacity metrics like IBM software. But it is incumbent upon your team to understand these license agreements to determine if and how cost optimization techniques can impact those software offerings.

The Bottom Line

Before attempting to optimize your mainframe software costs, understand your environment, especially the type of software license agreements, your company has in place. Armed with information about your environment, it is possible to optimize its cost!

FIND OUT MORE

Download cloudFrame Relocate Product Fact Sheet

Related Articles

Common Misconceptions About zIIPs

Regular readers of my posts here know that zIIPs are a type of mainframe specialty processor that augments the general-purpose CPUs. Instead of running all

The Benefits of Shifting COBOL Compute

Cost is the primary driver for shifting COBOL compute to less expensive platforms. But once organizations decide that they are going to use shifting COBOL

Next Event

Recent Events