Neon revs cost-cutting mainframeware
zPrime risks Big Blue ire
A small mainframe software tool developer called Neon Enterprise Software has opened up a can of worms - and quite possibly several cans of Big Blue whoop-ass - by launching a new tool that will allow customers to shift a larger percentage of their workloads from standard (and expensive) mainframe engines to the cheaper specialty System z mainframe engines known as zIIPs and zAAPs. It's called zPrime.
With around 10,000 footprints worldwide, maybe somewhere around $4bn in mainframe sales a year, and heaven only knows how many billions per year in monthly rentals for mainframe operating systems, databases, and middleware, IBM is very protective of its mainframe
franchise monopoly. And products like zPrime - while technically doable and presumably legally defensible - strike fear into the hearts of IBM's mainframers.
We've seen this before. IBM put governors on the performance of green-screen RPG and COBOL workloads on its AS/400 proprietary minicomputers in the late 1990s, and a few different clever software developers figured out ways around the governors. This resulted in much consternation at IBM, legal battles with the governor buster, and eventually a settlement in the courts where the terms of the settlement were not divulged. It's widely believed that IBM gained all rights to the tool in exchange for cash. (You can see the whole saga here).
Because mainframe shops pay the highest prices in the world for hardware and software - think 2000 prices for hardware and something like 1990 prices for software, and I am only half-joking - Big Blue has been tweaking things here and there over the years to try to make the mainframe more competitive. Different classes of machines have been given different pricing, such as lower software fees for entry mainframes a few years back. Then customers were given metered pricing options for monthly software rentals, based on a metric that IBM calls Metered Software Units, or MSUs, which allowed them to pay for software on a capacity-over-time basis instead of on a per-machine or per-engine basis.
In 2000, just after Big Blue caught the Linux bug, IBM decided to designate some of the mainframe engines in a processor complex as specialty engines, including the Integrated Facility for Linux (IFL), which turns a standard mainframe engine into one that can only run Linux and workloads that have been ported to the mainframe variants of Linux. (And, as of last November, OpenSolaris and its "Sirius" mainframe port can go on the IFLs). The IFL has been very popular at IBM mainframe shops, and has been instrumental in the stabilization of mainframe revenues and MIPS shipments.
The IFL was followed up in September 2004 with the System z Application Assist Processor (zAAP) for offloading Java and XML workloads from the central processors (CPs) running z/OS and IBM's WebSphere middleware. In June 2006, the System z Integrated Information Processor (zIIP) debuted, accelerating DB2 databases by offloading certain functions from the CPs running z/OS and DB2 to these zAAPs.
By early 2007, the last time I have seen IBM talk publicly about its MIPS installed base, IBM had an installed base of 11.074 million aggregate MIPS, and about 1.2 million MIPS of that were for specialty engines. And in the most recent quarter IBM talked about, the first quarter of 2007, specialty engines accounted for 60 per cent of the total MIPS that IBM shipped.
Because they cost about one-quarter the price of regular mainframe engines, these specialty engines don't contribute to the bottom line the same way as those CPs. But imagine what IBM's mainframe business would look like without them. It would be a declining footprint with declining aggregate power and declining sales, not a stable footprint with growing aggregate power and somewhat stable sales.
Enter Neon Enterprise Software and its zPrime tool.
The trouble with zIIPs and zAAPs
The problem with the zIIPs and zAAPs, according to Robin Reddick, vice president of marketing at the company, is that there are a lot of restrictions on what workloads can and cannot be offloaded to the zIIPs and zAAPs. Reddick says that the mainframe shops Neon talks to - and they talk to a lot of them, thanks to the mainframe tools the company has been creating and selling since 1995 - were hopeful that maybe somewhere between 20 and 40 per cent of their DB2 workloads could be moved over to the zIIPs. But in practice, because of the way IBM has implemented the zIIP, maybe somewhere between 5 and 20 per cent can move. And the zAAP is only useful for accelerating Java and XML, not the ka-gillions of lines of COBOL and CICS code running out there in mainframeland.
Tony Lubrano, whose title is zPrime product author at Neon, would not divulge how zPrime works, but he gave a few hints about how it lets IMS and DB2 database applications as well as the related CICS transaction processing, the TSO/ISPF green-screen interfaces, and batch programs run on zIIPs and zAAPs. While zPrime accelerates COBOL applications and their underpinnings, it actually doesn't move the COBOL code or any pieces of IBM's systems software over to the zIIPs and zAAPs. "zPrime facilitates the use of zIIPs and zAAPs," explains Lubrano, "but the z/OS dispatcher actually makes the call about what work gets moved to the zIIPs and zAAPs."
Well, it does until IBM's own programmers tweak the z/OS dispatcher.
Lubrano explained that there are two modes for database applications to be created on mainframes, one called task control block (TCB) mode and the other called service resource block (SRB) mode. The zIIPs can only run applications that have been coded in SRB mode, which Lubrano says requires a lot of expertise and special authorization to run. Unfortunately most legacy DB2 batch jobs are coded in TCB mode.
It is reasonable to conjecture that one of the things that the zPrime tool is doing is creating some sort of shell around legacy applications coded in TCB mode to make the zIIPs think they are in SRB mode. That means it can execute on the zIIPs instead of the CPs. And this all gets done in such a way that the z/OS dispatcher sees the zIIP and sees the DB2 work can be moved over and does it.
So how much money can companies save by running zPrime on their mainframes? Reddick says that among some initial customers, they are seeing that as much as 50 per cent of the mainframe workload can be moved from CPs to zIIPS and zAAPs and that as much as 20 per cent of the mainframe hardware and software budget can be eliminated. (These are numbers that will surely get IBM's attention, if not its lawyers on the phone).
The most immediate effect will come from customers who are using MSU pricing, says Reddick. To calculate the monthly software bill on a mainframe, IBM counts up the four highest hours of MSUs used by a piece of software for the month and does a rolling average to send you the bill. Shifting those peaks down with zPrime will lower the monthly bill.
But zPrime could have far-ranging effects on IBM's mainframe business. Companies that might upgrade their machines every two or three years might figure out how to make their existing machines do more work and skip an upgrade cycle and then do a more modest upgrade further down the line. And third party application providers, who make money whenever a mainframe shop upgrades their box, might see fees go flat as customers upgrade to newer, but smaller, machines that nonetheless do more work because they are offloading to zIIPs and zAAPs at a higher rate than IBM or the ISVs anticipated.
We're talking about billions of dollars here - potentially.
So far, IBM has not bought a copy of the product and its lawyers have not come a-calling, says Reddick, but Neon has had some conversations with IBMers. What about, she did not say. Rest assured that if zPrime takes off, there will be more conversations.
zPrime will run on IBM's line of 64-bit mainframes, which includes the z800, z890, z900, z990, and z10 BC and EC machines. It requires z/OS 1.7 or higher and can support applications written in either 31-bit or 64-bit mode. Pricing for zPrime has not been hammered down as yet, but it is a fair guess that it scales with the size of the mainframe and the amount of work that gets moved over.
Neon Enterprise Software is a privately held firm located in Sugar Land, Texa, that is owned by none other than John Moores, one of the three co-founders of BMC Software back in 1980 and the venture capitalist behind Peregrine Systems. He eventually became its chairman and stayed in that position until Peregrine went bankrupt in early 2003. He has plenty of money and a lifetime of experience dealing with IBM in the mainframe racket.
It will be interesting to see how this plays out. ®