Home/Performance & Cost
z/OS performance and cost analysis
From your operational data we measure where load is created, where it becomes cost-relevant and what can be capped without losing throughput — and we tell you what it costs if you do.
Starting point
Capacity is measured. Cost is calculated. These are not the same thing.
Most z/OS sites know precisely how busy their machines are. Far less often is it known which share of that utilisation actually enters the invoice — and which workload simply happens to run at the wrong time.
Under classic sub-capacity pricing the highest rolling 4-hour average of a month is billed. Anything outside that window matters operationally but is cost-neutral. That distinction is the core of our analysis.
Areas of investigation
What we look at
Six areas that contain potential or risk in almost every environment.
Capping & capacity limits
Capacity limits per partition, group limits, distribution via the weights, share of capped intervals, effect of soft versus hard capping.
WLM policy and goal attainment
Goal attainment per service class, execution velocity, response time distribution, use of the priority levels, homogeneity of workload within classes.
Contributors at job level
Rankings by hour and interval, elapsed versus CPU time, I/O profiles — down to the single job that triggers a capping event.
Specialty engines
Utilisation of specialty engines, crossover onto general purpose processors, view per service class — the basis for deciding whether additional capacity is economically justified.
Dispatching and hypervisor
Distribution and parking of logical processors, operating system versus partition utilisation, capture ratio, hypervisor overhead, consistency of weights.
Batch window and scheduling
What runs when, and how much of it falls into the cost-relevant window? Frequently the most effective lever, because it requires no technical change at all.
Analysis
More than 250 analyses — and an assessment with them
We work with our own analysis tool. It does not run alongside the live system; it reads operational data that has already been written, condenses it and provides time series that can be compared across weeks and months.
Resolvable level by level
From the machine via the partition and the service class down to the individual job or transaction — without resetting the time range.
Explained, not just displayed
Below every analysis is a note on what it shows and what to watch for. That keeps values interpretable for people who do not see them daily.
Recurring reports
Any set of analyses can be bundled and generated as a PDF on a schedule — to verify the effect after a change.
What you end up holding
- An assessed sequence of results — every analysis with professional interpretation, not just the picture
- Concrete threshold proposals for capacity limits, group limits and weights
- Named trade-offs — which workload would be delayed, when, and under what condition that is acceptable
- A staged implementation plan rather than one large switch-over
- WLM findings: goals set too weakly or unattainably, unused priority levels, inhomogeneous service classes
- A results workshop including a fundamentals section, so everyone speaks the same language
Subsystem analysis
CICS, Db2 and MQ — the layer where the time is actually spent
The partition view tells you when load occurs and what it costs. Why it occurs is usually decided one layer down: in the transaction monitor, in the database and in messaging. We evaluate these layers on the same time axis as the system data — so findings can be placed side by side instead of being interpreted one after another. Set out below are CICS, Db2 and MQ; we evaluate IMS and WebSphere Application Server by the same method.
Transaction monitor
CICS analysis and tuning
A transaction's response time splits into two parts: the time the task was dispatched by the monitor, and the time it spent waiting. What matters is the gap inside the first part — dispatched, but without CPU. That is exactly where CICS tuning meets operating system tuning: a capped partition, a page-in, a competing address space.
Hence the sequence IBM has stated unchanged in the Performance Guide for years: tune disk, network and the whole operating system first, the individual region afterwards. Raising the MaxTask limit while the partition is capped only moves the queue further inside.
- Wait profile per transactionfile and storage access, journalling, inter-region coupling, terminal and sockets, syncpoint, locks — named causes instead of one catch-all "remaining wait time".
- Delay before the first dispatchseparated by MaxTask limit and transaction class. This makes queueing before the first dispatch visible without relying on region statistics.
- The main TCB as a saturation measurethe ratio of CPU time to dispatch time, plus the open TCB pools and the waits for a free TCB.
- Threadsafe assessmentmode switches between TCBs are the classic overhead driver. In one IBM measurement series throughput rose from 218 to 337 transactions per second after the conversion.
- "Database slow" or "no free thread"?The wait for a database thread is reported separately. These are two entirely different findings calling for two entirely different measures.
- Program level, not just transaction IDcall frequency, CPU time per call, load times and storage high-water marks — before a region runs short on storage.
- Response time against the WLM goalin the same chart. It answers directly whether a CICS problem is in fact a policy problem.
Database
DB2 analysis and tuning
A substantial share of a database transaction's time is spent outside the database code: waiting for a dispatch, for a log write, for a page that should still have been in the buffer, or for a coupling facility response. SQL tuning cannot reach these shares at all.
What they do have is leverage: SQL tuning improves one statement, system tuning affects everything that passes through the subsystem. The reverse holds too — a single misconfigured system parameter degrades every transaction simultaneously.
- Reading buffer pools correctlythe hit ratio on its own is worthless. A 96 % hit ratio can still mean thousands of read I/Os per second — only together with the read rate does the ratio become assessable.
- Prefetch and thresholdsdisabled prefetch and buffer pool thresholds being hit are silent CPU cost drivers that show up in no response time figure.
- Loggingwaits for an output buffer point directly to undersized buffering; reads from the archive indicate backout problems.
- Lockingdeadlocks, timeouts and lock escalations across the daily profile — plus the suspension rate as an early indicator that rises long before the first timeouts.
- Threadsutilisation against the configured limits and the queueing that starts when they are reached. This is the counterpart to the MaxTask limit in CICS.
- Metrics that must be zerofailures in the internal pools and thread queueing. Any deviation from zero is a concrete parameter task, not a matter of interpretation.
- Data sharingsynchronous coupling facility requests occupy the processor for the full duration of the round trip. Service time there is processor cost, not just response time — which is why coherency traffic and re-read hit rates belong in every cost assessment.
- Speciality engineshow much of the database load is offloaded today, and what is holding the offload back.
Messaging
MQ analysis and tuning
MQ is rarely the cause and almost always the place where a problem becomes visible first. A queue that grows reliably reports that something behind it is processing less than arrives at the front — it just does not say where. That is precisely why we evaluate MQ on the same time axis as the partition, the transaction monitor and the database: only side by side does a rising queue depth turn into a named bottleneck.
The second reason is cost. Persistent messages force log writes, and every delivery consumes processor time in several address spaces at once — in the queue manager, in the channel initiator and in the calling application. In chargeback that share often shows up only partly. We report it in full.
- Buffer pools judged the way Db2 buffer pools areHit ratio only together with the read rate. What decides the case are the thresholds: write thresholds reached and critical thresholds belong in the assessment, not in a footnote.
- Counters that must be zeroSynchronous writes, short-on-storage conditions in the buffer pool and critical thresholds reached. Any deviation from zero is a concrete parameter task — the same logic as in the database.
- Logging as the real throughput ceilingWaits for a free log buffer affect every writer simultaneously. Reads served from the archive rather than from the buffer or the active log stretch backouts by orders of magnitude.
- Queue depth as a daily profile, not a snapshotA peak value says little. How long a queue stayed in which band, and how quickly it drained again, says everything about the processing headroom.
- Puts against gets, per queueThe balance shows immediately whether the consuming side is keeping up — and whether additional instances would help at all or merely move the contention.
- Consumer capacityHow many consumers were actually active, how evenly they shared the work, and whether processing is held up at the queue or in the application behind it.
- Indexed queuesA targeted get by message or correlation identifier without a matching index scans the entire queue. Processor cost then grows with the depth — the most expensive silent finding in MQ.
- Two sets of counters against each otherQueue manager statistics and application accounting records have to agree. Where they do not, work is running past the instrumentation — and will be missing from every chargeback later.
Scope of analysis
More than 250 ready-made analyses — and why there are that many
A single metric rarely proves anything. A finding becomes solid only once it can be confirmed from several directions: from the capacity view, from the workload view, from the subsystem and from chargeback. That is what our worked-through body of analyses is for — not a catalogue to browse, but a toolbox from which the ones that fit your question are drawn.
Capacity and billing
The largest block. Rolling four-hour average against the agreed limits, group view across several partitions, weights and guarantees, every capping mechanism side by side, capture ratio and the share that cannot be attributed.
Partition and processors
Utilisation by processor type, shared against dedicated cores, the ratio of logical to physical capacity, HiperDispatch with its three levels and parking — the layer at which every WLM decision finds its ceiling.
Workload and WLM
Service classes against their goals over time, goal attainment and delay causes, consumption per class and period, dispatch placement — and the cross-check of whether a goal is achievable at all.
Specialty engines
Offloaded work, the share that spilled back onto general purpose processors, and whether additional capacity pays for itself. Reported separately, because this is where the money is.
Jobs, batch and rankings
Consumption and elapsed time per job and started task, elapsed time split into computing and waiting, the night window with its drivers, sort load — and rankings by every quantity that can be charged for.
CICS, Db2, IMS, MQ and WebSphere
Response time and wait profiles in the transaction monitors, buffer pools, logging, locking and accounting records in the database, queue depth, puts against gets and consumer capacity in messaging, plus the Java runtime environment.
Tailored Fit Pricing
A block of its own, because under this model the questions change: no longer the monthly peak, but consumption across the year, the baseline, and which share enters the measurement at all.
Application view and data quality
Consumption by business application rather than by technical address space, peak contribution and what-if calculation — plus checks on the data itself: gaps in the measurement interval, shifted timestamps, incomplete records. A finding is only as good as the data beneath it.
You do not get 250 charts, you get the handful that answers your question — derived transparently, with the path documented. The rest stands ready in case the answer raises a new question.
Pricing models
Your contract determines which optimisation works at all
We model what you actually pay for — otherwise the calculation misses reality.
Sub-capacity / R4HA
The highest rolling 4-hour average per partition and product in a month is billed. Levers: peak shifting, capping, weights.
Tailored Fit Pricing
Under the Software Consumption Solution, actual consumption across the year is what counts. The economically decisive moment is the baseline negotiation — optimisation belongs before it, not after.
Full capacity
Under the Enterprise Capacity Solution there is no reporting obligation; the lever shifts from peak management to capacity sizing and workload placement.
We are not a licence reseller and do not negotiate contracts. We provide the measurement basis you or your licensing partner can negotiate with.
FAQ
Questions about performance and cost analysis
What data do you need from us?
The operational data your system writes anyway, over a contiguous period of ideally two months, plus the active WLM service definition. Which components are needed in detail depends on the question and is agreed in the initial conversation. Preparation requires neither an agent nor an installation in the running system.
Does data have to leave our premises?
No. The analysis tool can run entirely inside your data centre. Alternatively we work from an anonymised extract. What is practical for your environment is agreed up front and recorded in writing.
How long does an analysis take?
Effort depends on scope and the number of partitions. Data collection runs at your site across the agreed observation period; analysis, assessment and preparation follow and lead into a results workshop. We give a reliable frame after the initial conversation.
How much can be saved?
We can only answer that responsibly once we have seen the data — and we deliberately avoid blanket percentages. What matters is the ratio of average to peak load in your environment and whether your peaks sit in shiftable time windows. Both are directly measurable from your data.
Do you also do CICS, Db2, IMS, MQ and WebSphere tuning?
At system level, yes. For CICS we break the response time down into its components and name the wait types, examine queueing before the first dispatch, the utilisation of the main TCB and the effect of a threadsafe conversion. For DB2 we look at buffer pools, prefetch, logging, locking behaviour, threads, storage and — under data sharing — coupling facility access. What this does not include is SQL tuning, access paths and index design; those stay with your database development team. For MQ we look at buffer pools and their thresholds, logging, queue depth across the day, the balance of puts against gets, and consumer capacity. The same approach applies to IMS and the WebSphere Application Server: break the response time into its parts, name the wait types, hold region and runtime limits against actual demand. We do, however, tell you where the system view connects to the application view.
Our queues are filling up — is that an MQ problem?
Usually not. A growing queue is first of all a statement about the consuming side: less is being processed than is being put. So we check, in this order, whether anything is consuming at all and from how many instances, whether consuming is needlessly expensive — a targeted get by message or correlation identifier without a matching index scans the whole queue, so processor cost grows with the depth — and only then whether something is missing in the queue manager settings. The answer regularly lies in the application behind the queue, not in MQ.
Does this replace our monitoring?
No. Monitoring answers “what is happening right now”. We answer “what happened structurally over weeks, what did it cost and what follows from it”. The two complement each other.
What does your curve look like?
Send us your question — we will tell you which data answers it and how we would proceed.