Log Master: a Db2 utility that hides inside a bundle.

BMC AMI Log Master for Db2 reads and exploits the Db2 for z/OS log for purposes beyond restart and recovery: point in time and transaction level recovery, undo and redo SQL generation, change auditing, and data migration. It works alongside the rest of BMC's Db2 recovery tooling to enable fast, precise recoveries to a timestamp or log point. It is a specialist database utility, valuable to a Db2 team, and it almost always sits inside a wider BMC Db2 solution rather than standing alone, which is the key to how it is priced.

Log Master is licensed on mainframe capacity measured in MSU, consistent with BMC's Db2 portfolio. The traditional entitlement is a contracted MSU figure for the environment where Db2 runs; BMC also offers zConsumption Licensing (zCL), which sets the charge from measured z/OS MSU utilization with an annual true up. The charge tracks the capacity of the Db2 environment, not how many log records are read or recoveries performed. Critically, Log Master typically renews as part of the BMC AMI Recovery Management for Db2 solution, so its cost is usually expressed inside a bundle rather than on its own line.

Because it sits in a bundle, the first task is to make the vendor express what Log Master and each sibling component cost separately.

The base driver is the MSU of the Db2 environment, contracted or measured. The defining second driver is bundling. Inside Recovery Management for Db2, a single capacity figure and one uplift can cover Log Master and several sibling utilities, so the buyer pays for a set without seeing whether every component is used or whether the capacity is counted consistently. The third driver is scope creep: Db2 subsystems spun up for new applications, or kept after a project ended, that extend where the tool is deployed and therefore the capacity it is expected to cover.

Log Master exposure comes from the bundle and from capacity drift. Common traps we see at pattern level:

The bundle is the battleground, so the levers start with making it transparent. The five that pay:

Db2 log analysis and recovery is a contested category. IBM offers Db2 utilities and recovery tooling, and other independent vendors compete in Db2 administration and recovery, so Log Master's functions have credible substitutes in a way core infrastructure does not. Switching is real work, recovery procedures, automation, and operational trust all have to transfer, and a database recovery tool is something teams are rightly cautious about changing. But for the specific functions a shop actually uses, a scoped evaluation of the alternative is a legitimate lever, particularly on the components of a bundle that are lightly used or duplicated elsewhere.