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.

• Switching to vendors with less onerous upgrade fees. This could entail a fair amount of work for conversion, however.

Vendors fought back with extensive bundling schemes. The prices didn’t vary based on the product mix—it was all or nothing. Millions of dollars were at stake and the entire situation was begging for a solution.

When discussing zIIP processors, because of the restrictions IBM placed on software running on zIIP processors, it’s necessary to understand a little about the operating system and how it dispatches units of work.

Originally, when System/360 was first announced in 1964, there was only one method of dispatching work, and that was under a Task Control Block (TCB). This satisfied the requirements at the time. TCBs were long-lived, relatively speaking, lasting the life of the job step. Although they had some drawbacks (such as lots of status information to save), they got the job done. However, as the original architecture evolved and was extended, IBM needed to create a new vehicle for dispatching work, and that became known as a Service Request Block (SRB).

SRBs were an ultra low-overhead method of dispatching work that had a short lifespan (i.e., milliseconds), had minimal status-saving issues, ran at a high priority, etc. In exchange for these characteristics, running under an SRB (called running in SRB mode) was restrictive. While running in SRB mode, code couldn’t invoke any SVCs (with which many operating system services are implemented), and were restricted from invoking many other operating system services as well. Additionally, almost all the developed I/O access methods couldn’t be used under SRBs because they issue SVCs. Also, SRBs had different recovery requirements, certain resources (such as storage) couldn’t be owned by SRBs, etc. Bottom line: TCBs are full function; SRBs are extremely limited in what they can do.

IBM had been somewhat successful with “specialty” engines. No license charges were incurred for these engines—such as the Integrated Coupling Facility (ICF), Integrated Facility for Linux (IFL), and the System z Application Assist Processor (zAAP)—but nothing addressed the core issue of vendor software running the big database products, DB2, and IMS. How to tackle this issue was tricky, as IBM didn’t want to diminish its software license charges. However, IBM had an ace in the hole. When writing DB2, it become necessary to run a lot of processing, not under TCBs, which resided below the 16MB line and had several limitations, but under SRBs. Unfortunately, the traditional SRB wasn’t completely suitable for this purpose (their dispatching priority was too high), so IBM created the concept of Enclave SRBs, which could run at different priorities governed by Workload Manager (WLM).

Now all the pieces were in place for IBM to enable these enclave SRBs to run on a new type of specialty processor, the zIIP. This was a stroke of brilliance because it enabled IBM to offload a significant portion of DB2 processing onto a specialty processor, for which there were no software license fees. Simultaneously, since all the physical processors on a z9 and z10 box were essentially identical, almost any processor could be configured as a Central Processor (CP) or a specialty processor, subject to license restrictions (the number of zIIP processors, for example, can’t exceed the number of CP processors). Just to add some punch to the zIIP announcement:

• All zIIP processors run at full speed. They’re never “knee-capped” as CP processors might be.

• They’re masked off for I/O interrupts. This is a critical issue with the z9 and especially the z10 processors, on which cache disruptions can wreak havoc on processor throughput.

• They’re lower priced than a CP processor.

But IBM didn’t stop there. After much internal debate, IBM decided to license the zIIP enablement interface to ISVs. This lets them run their own code on a zIIP processor. This was done because it isn’t possible to just take any code and run it on a zIIP processor: it must be an Enclave SRB, and almost all ISV code is running under TCBs. In most cases, vendors can’t just zIIP-enable their code to run on a zIIP processor. They must do an extensive code rewrite to enable this function. If a software vendor has a large sales and marketing staff, but a neglected and minimal software development staff, it probably won’t be able to make this change. IBM bet that smaller and more nimble software companies would make this change while their larger and more complacent competitors wouldn’t be able to do so. Has the strategy been successful? For the most part, the answer is a resounding yes. Most of the smaller ISVs have announced zIIP-enabled offerings.

IBM has helped DB2 shops in a major way with its zIIP support. Since a large percentage of CICS transactions that access databases use DB2, it has indirectly helped CICS users, too. The missing piece of the puzzle is IMS. IBM hasn’t yet done anything to help the IMS user offload work to zIIP processors. However, not all this is IBM’s doing. IMS runs almost completely under TCBs, except for a minor amount of work for Fast Path (a flavor of IMS), whereas DB2 already had a great deal of its processing running under Enclave SRBs. Perhaps IBM will announce something in this area in the future.

IBM’s results have been spectacular. It’s no secret that z10 production was sold out through the end of 2008 and beyond, even with the world entering a deepening recession. The value proposition is just that good. Revenues from System z mainframe server products increased 25 percent compared with the same period a year ago, with double-digit growth in all geographies. Total delivery of System z computing power, which is measured in Millions of Instructions Per Second (MIPS), increased 49 percent. Additionally, shipments of zIIP processors increased by 125 percent over the previous year.

So, customers must now separately examine not just the usual growth demand for CPU time, but the growth demand for CP processors and zIIP processors. If customers can move significant work over to the zIIP processors from CP processors, they save money on the hardware and avoid devastating software license upgrade fees. This has been disruptive because IBM has been able to break the stranglehold that some large ISVs have had by enabling an architecture that allows smaller, more nimble companies to effectively compete.