We show you where your MSU come from — and where they actually cost money.
We analyse z/OS environments from your own operational data: performance, cost, security and the factual basis for modernisation and migration decisions. No estimates, no agents on your system — measured data and a clear assessment.
Services
Four questions every z/OS organisation asks
All of them need the same foundation: reliable numbers from your own operation.
The costly misconception
Not every CPU second you save reduces the bill.
Under classic sub-capacity pricing, a single value determines the monthly invoice: the highest rolling 4-hour average. An application consuming 15 % of annual CPU work overnight, while the peak occurs at midday, saves — nothing when switched off.
Conversely, a small application with a sharp load profile can contribute disproportionately if it runs at exactly the wrong moment. To reduce cost you first have to know when load occurs, not only how much.
Scope
More than 150 analyses from one shared SMF data basis
Capacity and cost, workload and goal attainment, processor utilisation, jobs and transactions, database and application view — all from the same body of data, so the numbers fit together.
That is the real advantage: you do not have to reconcile values from different tools. What becomes visible at machine level can be resolved level by level down to the contributor — and the totals still agree.
Capacity & cost
Load peaks, smoothed curve, capacity limits, weights, group limits.
Workload & goals
Goal attainment per service class, delays, response times, prioritisation.
Processors
Utilisation of general purpose and specialty engines, dispatching, overhead.
Jobs & applications
Contributor rankings, runtime profiles, transactions, virtual applications.
Market picture 2026
Leaving the platform is not the norm
Current user surveys paint a different picture from the headlines. That is precisely why an open-ended analysis is the more honest starting point.
All figures come from user surveys with self-selected participants and should be read accordingly. We deliberately avoid the widely quoted “failure rates” for mainframe migrations — none of them can be traced to a primary source.
“Capping systems and running them more restrictively means accepting delay.”
We always state the price alongside the saving. A recommendation without a named trade-off is not a recommendation, it is a sales pitch.
Let's talk about your numbers.
An initial conversation usually clarifies which data is needed and what scope fits your question.