Strobe: priced on the MSU it exists to cut.

Strobe is a code level application performance measurement product for z/OS. It samples execution to show exactly where CPU time goes, down to the sub routine, so teams can pinpoint the inefficient code that consumes far more MSU than it should. Its entire reason to exist is cost: inefficient routines can drive CPU consumption many times higher than necessary, and Strobe makes that waste visible so it can be tuned out. Long sold by Compuware, it is now BMC AMI Strobe within the BMC mainframe portfolio, and it is one of the few mainframe tools whose direct purpose is to reduce the bill rather than add to it.

Strobe is host based z/OS software, so it is licensed on capacity, measured in MSU, sized to the LPARs where it is authorized to run. Under BMC it can be taken on BMC zConsumption Licensing (zCL), BMC's consumption based model with a year end true up, rather than a fixed capacity entitlement. So the two variables are the licensed MSU footprint and whether you are on a standard entitlement or the consumption model. The number of applications you profile does not drive the price; the LPAR capacity does.

Because it is capacity priced, the lever is the LPAR footprint and the model. See batch window tuning to cut R4HA peaks.

The first driver is the licensed MSU footprint, the set of LPARs where Strobe is authorized, which is often wider than the systems where tuning work actually happens. The second is the consumption model versus a fixed entitlement, since zCL shifts the cost to measured use with a true up that can move either way. The third is the bundle, because under BMC, Strobe is increasingly negotiated inside a wider portfolio deal alongside the AMI and DevX tooling, where its individual price is easy to lose. The honest fourth factor is the return: a working Strobe program cuts MLC cost elsewhere, so the product should be evaluated on net savings, not gross price.

Capacity priced tooling inside a portfolio has a specific exposure pattern. Common traps we see at pattern level:

The levers work on the footprint, the model, and the bundle. The five that pay:

Code level performance profiling on z/OS is a real but narrow market. IBM offers its own application performance tooling, and other vendors provide profiling and tuning capability, so a credible alternative exists to discipline the Strobe renewal. The switching cost is in retraining performance teams and rebuilding the tuning workflow, and the deeper consideration is that Strobe is woven into a cost reduction practice rather than a routine operation, so continuity of that practice matters. The practical play is to keep a credible alternative priced as leverage, and to judge Strobe on the net MLC savings it produces against its capacity cost.