Home / BMC / AMI Data for Db2 Licensing
① Product · BMC
BMC AMI Data for Db2 is a modular suite priced on MSU capacity and, increasingly, zConsumption. The entitled module set usually outruns the used one. Here is how it is licensed and what to pull at renewal, buyer side.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →BMC AMI Data for Db2 is BMC's suite of database administration, utilities, and data management tooling for Db2 for z/OS. It covers database administration and change management, the load, unload, copy, and reorg utilities that move and maintain data, recovery, and Db2 catalog navigation, with the stated aim of cutting CPU and streamlining administration. The important point for licensing is that it is modular: the administration, performance, and recovery pieces are separately entitled, so the suite tends to accumulate modules faster than a shop retires them.
AMI Data for Db2 is licensed on mainframe MSU capacity, traditionally on a tiered basis tied to the capacity of the machines or LPARs where the Db2 tools run. BMC has been moving customers to zConsumption Licensing, or zCL, where you pay against the prior year's actual z/OS MSU consumption and true up overage at year end, rather than against rated capacity. Because the suite is modular, the set of entitled modules sits alongside the capacity basis as a primary driver of the bill.
| Element | How AMI Data for Db2 is treated |
|---|---|
| Legacy basis | Tiered MSU capacity on the Db2 LPARs |
| Current direction | zConsumption Licensing on measured MSU |
| Scope unit | Modules, entitled separately |
| True up | Annual overage reconciliation under zCL |
| Term | Multi year, with renewal uplift pressure |
Directional summary. The basis and module mix on a given contract depend on your deployment and whether you have moved to zCL.
Three drivers set the number. The MSU capacity of the Db2 LPARs the tools run on, whether rated under the tiered basis or measured under zConsumption. The module breadth, because each administration, performance, recovery, and utility module is entitled separately and an estate often carries more than it uses. And the consumption baseline under zCL, because a baseline set in a peak year locks in a high floor that an annual true up only adjusts upward unless you push to rebase it. The interaction of capacity and module scope is where the real money sits, and where reconciling entitlement to use pays off.
The recurring traps are scope and capacity drift. Tiered MSU capacity larger than the Db2 LPAR footprint actually being managed, after consolidation or workload movement. Modules across administration, performance, and recovery that are entitled but not in real use, the classic suite accumulation problem. And a zConsumption baseline set in a high year that never gets rebased, so the true up ratchets without anyone testing the floor. The same discipline that controls subscription and support creep applies here: the entitled set has to be reconciled to the used set before the renewal conversation.
The first lever is the module cull: rationalize the entitled set down to what the Db2 teams actually run. Then rebaseline the capacity to the Db2 LPARs being managed, and test zConsumption against the legacy tiered basis to see which is cheaper for your consumption shape rather than accepting BMC's preferred model. The contract levers are a hard cap on the renewal uplift and the credible competition from IBM's own Db2 tooling and other vendors, which is real leverage in the Db2 administration space even when you do not intend to migrate. This is the buyer side work we do on BMC MSU optimization.
BMC AMI Data for Db2 is licensed on mainframe MSU capacity, traditionally on a tiered basis tied to the capacity of the machines or LPARs where the Db2 tools run. BMC has been moving customers to zConsumption Licensing, or zCL, where you pay against the prior year's actual z/OS MSU consumption and true up overage, rather than against rated capacity. The suite is modular, so module scope sits alongside capacity as a primary driver.
Not directly the way IBM MLC products are. BMC prices on MSU capacity or, under zConsumption Licensing, on measured annual MSU consumption. Sub-capacity discipline on the underlying z/OS environment still matters, because the MSU profile that BMC measures is shaped by the same workload peaks, so peak management reaches the BMC bill indirectly.
The common traps are tiered MSU capacity larger than the Db2 LPAR footprint actually being managed, modules across administration, performance, and recovery that are entitled but not in real use, and a zConsumption baseline set in a high year that never gets rebased. Db2 tool suites accumulate modules over time, so the entitled set often exceeds the used set.
Rebaseline the capacity to the Db2 LPARs the tools actually manage, rationalize the module set down to what is used, test zConsumption against the legacy tiered basis for your profile, cap the renewal uplift, and use the credible competition from IBM and other Db2 tooling vendors as leverage even where you do not intend to migrate.
Publisher hub: BMC mainframe licensing. Related product: AMI Cloud licensing. Related metric: MSU explained. Put it to work: BMC MSU optimization.