Three TFP Risks Every Mainframe Customer Needs to Manage

By Jacky Hofbauer, Published May 2026, Last update May 2026

If you've moved to Tailored Fit Pricing (TFP),  or you're about to, there are three TFP risks every mainframe customer needs to manage. IBM's pitch for TFP is built around simplicity: no more managing your peak hour, no more capacity planning anxiety, contractually fixed costs. That pitch is largely accurate. But simpler billing does not mean fewer cost levers. It means different cost levers and the ones that matter under TFP are invisible until they bite.

That pitch is largely accurate. TFP is simpler than AWLC in one specific way: the billing mechanism. But simpler billing does not mean fewer risks. It means different risks, ones that are easier to miss precisely because the old alarm (the monthly peak) is gone.

If you have made the transition to TFP, or are about to, here are the three risks that consistently catch organisations off guard. None of them are inevitable. All of them are manageable if you have visibility.

Risk 1:  Flying Blind on Consumption — and Paying for It

The problem

Under AWLC, most mainframe teams had a single number to watch: the monthly R4HA peak. It was crude, but it was concrete. Under TFP, your cost accumulates continuously and every MSU used every day contributes to your annual bill. The question is no longer 'what was our worst hour?' It is 'what are we consuming right now, and is it on track?'

Without a real-time consumption view, you are effectively billing on trust. SCRT reports are monthly snapshots and by the time you see a problem, you have already paid for it.

Why this is harder than it sounds

IBM does provide native monitoring tools that can give you workload-level consumption data. The problem is cost: IBM's monitoring tools themselves consume meaningful MSU. Under TFP, using IBM's tools to watch your consumption adds to the consumption you are trying to manage. It is a self-defeating loop.

General-purpose observability platforms, the tools your organization may already use for application performance monitoring, are not built for mainframe SMF data. They either cannot connect to the data sources that matter (SMF records, DCOLLECT, IMS logs), or they require heavy custom integration to do so.

The solution: mainframe-native observability without the overhead

Zetaly Data Platform (ZDP) was built specifically for this problem. It collects mainframe SMF records continuously, enriches the data, and surfaces consumption by workload, application, and product, all using only 0.2% of mainframe resources. The monitoring overhead does not meaningfully affect the consumption you are measuring.

ZDP dashboards are updated every 15 minutes, giving you a near-real-time view of where MSU is going. For teams that need to identify consumption spikes before they compound, this visibility is the foundation of every other optimization action.

Note: ZDP currently updates every 15 minutes, providing near-real-time visibility into mainframe consumption. For organizations that require more frequent updates, for example, to monitor a critical batch window, ZAC's dashboard capability provides 2-minute refresh rates alongside its workload automation features.

For teams that do not have an existing business intelligence (BI) platform to analyze and visualize the data, Zetaly Service Intelligence (ZSI) provides pre-built and customizable dashboards on top of ZDP, connecting IT consumption data to business context without requiring deep mainframe expertise.

Risk 2:  The Dev/Test Container Ratchet, A One-Way Door

The problem

If your TFP contract includes a Dev/Test Solution container, you are subject to a billing mechanism that almost no one reads carefully before signing: the container ratchet effect.

Under TFP's Dev/Test Solution, IBM defines a container size for your development and test workloads. If the R4HA (Rolling 4-Hour Average) of your dev/test workloads ever exceeds that container size (even once, even during a batch run that nobody intended to be expensive) the container permanently expands to the new high-water mark.

Permanently. There is no mechanism to reduce it back.

How it happens in practice

The most common triggers are end-of-quarter data refreshes (copying production data volumes into test environments), large regression test runs, or a new application rollout where test workloads were not capped before they ran. A single unplanned spike at the wrong moment can increase your dev/test container and your ongoing cost for the remainder of the contract.

Example: A team refreshes their test environment with a full production data copy before a major release. The batch job runs at a higher MSU rate than usual. R4HA exceeds the container. IBM records the new peak. The container expands. The team finds out on their next SCRT review — weeks later.

The solution: visibility before the spike, not after

The ratchet can only be prevented, not reversed. This means the only effective defense is knowing when you are approaching the container boundary before you breach it.

ZDP gives you visibility into dev/test workload consumption at a workload level. If a batch job or test run is trending toward your container limit, you can see it with enough lead time to intervene, defer the job, cap the resources, or reschedule the run.

ZAC provides the automation layer: it can enforce soft caps on dev/test workloads to prevent them from exceeding defined resource limits, automatically, without requiring a human to catch every spike in real time.

Risk 3:  Your Consumption Today Sets Your Renewal Baseline

The problem

Under TFP, your contract baseline is not fixed for life. When your contract renews, IBM draws a new baseline from the last 12 months of SCRT data — the same calculation that set your original baseline.

