How zIIP Processors Are Changing the Rules

3 Pages

IBM intended for its System z Integrated Information Processors (zIIPs) to be a disruptive event in the mainframe market. Well, they’ve certainly succeeded in this mission. IBM is selling more central processors and specialty processors—especially zIIP processors—than ever. The dynamics of software licensing fees on zIIPs are realigning the Independent Software Vendor (ISV) and IBM software markets.

 

For the last decade, IBM had a pressing issue in the z marketplace: The cost of z hardware dropped by tremendous percentages, while the cost of z software increased by similarly tremendous percentages. Customers complained loudly to IBM. For almost two decades now, z software has been priced by the CPU capacity of the hardware it runs on; a seemingly fair solution. CPU was probably chosen because it was reasonably repeatable and easy to measure, unlike memory or channel time. Installations with smaller processors would pay a smaller fee, and installations with larger processors would pay a larger fee.

 

This actually made sense, except that, in reality, if a customer ran, for example, DB2 and IMS on the same processor, and the DB2 workload was growing and the IMS workload was stable, the customer may need to add more processing power to handle the increased DB2 workload. However, doing so almost always triggered significant price surcharges for the IMS products. Customers perceived this as unfair since the IMS software wasn’t being used any more than it was previously; it was just being housed on a CPU with larger capacity. To add insult to injury, software license “upgrade” fees were quite expensive and could easily dwarf hardware upgrade costs.

 

To avoid these costs, customers tried various tactics:

 

• Negotiating for more capacity than they needed at license renewal time. This sort of solved the issue, but at a price: The customer was forced to purchase upfront more capacity than was needed to avoid the steep “upgrade” license fees.

• Isolating the software to a smaller machine. This was a somewhat successful strategy, but it was cumbersome to implement and had other costs (people and operational) associated with it.

3 Pages