What actually sets your z/OS software bill

Most companies still on an IBM mainframe know the monthly software bill is large. Fewer know which four hours of the month set it.

That matters because the bill for IBM’s monthly-licensed software on z/OS isn’t based on how much you use the machine over the month. It’s based on the busiest stretch. If you can find what runs in that stretch and move it, the bill comes down. You don’t have to rewrite everything at once to get there.

This post covers how the peak works, how to find the jobs inside it, and the two levers for lowering it.

The bill is set by four hours, not thirty days

IBM’s Monthly License Charge (MLC) software, which includes z/OS itself, CICS, Db2, IMS and MQ, is usually billed on sub-capacity pricing. Capacity is measured in MSUs (millions of service units, IBM’s unit of processing capacity). For each product, IBM looks at the LPARs where it runs and takes the highest rolling four-hour average of MSU use during the month. That one number sets the charge.

The data comes from your own system. SMF records track CPU use continuously, and IBM’s Sub-Capacity Reporting Tool (SCRT) turns them into the monthly report you submit. So the peak is no secret. It’s in a report your systems programmers already produce.

Two consequences follow:

• Quiet hours are cheap. A job that burns a lot of CPU at 3 a.m. on a Sunday, when nothing else is running, may not add a dollar to the bill.
• One busy window is expensive. A job that adds modest CPU at the moment of the monthly peak raises the bill for the whole month.

The rolling four-hour peak is common, but it isn’t the only model. Depending on the vendor and the contract, mainframe software can be priced on the peak, on the machine’s full capacity, on total consumption, or through an enterprise agreement, and third-party software from Broadcom and BMC adds its own terms. The details vary too much to generalize. What holds under every model is simpler: the bill follows the work that runs on the mainframe. Less work means less to license and less to run.

Which jobs are in the peak?

For most manufacturers, distributors and retailers, the monthly peak isn’t the online day. It’s batch:

• Nightly inventory and replenishment runs
• Pricing and promotion feeds to stores, e-commerce and partners
• Month-end close and the reports that go with it
• Extracts to the data warehouse, planning tools and EDI partners

Many of these jobs follow the same pattern: read IBM data, write a file, feed or report. They don’t post transactions or change the system of record. They’re islands, and islands are the easiest thing to move.

To see which ones are in your peak, line up three sources:

1. SCRT reports for the last several months, to find the peak hour each month and which LPARs drive it.
2. SMF records for those windows: job-level accounting (type 30) and workload activity (type 72) show which jobs and service classes were consuming CPU at the time.
3. The scheduler export (Control-M, CA-7, IBM Z Workload Scheduler or similar), to see what each job depends on, what depends on it and when it’s allowed to run.

Rank by share of the peak, not total CPU

This is where most cost exercises go wrong. The instinct is to go after the biggest CPU consumers. But the bill doesn’t care about total CPU. It cares about CPU in the peak window.

So rank every job on two axes:

• Dollars: how much of the monthly peak this job accounts for, and what that’s worth at your MLC and third-party rates.
• Risk: what breaks downstream if the job is late or wrong, and how well anyone still understands it.

The best first candidates sit high on dollars and low on risk: big contributors to the peak with simple inputs, simple outputs and a clear owner.

First lever: move the job in time

If your contract is priced on the peak, the cheapest fix is often a scheduling change. If a job is in the peak only because it was always scheduled at that time, and nothing downstream needs it then, moving it to a quiet window can lower the peak without new code.

Check this before anything else. Also check whether your team already caps capacity (defined capacity or group capacity limits). Capping lowers the bill by slowing work down when the four-hour average hits the limit, which is exactly what you don’t want for time-sensitive batch.

Some work can also run on zIIP specialty engines, which don’t count toward the MSU figure for software pricing. Db2 distributed requests, Java and some utilities qualify. Ordinary COBOL batch generally doesn’t.

Second lever: move the job off the box

When a job can’t move in time because the stores, the warehouse or a partner needs its output by a deadline, rebuild that one job in the cloud:

1. Replicate only what it reads. Land the job’s input files or tables in AWS, Azure or Google Cloud, as a scheduled extract or a change data capture feed. Time the replication outside the peak, or you’ve just moved CPU from one job to another.
2. Rebuild the logic against Postgres or the database you already run, with the same output format the downstream systems expect.
3. Dual-run. Run the new job alongside the old one every cycle and compare the outputs until they match, including month-end and other edge cases.
4. Turn the old job off once the outputs match and the people downstream have signed off. Then the next job.

Everything else keeps running on the mainframe while you do this. You’re taking load off the box one job at a time, with evidence at every step, and each job you move makes a full migration smaller if and when you choose one.

Start around the core

Start with the jobs around the core, not the core itself. Programs that post transactions are bigger, riskier moves, best made once the team and the cloud platform have a track record from the easier jobs. And some systems, like a bank’s deposit core or a government benefits system, aren’t candidates for this approach at all.

Does this apply to IBM i?

IBM i (the old AS/400) isn’t licensed this way, and there’s no rolling four-hour peak. The cost there is licensing and hardware, and usually people: decades of RPG and COBOL batch that fewer people understand every year. The method (inventory the jobs, pick one, dual-run, turn it off) is the same. The ranking is different: by who screams if it’s late, and by whether the person who understands it is still around.

How we run it

We start with a diagnostic: your contracts and invoices, the scheduler export and usage reports on z/OS, or the job scheduler and programs on IBM i. The result is a ranked job list, a migration plan and a baseline of today’s licensing and compute spend. There’s no upfront fee; we’re paid a percentage of the net savings against that baseline, after the cost of running the work in the cloud.

More on the offer: mainframe & IBM i migration. If you’re working through the same question for your cloud bill, the cloud cost diagnostic is the same idea pointed at a different invoice.