This creates a compounding dynamic that most TFP customers do not fully appreciate until renewal. If your consumption has crept upward over the contract period — gradually, workload by workload, quarter by quarter — your renewal baseline will be higher than your original one. You will be negotiating from a higher floor.

Conversely, organizations that actively manage consumption throughout the contract arrive at renewal with their baseline still lean. They negotiate from strength.

Why consumption creep happens

The transition from AWLC to TFP often coincides with a period of relief. The peak-management pressure is gone. New projects get provisioned without the same scrutiny. Test environments expand. Applications that were carefully constrained under AWLC now run with less oversight.

None of these individual decisions are unreasonable. Collectively, they ratchet up your average monthly consumption — and therefore your next baseline.

The solution: treat TFP as an ongoing discipline, not a one-time event

Baseline management under TFP is not a pre-transition exercise. It is a continuous practice. The organizations that get the most out of TFP are the ones that maintain visibility and governance from day one of the contract, not just in the months before renewal.

Putting It Together: The TFP Management Stack

These three risks share a common thread: they all stem from reduced visibility. Under AWLC, the monthly peak forced discipline. Under TFP, that forcing mechanism is gone — and you have to replace it deliberately.

The organisations that manage TFP well do so with a clear stack:

• ZDP for continuous SMF data collection and consumption visibility (0.2% mainframe overhead)
• ZSI for teams that need BI dashboards without building their own integration
• ZAC for workload automation, soft capping, and dev/test protection

None of these require a large team to operate. The point of the stack is to replace manual monitoring with automated guardrails — especially important for organisations that have fewer mainframe engineers than they did five years ago.

On observability more broadly: The mainframe observability market includes general-purpose tools from large vendors. Most of these were designed for distributed environments and adapted for mainframe. ZDP is purpose-built for z/OS SMF data — no adaptation required, and the 0.2% resource overhead reflects that specificity. Under TFP, where your monitoring tools contribute to your billed consumption, that difference matters.

Frequently Asked Questions

What are the biggest TFP risks for mainframe customers?

The three most common risks are: (1) consumption creep — costs accumulating gradually without visibility; (2) the Dev/Test container ratchet — a single workload spike permanently expanding your container size; and (3) a rising renewal baseline — letting consumption drift up during the contract period means you negotiate from a higher floor at renewal.
 

Can IBM's own monitoring tools track TFP consumption?

Yes, but at a cost. IBM's native monitoring tools can provide workload-level consumption data. However, they consume significant MSU themselves — which under TFP adds directly to your monthly bill. Purpose-built tools like Zetaly Data Platform (ZDP) provide similar visibility at 0.2% mainframe resource overhead, avoiding this self-defeating overhead.
 

What is the Dev/Test container ratchet in TFP?

Under TFP's Dev/Test Solution, IBM sets a container size for your dev/test workloads. If your Rolling 4-Hour Average (R4HA) for dev/test ever exceeds that container — even once — the container permanently expands to the new peak. It cannot be reduced. The only protection is visibility before the breach and automated resource caps to prevent it.
 

How does TFP baseline renewal work?

When your TFP contract renews, IBM recalculates your baseline using the last 12 months of SCRT data from your current contract period. If your average monthly consumption has increased over the contract term, your new baseline — and your minimum cost floor — will be higher. This is why consumption management during the contract period matters as much as pre-transition optimisation.
 

Is ZDP compatible with existing BI tools?

Yes. ZDP exposes enriched data via APIs, allowing integration with Power BI, Excel, and other BI platforms. For organisations that do not have an existing BI platform, Zetaly Service Intelligence (ZSI) provides pre-built and customisable dashboards directly on top of ZDP, covering ITOps use cases including workload monitoring, WLM objective tracking, and anomaly detection.

Does ZAC still add value once a customer has moved to TFP?

Yes, for two reasons. First, ZAC's workload automation capabilities help reduce cumulative MSU consumption — important for both day-to-day cost management and pre-renewal baseline optimisation. Second, ZAC's soft-capping functionality provides automated protection against Dev/Test container expansion. Teams running lean on mainframe staff particularly benefit from ZAC's ability to enforce consumption policies automatically.

Manage TFP with confidence.

Download our complete TFP guide for a full explanation of how billing works, what your baseline means, and how to stay in control from day one. → Download our ebook " IBM Tailored Fit Pricing, Considerations & Strategies " 

Want to see how ZDP fits your environment? → Talk to a Zetaly expert

About Zetaly

Zetaly builds mainframe FinOps software used by 60+ enterprises to control IBM Z costs. Our products serve customers across both IBM pricing models: Zetaly Automated Capacity (ZAC) reduces Monthly License Charges by 5–20% under AWLC by managing the Rolling 4-Hour Average billing peak in real time. Zetaly Data Platform (ZDP) and Zetaly Service Intelligence (ZSI) give TFP customers near-real-time observability into mainframe consumption — at under 0.2% mainframe resource overhead — with dashboards organized for finance and line-of-business audiences.