① Product · BMC
AMI Ops, the suite formerly known as MainView, watches and tunes your z/OS estate. BMC prices it on MSU, often under consumption terms, where the conversion ratio and the true up are where the cost quietly moves.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →BMC AMI Ops, formerly MainView, is BMC's systems management and monitoring suite for z/OS. It gives operations centralized visibility and automated response across the operating system and its subsystems, with family members covering CICS, IMS, networks, and core z/OS monitoring. The MainView name still appears on installed estates and older contracts, but BMC now markets the line as AMI Ops. Its competitive set is IBM OMEGAMON, delivered within the IBM Z Monitoring Suite, and Rocket TMON.
AMI Ops is licensed on MSU based capacity. Many estates now contract under BMC's zConsumption Licensing, where you pay on the prior year's actual z/OS MSU consumption and true up any overage at year end, while older agreements remain on fixed MSU capacity. The metric tracks machine capacity, not the number of monitored systems or consoles. Consumption conversions have commonly rested on a stated MIPS to MSU ratio tied to the machine models in place when the order was signed.
| Element | How AMI Ops is treated |
|---|---|
| Metric | MSU based capacity |
| Model | zConsumption Licensing (zCL) or fixed MSU |
| Reconciliation | Annual true up on consumption overage |
| Conversion basis | Stated MIPS to MSU ratio, e.g. 8.2 to 1 |
| Cost driver | Licensed or consumed MSU, not console count |
Directional summary. Model, ratio, and true up terms depend on the specific BMC agreement.
Three drivers set the AMI Ops number. Consumed or licensed MSU, because the metric follows capacity, so estate growth and peak shifts lift the charge even when the monitoring scope is unchanged. The MIPS to MSU conversion ratio, because a ratio fixed to older machines can drift and inflate the consumption baseline as hardware changes. And bundling, because AMI Ops is frequently sold inside a larger BMC AMI agreement where the individual line cannot be benchmarked against alternatives. Consumption pricing rewards a flat profile and punishes an uncapped true up.
The recurring traps live in the consumption mechanics. An uncapped annual true up turns a single high consumption year into a higher recurring baseline. A MIPS to MSU ratio carried forward without review, the classic being a figure such as 8.2 to 1 tied to retired machines, can overstate consumption against current hardware. And scope creep, where AMI Ops components spread onto systems the entitlement never covered, widens the basis quietly. Independent validation of the consumption report and the conversion ratio against actual capacity is the defense, the same discipline we bring to BMC contract review.
The structural lever is displacement: IBM OMEGAMON and Rocket TMON both displace AMI Ops, and a costed, time bound study resets the conversation even when the intent is to reprice. The consumption levers are a true up cap so a single peak year cannot become a permanent floor, and a renegotiation of the MIPS to MSU ratio in good faith as hardware changes, language BMC contracts commonly anticipate. The contract levers are uplift caps and unbundling the AMI Ops line from the wider BMC AMI agreement so it can be benchmarked. We model the consumption baseline, test the ratio, and build the displacement math before the renewal sets the next term, the core of our BMC work.
BMC AMI Ops is BMC's z/OS systems management and monitoring suite, and it was formerly branded MainView. The rebrand runs across the family, including AMI Ops Monitoring, AMI Ops for CICS, AMI Ops for IMS, and AMI Ops for Networks. Functionally it monitors, tunes, and automates response across the z/OS estate, competing with IBM OMEGAMON and Rocket TMON.
BMC mainframe products including AMI Ops are licensed on MSU based capacity. Many estates contract under BMC's zConsumption Licensing, where you pay on the prior year's actual z/OS consumption and true up overage at year end. Older agreements remain on fixed MSU capacity. The metric tracks machine capacity, not the number of monitored systems or consoles.
BMC consumption conversions have commonly been based on a stated MIPS to MSU ratio, for example 8.2 MIPS to 1 MSU tied to the machine models in place at the time of the order. As hardware changes, that ratio can drift away from reality, so the contract language that lets both parties renegotiate it in good faith is worth securing. An unexamined ratio can quietly inflate the consumption baseline.
The credible displacers are IBM OMEGAMON, delivered within the IBM Z Monitoring Suite, and Rocket TMON. Monitoring is sticky because dashboards, automation, and runbooks are built around it, but a costed displacement study is real leverage at renewal, particularly when AMI Ops is bundled inside a larger BMC AMI agreement.
Publisher hub: BMC mainframe licensing. Related products: MaxView and the displacer z/OS. Put it to work: BMC mainframe contract review.