Dec 1 ’09
NEON’s zPrime Tweaks Mainframe Technology & Economics
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.
The equation changed in July 2009, when NEON Enterprise Software announced its zPrime product, which lets customers run some regular z/OS work on zIIPs and zAAPs. This announcement caused a stir on the IBMMAIN Internet mailing list, with much speculation and rumination. NEON says that, with zPrime, you can:
- Reduce workload on expensive central processors
- Reduce the cost of software
- Eliminate peak-period temporary usage costs
- Delay hardware upgrades
- Rebalance the IT budget and infrastructure
- Maximize return on your System z mainframe investment.
Specifically, zPrime lets customers use a standard IBMprovided exit to mark IMS, DB2, TSO, CICS, or limited (non-APF, non-multi-tasking) batch work as eligible to run on zIIPs/zAAPs. Other jobs, including most third-party products, aren’t eligible.
Customers are strongly polarized on zPrime. They either think it’s a great idea, or they think it’s “cheating” and that IBM will stop its use.
Those who like the idea of zPrime say such things as:
- “Well, IBM has abused its customers with high software prices.”
- “We shouldn’t have to pay more for the same hardware.”
Yes, workload growth increases costs, but workload growth also presumably means increased business for those customers, so they get value for those increased costs. Charging different prices for the same hardware (CPs and specialty processors) is arbitrary, but it serves a purpose. If the alternative were for IBM to not discount specialty processors, or not offer them at all, would that be preferable?
Such a position also ignores the great strides IBM has made in making System z more affordable in recent years, between lowered prices, specialty engines, the recently announced System z Solution Editions (prepackaged z/OS installs for specific applications), and the “technology dividend”—the fact that as new, faster processors are released, the same number of MIPS translates to fewer chargeable Millions of Service Units (MSUs).
Those who see zPrime as cheating say IBM sold zIIPs and zAAPs cheaply specifically because they were for non-core processing, and that this has been clear from the start. Consider an analogy. Those readers who grew up on farms will recall that farmers can buy certain fuels at reduced tax prices for farm use only. These fuels are typically dyed to indicate their intended use, and inspectors occasionally check vehicle tanks for the dye, with hefty penalties for misuse. Using zPrime is cheating; it’s like using “farm gas” for road use.
IBM’s response was unsurprising. A quickly released statement basically says, “Don’t do it,” and threatens to charge customers who take advantage of zPrime the full price of the added core processing capacity. A retired IBM executive friend likes to say, “There are two monopolies in the computer industry: Microsoft and IBM.” When he says “Microsoft,” he is, of course, referring to the Windows/ Office duo (Office actually being the larger of the two in terms of profit). For IBM, he means the mainframe and z/OS. The recent experience with Platform Solutions’ System z clone on Itanium hardware demonstrates that IBM will aggressively fight any threat to its mainframe market position.
Now, NEON isn’t naïve; they considered all this before introducing zPrime. Their position, after careful analysis (both technical, by an expert witness, and legal, by a highpowered law firm) is that there’s nothing definitive in IBM’s licensing that states a zAA P or zIIP can’t be used for “regular” z/OS work. Since they don’t use the IBMprovided interface, they aren’t violating the stated purpose of that interface.
A conversation with Mark Anzani, vice president and CTO, IBM System z Technical Support, clarified IBM’s position: Licensed internal code (aka “microcode” or “millicode”) agreements (available from www-947.ibm. com/systems/support/machine_warranties/machine_code. html) clarify that customers may use only the capacity they agreed to in the manner IBM intended. He says customers who have “kicked the tires” on zPrime and then contacted IBM have ruefully agreed that it “sounded too good to be true.”
A similar conversation with NEON CEO Lacy Edwards, of course, presented things from a vastly different perspective. He acknowledges that zPrime hits IBM in the wallet and is clearly counter to the intended use of the hardware, but believes there are precedents—such as the development of disk compression products—which had similar effects.
“This is what software companies do,” Edwards explains. “They find ways to use hardware more effectively.”
He sees zPrime as helping to save the mainframe, making it affordable for shops that would otherwise move to other platforms to save money, and expressed willingness to work with IBM to resolve the issues.
It’s worth noting that even if zPrime is currently allowed by IBM licensing, IBM can update license terms, and can also tinker with the specialty processor “handshake.” It seems likely that zPrime will have a limited life. Its primary value may be as a negotiating point with IBM for customers unhappy with license costs, though how that serves NEON is unclear.
Meanwhile, other vendors have expressed irritation that NEON isn’t “playing by the rules.” They see zPrime as disruptive to the marketplace and their specific pricing schemes. qIBM has not initiated legal action against NEON, feeling sufficiently confident in their position based simply on explaining how it relates to licensing. It seems evident, however, that issues around zPrime are mainly legal, not technical.
Does NEON think their lawyers can prevail over IBM’s? A manager once told me long ago, “IBM’s lawyers can beat up our lawyers.” While that may also be true for NEON, NEON is indemnifying zPrime customers against possible legal action by IBM. That doesn’t extend to NEON being willing to pay increased license fees levied by IBM against zPrime customers, however. Since IBM is unlikely to sue a customer over use of a vendor product, this indemnification may be ultimately meaningless.
The zPrime denouement isn’t yet clear. The lawyers are preparing to fight! ME