Understanding Mainframe MLC Software Pricing is No Easy Task

BY

Understanding-Mainframe-MLC-Software-Pricing

As a mainframe professional who is responsible for optimizing the systems, data, and costs of your company’s mainframe, you know how complex things can be. Sorting out how to reduce costs can be cumbersome, exceptionally so, if your team is unfamiliar with the inner workings of how the cost of monthly license charge (MLC) software is calculated. But don’t feel bad – you’re not alone.

Probably around 20% of those trying to manage MLC costs do not have a good understanding of how the charges are calculated. Another 60% think they do, but have it wrong. I was in this 60% group before I really studied the calculation process. The final 20% do understand how the combined software stack, across multiple LPARs, with a moving four hour rolling average (4HRA) impacts your IBM MLC bill.  Congratulations to you!

In his White Paper, 10 Steps to Reducing Mainframe MLC Costs, David Wilson of SZS Consulting states, “Very few people really understand how costs are derived in the mainframe environment. MLC is the only component with a realistic list price but with over 50 different licensing metrics, most users delegate calculating the price to IBM. With little understanding of the underlying structure (other than more MIPS = more cost), what hope is there to manage the cost down?”

As with any such complicated calculation, there are “it depends” situations; but basically, you take the 4-hour rolling average of all the MSUs consumed by summing up all the software that is running on an LPAR, including MLC products, batch work, other vendor tools, etc…all of it. The highest one-hour amount for the month then determines your MLC bill. If you have multiple LPARs running the same MLC products, you add up the amounts for hour 1 on each LPAR, hour 2 on each LPAR, etc., for each hour in the month and the highest hourly period peak of these hourly sums determines the MLC bill. (You really need a tool to do this properly.)

To make understanding these costs even tougher, yearly price increases are typical for MLC products and now a new pricing model, Country Multiplex, is being rolled out by IBM. (Did I mention that using a tool to do these calculations can greatly simplify this complexity? See Cost Analyzer)

Again, David Wilson states, “If you want to manage something, then you need to understand what influences it. However, most organizations regard MLC charges as an art, not a science, and they lack the ability to dynamically calculate MLC cost themselves.”

Here’s what you should do right now: study and understand the MLC calculation process for your shop. Identify what is driving the peak 4HRA and model proposed actions so you can see if they will make a difference. Then attack the things that will drive down your MLC cost with dynamic capping, workload tuning, subsystem placement and workload placement tactics. Read David Wilson’s white paper.

 

Related posts:

12th Annual Mainframe Survey Results


The BMC annual mainframe survey is a key indicator of the future health and viability of the mainframe—and this year’s report busts 5 common myths about the platform.

Download Now ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post


David Schipper

David Schipper

Dave Schipper is a lead product manager at BMC Software responsible for the BMC Subsystem Analyzer for zEnterprise (Subzero) and the BMC Database Solutions for IMS. As product manager, Dave works with customers to understand their needs and uses that information to set product directions and prioritize new product capabilities as he interfaces with the development teams. Dave has over 30 years of experience with mainframe systems and has been in product management for over 20 years.

Dave has Bachelor of Science degrees in Computer Engineering and Applied Mathematics from the University of Michigan as well as a Master of Science in Computer, Information and Control Engineering from the University of Michigan.