MSU, monthly license charges, the rolling four hour average, SCRT and the specialty engines. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real IBM negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to session sixteen, and to module four. We are on the mainframe now, which is the oldest part of the IBM estate and, I would argue, the most misunderstood commercially. Here is the claim I want to defend over the next twenty four minutes. The mainframe bill is not fixed. It is the most engineerable invoice in enterprise software, and it is also the least engineered, because almost every organisation treats it as a contract to be negotiated rather than as a curve to be shaped. Mainframe cost is consumption economics wearing a licensing costume. Three knowledge checks. Let's begin.
Five objectives. First, price in the right unit, because MSU is the billing currency while MIPS is a hardware rating, so you plan with MIPS and never price with it, and the unit choice alone can shift a headline figure by a third. Second, explain the rolling four hour average, because IBM averages usage over each four hour window and bills the highest of them, so a short spike costs nothing and a sustained plateau costs everything. Third, hold the reporting discipline, with monthly submissions by the ninth day and two years of retained reports, because a single outage past seven days can flip a month to full capacity. Fourth, shape a peak rather than discount it, since a discount prices the waste while a capped peak removes it. And fifth, separate the two engines, because monthly charges and the perpetual side do not move together and a blanket percentage across the agreement hides both.
Four numbers. Three of four, the banks where a single batch window, often only a few hours long, set the monthly peak that priced everything else. Fifteen to thirty percent, the inflation an uncontrolled peak added to monthly charges, and equally the cut available from controlling it. Twenty to thirty five percent, how far billed usage ran above sustained workload once batch windows and capping were tuned, which is headroom you are paying for every month. And eight of ten to fifteen, the mainframe programmes benchmarked where a double digit reduction was available inside the existing platform, with no migration risk at all. The note underneath is the thesis. The bill almost always moved more from peak control than from the discount conversation everybody wanted to start with. Rate is the last lever, not the first.
Guest analyst clip. I describe the mainframe bill as the most engineerable invoice in enterprise software, and the least engineered, and I want to explain why both halves of that are true at once, because it is a genuinely odd situation. The engineerable half is straightforward. Unlike almost any other licence, this one is calculated from a measurement of what your machine did, hour by hour, and your own people control what the machine does. Move a job, cap a partition, offload eligible work, and the number changes. It is arithmetic responding to operational choices, which is a wonderful property in a cost line. So why is it the least engineered. I think it is organisational. Mainframe teams are, quite rightly, obsessed with availability and throughput, and nobody ever thanked them for a lower software bill. Meanwhile the people who own the software bill cannot read a workload profile and would not know which job to move. So you have a lever that requires two groups to be in the same room, and in most organisations those two groups meet once a year, at renewal, to talk about a discount. Which is precisely the wrong conversation at precisely the wrong time.
A lever that needs two groups in the same room, who usually meet once a year to discuss a discount. So let us start with what those two groups are actually looking at.
Two engines, and they behave differently. Monthly license charges cover z/OS and the strategic middleware, CICS, Db2, IMS and MQ, billing as a recurring monthly fee on a usage curve, metered by peak MSU on the rolling four hour average, and the lever there is peak shaping through scheduling, capping and offload. IPLA programs cover the tools and utilities, the Db2 utilities, IMS tools and the monitoring family, billing as a one time charge followed by support that renews until somebody cancels it, metered in value units and sub capacity eligible, and the lever there is capacity right sizing and retiring tools nobody opens. And the note is the part that costs money when it is missed. They do not move together. You can be over consuming badly on the monthly side while paying flat support on tools you no longer run, and one blended discount hides both problems at once.
Knowledge check one. A proposal arrives quoting your estate in MIPS at full capacity. What do you do with it? A, work with it, since MIPS and MSU move together anyway. B, send it back and require MSU on a sub capacity basis, because the unit choice alone can shift the figure by a third. C, convert it yourself using a standard ratio. D, accept it for planning and negotiate the rate down instead. Pause here, and ask which unit the invoice actually arrives in.
The answer is B, send it back. MIPS is a hardware speed rating and MSU is the billing currency, and while they move together they are not identical, so a model built in the wrong unit is a model of the wrong thing. Answer D is the trap this whole session is about, and it is the most professional looking wrong answer available. Negotiating the rate hard, on a number expressed in the wrong unit at the wrong capacity basis, means winning an argument about a figure that should never have been the starting point. You will feel like you did well. The invoice will disagree.
So, the currency. MSU is million service units per hour, the software licensing metric, billed on the rolling four hour average peak under sub capacity pricing, and it is what the invoice is denominated in. MIPS is million instructions per second, the hardware view used for sizing, and the two move together without being identical, which is why you plan with it and never price with it. The charge follows the peak rather than the average load or the size of the machine, and that single fact is why managing the peak is the whole game rather than a tuning exercise at the margin. It covers the strategic middleware, z/OS, CICS Transaction Server, Db2 for z/OS, IMS and MQ for z/OS, none of which you ever own, all of which you pay for monthly on measured usage. And aggregation matters, because the charge is aggregation aware, so grouping machines in one location can move the effective rate, which quietly makes machine placement a commercial question as well as a technical one.
Now the rolling four hour average, five points. The definition, which is that IBM averages usage over each four hour window across the month and bills on the highest of those averages, so a short spike does not set the bill and a sustained busy window does. Which means one batch run can price everything, because a single uncontrolled batch peak set the monthly charge for the whole machine in thirty to fifty percent of estates, regardless of what the other seven hundred and nineteen hours did. The gap is measurable, since billed usage ran twenty to thirty five percent above sustained workload once batch windows and capping were tuned. It prices every product on the curve, so dropping the peak by ten percent reduces the bill for every product priced on it, which makes the lever unusually efficient. And the median result is real, because the median reduction from peak shaping ran around twenty percent, and moving one batch window often saved more than a year of discount negotiation.
Guest analyst clip. Regardless of what the other seven hundred and nineteen hours did. I use that number deliberately, because it makes the shape of this metric visible in a way that percentages do not. There are roughly seven hundred and twenty hours in a month. Your bill is set by four of them. Not the busiest four hours in aggregate, but the four hour window with the highest average, and everything else in the month is, from a billing perspective, irrelevant. Now think about what that means for where you spend effort. Most cost programmes I see try to reduce consumption broadly. Trim here, tune there, improve efficiency across the estate. Worthy work, and on this metric it does almost nothing unless it touches those four hours. Conversely, an intervention that looks trivially small, moving one job to start at two rather than at eleven, can cut the bill for every product on the machine. So the question I would put to a mainframe team is not how do we use less. It is which four hours are we being billed for, and what is running in them. That is a much narrower question, it has a findable answer, and the answer is usually the same handful of jobs month after month.
Not how do we use less, but which four hours are we billed for and what runs in them. A much narrower question, with a findable answer.
Knowledge check two. Your month shows one three hour spike on the fourth, and a steady midday plateau all month. Which sets the charge? A, the spike, because it is the highest point reached. B, the plateau, if its four hour average exceeds the spike's, because the metric averages over four hour windows. C, the monthly average across all hours. D, whichever occurs at month end. Pause here, and ask what exactly is being averaged, and over how long.
The answer is B, the plateau. A short spike costs nothing if the surrounding hours are quiet, and a sustained midday plateau costs everything, because what is billed is the highest four hour average rather than the highest instant. Answer A is the intuition almost everybody arrives with, and it matters because it sends teams after the wrong workload. They go hunting for the dramatic spike, which is visible, alarming and often free. Meanwhile the unglamorous plateau that actually sets the invoice sits there being unremarkable. The target is not your sharpest moment. It is your busiest sustained window.
Now the reporting, because sub capacity has to be reported to exist at all. Without the reporting, the default is full capacity, which on a large machine is the single largest avoidable cost in the mainframe budget, and that is exactly the same arithmetic as module two on different hardware. Monthly submissions by the ninth day, where the Sub Capacity Reporting Tool aggregates measured usage and the peak figure drives the invoice, and no exceptions because the deadline is contractual. Two years of retained reports for audit verification, which is the same retention the distributed side owes, for the same reason: an unproven period is an unclaimed discount. A seven day outage is enough, because a single tooling outage longer than seven days can flip the affected month to full capacity pricing, and on a mid size estate that is a seven figure event. So write an incident playbook, a documented response for any outage past twenty four hours with logged uptime as the audit trail, because most findings trace to reporting gaps rather than to unlicensed software.
Guest analyst clip. Seven days. I want to sit on that number, because of how ordinary seven days is. A tool goes down. It is not a production outage, nothing customer facing is affected, and it sits in a queue behind things that are genuinely urgent. Somebody picks it up the following week. In almost any other context that is a perfectly reasonable response time for a reporting utility. Here it can flip an entire month to full capacity pricing, and on a mid size estate that single month is a seven figure number. So what I ask organisations to do is reclassify the outage. Not raise its priority in a vague sense, but actually change how it is categorised, so that a reporting failure sits in the same bucket as a compliance system going down rather than in the bucket marked internal tooling. And write the playbook before you need it, with the response documented and the uptime logged, because that log does double duty. It shortens the outage, and if a month is ever disputed, it is the evidence that the gap was twenty hours rather than nine days. The difference between those two facts, on paper, is the difference between a conversation and an invoice.
Reclassify the outage so it does not queue behind ordinary tooling. And log the uptime, because that log both shortens the gap and proves how short it was.
So, four ways to move the peak, roughly in order of effort. Shift workload out of the peak window, worth five to fifteen percent of the count, and it is scheduling rather than engineering, which makes moving one batch window often the cheapest money in the estate. Offload to specialty engines, where eligible Db2, Java and XML work moves to zIIP engines and leaves the billable general purpose count, worth ten to twenty five percent at higher effort. Cap with defined and group capacity, limits that hold partitions below a chosen level so the average cannot drift, worth five to ten percent, and set with care rather than enthusiasm. Decommission what nobody runs, worth three to eight percent, and it is the same uninstall discipline that lowered a PVU count back in session nine. And cap the meter, never the resilience, so you cap non critical partitions and keep headroom on the critical path, because a regulator expects capacity to exist even where the meter should not be paying for it at peak.
And then the other engine, where IPLA looks cheap because the licence is perpetual. The cost lives in the annuity, because support runs near twenty percent of the one time charge every year and renews automatically until somebody cancels it, which is session four appearing again on different hardware. Tools nobody opens keep billing, and that has run eight to fifteen percent of the annual support line, paid on monitoring and utility families no team has used in years. So reconcile entitlement to actual use, asking which tools are installed, which are used, and which are simply still on the invoice from a decision taken two hardware generations ago. Elect Value Unit Edition where eligible, moving eligible programs to sub capacity so they bill on consumed capacity rather than on the whole machine. And never take one blended discount, because a single percentage across the agreement hides both engines, so each side needs its own reconciliation before any rate is discussed.
Knowledge check three. IBM opens a mainframe renewal with a discount on the total. Where should your work start? A, on the discount, since that is what is on the table. B, on the peak, shaping it first, because a discount prices the waste while a capped peak removes it. C, on a hardware refresh, to lower the ratings. D, on moving to a consumption model immediately. Pause here, and ask whether a discount changes the quantity or only what you pay for it.
The answer is B, shape the peak first. The bill almost always moved more from peak control than from the discount conversation everybody wanted to start with, which is why rate is the last lever rather than the first. Answer D is next session's entire subject and it is premature here for a specific and important reason. A consumption model prices from your recent consumption. So if you move before you have shaped the peak, you lock the unshaped number into the baseline, and every reduction you would have made afterwards becomes a saving you handed to IBM. Optimise first, sign second, and we will spend twenty four minutes on exactly that next time.
Guest analyst clip. Rate is the last lever, not the first. I know that is an unpopular thing to say to a procurement team, because the rate is the part of this that belongs to them and the peak belongs to somebody else. But look at what the two levers actually do. A discount prices the waste. A capped peak removes it. If your billed usage is running twenty to thirty five percent above your sustained workload, and you negotiate ten percent off the rate, you have made the overspend slightly cheaper and left the overspend entirely intact, permanently, for the length of the agreement. Whereas if you spend a quarter shaping the peak first and then negotiate the same ten percent, you are applying it to a smaller number and you keep both benefits. There is also a sequencing argument that I think is underappreciated. Once you have shaped a peak, you know something IBM's proposal does not: you know what your estate actually needs. And walking into a renewal knowing your own real number, rather than the number your unmanaged workload happened to produce, changes the conversation more than any negotiating technique I could teach you.
So, running a mainframe bill like a curve rather than a contract, five things. Review the report monthly, and treat every new high on the four hour average as a cost event to investigate rather than a capacity statistic to note. Know your peak makers by name, meaning which jobs, in which windows, on which partitions, because you cannot move a peak you cannot attribute. Submit by the ninth and retain for two years, with an incident playbook for any outage past twenty four hours, because the reporting is the eligibility rather than a report about it. Hold caps on the non critical tier, so test, development and discretionary partitions take the defined limits while the critical online path keeps its headroom. And run the two engines separately, with a monthly charge reconciliation and an IPLA tool reconciliation, because they move independently and a blended number hides both.
Three sentences. MSU is the billing currency and MIPS is a hardware rating, the monthly charge follows the peak rather than the average or the machine size, and quoting an estate in the wrong unit at full capacity can shift a headline figure by a third before anybody negotiates anything. The rolling four hour average bills the highest four hour window in the month, so a short spike costs nothing while a sustained plateau costs everything, and one uncontrolled batch window set the monthly charge for the whole machine in thirty to fifty percent of estates. And sub capacity exists only if it is reported, with monthly submissions by the ninth day and two years of retention, while a single tooling outage past seven days can flip a month to full capacity, which is why peak shaping and reporting discipline both come before the rate conversation.
Homework, about an hour, and this one has an unusually good return. Find the peak window, by pulling the last three months and identifying which four hour window set each month's charge, and if it is the same window each time then you have just found your project. Name the jobs inside it, asking which workloads run in that window and whether any of them could run two hours later without anybody noticing. Check the submission record, asking whether the last twelve monthly submissions were made by the ninth day and whether somebody can produce the retained reports for the last two years. Ask about caps, meaning whether defined capacity limits exist, on which partitions, and when they were last reviewed against the workload they are meant to bound. And list the IPLA tools, every tool carrying annual support with a yes or no on whether anybody opened it this year, because that column is worth eight to fifteen percent of the support line.
Five guides. The MSU and MIPS reduction guide carries the reduction matrix by lever and effort, the submission deadline and retention, and the seven day outage that flips a month. The mainframe software licensing optimization guide covers peak shaping as the primary lever, why one batch window prices a month, and what misconfigured reporting leaves on the table. And the CIO advisory explains why rate is the last lever, what an uncontrolled peak costs, and how the two engines behave differently from one another.
The MSU calculator gives you a directional model of the peak against the bill, which is useful for sizing the prize before you commit anybody to a programme. And the banking guide covers capping in a regulated estate, managing the meter rather than the resilience, and mapping the peak makers first. Next time, Tailored Fit Pricing: the consumption models, when they beat monthly charges, and how to run that comparison honestly rather than the way it is usually presented. See you there.