z /OS represents IBM’s “crown jewels.” Its power, reach, and Reliability, Availability, and Serviceability (RA S) are unparalleled. And its price— and the prices of its associated program products—reflect that.
The z/OS pricing model is both a strength and a weakness. It’s a strength because it lets IBM provide the strong service and continued innovation that keep z/OS attractive to sites needing its power; it’s a weakness because, in this era of “do more with less,” the annual price tag for z/OS and related products has caused more than one CFO to say, “Get rid of the mainframe!” (Not necessarily after analysis justifying such a move, but that’s another discussion.)
Recognizing this, IBM engages in a bit of pricing sleight-of-hand, depending on what software will run on the hardware. z/OS itself must run on regular processors (CPs, in IBM parlance). z/VM and Linux on System z can run on CPs or on Integrated Facility for Linux (IFL) processors. In 2004, IBM introduced System z Application Assist Processors (zAAPs) to offload z/OS Java and XML processing; and in 2006, they added System z Integrated Information Processors (zIIPs).
zIIPs are more general than zAAPs. Initially, IBM stated that DB2 zIIPs were for specific DB2 functions, but soon amended that to include an interface for software vendors to offload certain processing to zIIPs. Since then, several vendors have updated their products to exploit zIIPs when available. These “specialty” processors differ from CPs in only two ways: they report a different processor type and have a single instruction disabled. If a customer attempts to run z/OS on a non-CP, the Initial Program Load (IPL) process tries to execute that instruction and fails. While not foolproof, this provides the legal “safety” IBM needs. A customer must take deliberate, non-trivial action to run z/OS on an IFL and can hardly say, “Oops, we didn’t realize we were doing that.”
These specialty processors appeal to customers for several reasons:
- They’re cheaper than CPs.
- They always run at full speed, even if mated to a “kneecapped” (detuned) CP.
- Operating system and program product software licenses don’t include them in license fee calculations.
This last reason is, in some ways, the most significant. Consider Java applications. For various reasons, including their origins in non-timesharing environments and inefficient Graphical User Interface (GUI) coding tools, most Java applications are poor performers on z/OS. So, a site with little spare capacity may feel it can’t afford to run WebSphere, which is Java-based; adding the needed capacity would cost the price of the CP and increase license fees for z/OS, all its program products, and third-party software.
By, instead, adding a zAAP, the only cost is that of the zAAP itself. At a time when all such purchases are “let’s-make-a-deal,” that cost can be minimized. So, how does work run on a zAAP or zIIP? The operating system is certainly aware of the existence of specialty processors defined to the LPAR. As z/OS schedules tasks to run, certain work (e.g., Java, selected DB2 processing, and specific other work, including some vendor software processing) is recognized as eligible for dispatching on something other than a CP, and is then dispatched on the appropriate specialty processor. (z/OS doesn’t exploit IFLs at all.)
There are two levels of “handshake” that prevent regular z/OS work from running on specialty processors: the IPL time test and the scheduling/dispatching process that decides whether work is eligible.
This works well, and customers have happily exploited zAAPs and zIIPs for the last few years. Specialty processors have helped both IBM and its customers’ bottom lines. Like IBM, Independent Software Vendors (ISVs) whose products exploit these “cheap MIPS” don’t charge for those MIPS, but still benefit by making their products more attractive to cash-strapped customers.