So When Does the iSeries Get Java Engines?
April 12, 2004 Timothy Prickett Morgan
Last week, IBM unveiled a new midrange mainframe that does all the usual things in terms of giving more power for less money per unit of power, but the new machine also does something else that no other IBM machine–at least not yet–does. The new zSeries 890 (not to be confused with an iSeries Model 890) also includes a cool new feature: dedicated processor with substantially lower prices that do nothing but run Java code. The question now is: When will the iSeries get Java engines?
While the zSeries 890 shares much of the same technology as the prior zSeries mainframes, this new machine, which is being announced to much fanfare on the 40th anniversary of the launch of the System/360 mainframe, is unique in having dedicated Java engines. The zSeries 890 was code-named “Ptero” internally at IBM. In keeping with the company’s ironic saurian naming scheme, this is short for pterodactyl, and like its older brother, the “T-Rex” zSeries 990, it is based on the G8 series of mainframe processors. The Ptero processors run at 1 GHz, while the T-Rex processors run at 1.2 GHz.
There is some precedent for the Java engines IBM has created for its mainframe line. With the earlier G-series class System/390 mainframes from the 1990s, individual mainframes–comprised of multiple CMOS mainframe engines glued together with symmetric multiprocessing (SMP) electronics–could be linked together into parallel sysplex clusters to provide horizontal growth for MVS and OS/390 workloads. As IBM added more and more engines to the multichip module (MCM) processor complex, eventually it decided to use extra engines in the MCM as hot stand-bys in the event of a component failure or as capacity on demand. These standard processors could also be configured to run the special clustering code as an Internal Coupling Facilities. Prior to this, these clustering co-processors were separate computers.
Back in late 2001, IBM got the bright idea of making mainframe processors Linux-only and then charging a whole lot less money for those engines to try to spur demand for mainframe processing capacity. And it worked. About a fifth of the MIPS that IBM ships are now for the Integrated Linux Facility, as IBM calls mainframe processors that are dedicated only to Linux workloads. These Linux engines first came out with the Linux-only versions of the Raptor zSeries 800s, which made their debut at LinuxWorld in January 2002. Back then, a uniprocessor Raptor server equipped with a reasonable amount of memory and disk, the z/VM license (only good as a Linux partition manager) plus three years of maintenance and software services had a list price of around $400,000, and a uniprocessor “Freeway” zSeries 900 mainframe (the T-Rex machine was not yet announced) with the same features sold for around $750,000. It was obviously a lot cheaper to run Linux on a special Raptor Linux engine than it was on a real zSeries. The Raptors used the G7 class of engines, which were code-named “Blue Flame” and rated at between 250 MIPS for a 770 MHz processor to 300 MIPS for a 950 MHz processor.
With the zSeries 890 Ptero boxes, IBM is putting forth a lower-cost way of running Java workloads. This time around, IBM is taking a mainframe processor, slapping some microcode on it that allows it to support Java Virtual Machines, and designating it as a Java co-processor for other standard processors in the z890 complex. This Java processor, which is called a zSeries Application Assist Processor, or zAAP, is not running z/OS, z/VM, or Linux, so it cannot be used to do any other work, says David Mastrobattista, zSeries marketing manager. However, on typical commercial Java applications, according to IBM’s analysis, these zAAPs can have anywhere from 50 to 70 percent of Java instructions run on them rather than on the standard processors. (Why it is not 100 percent is unclear, but perhaps some Java instructions take less time to run locally on the standard processors than it would take to move them over to the Java processors.) What this means is that companies can offload MIPS from a regular mainframe, which costs three to four times as much as a Linux or Java mainframe processor. This allows them to add Java to their workloads–something Mastrobattista says companies want to do–and get the reliability and sophisticated transaction monitoring capabilities of the mainframe. Otherwise, they would have to run WebSphere within a Linux partition on a mainframe, or offload WebSphere to a set of separate Unix, Windows, or Linux boxes linked to the mainframe. The Global 2000 customers who have lots of mainframes and like them want to add WebSphere, but they don’t like the high cost of putting it on a mainframe. zAAP engines costs $125,000, compared to around $350,000 to $450,000 for a standard mainframe engine that can run z/OS.
The zAAPs are going to be offered on the bigger T-Rex zSeries 990 servers, too. While Mastrobattista says that some customers will upgrade from prior mainframes with Java workloads and spend less money on z/OS operating systems as they move Java workloads to the co-processors, IBM is clearly gambling that customers will like the idea enough that IBM will sell a lot more mainframe engines. This strategy has by and large worked with Linux, and although Mastrobattista will not confirm that similar co-processors could be in the works for the mainframe (such as for DB2 processing or for TCP/IP networking), he concedes that this certainly is possible.
The idea of having a dedicated Java processors is not new, mainly because Java, as an interpreted or partially compiled language rather than a fully compiled language, is a resource hog. Before Sun Microsystems saw the bottom drop out of its Unix server business in 2000, it was working on a Java co-processor called MAJC, short for Microprocessor Architecture for Java Computing. The chip has been used mostly as a graphics co-processor in Sun and third-party graphics cards. There was even some talk in the rumor mill in the fall of 2002 that suggested IBM was pondering a Java-only implementation of iSeries and pSeries Power4-based servers, to ride alongside WebSphere-only and Domino-only servers it already sold in the iSeries line.
While an iSeries Power4-based processor costs roughly $30,000, which is thankfully a quarter of what IBM charges for a mainframe processor of roughly equivalent processing power and memory bandwidth, that is still very pricey for customers who want to switch to Java and who are used to running very efficient and highly tuned RPG code and green-screen protocols. Because their RPG is lean and mean, a given OS/400 server can generally do a lot more work running RPG than it can processing the same transactions using Java. IBM could probably sell a lot more S-Star, Power4, and Power5 processors and stimulate the use of Java on the iSeries if it did the same zAAP trick on the iSeries. IBM controls the microcode for OS/400, it has developed its own JVMs for OS/400, and it knows how to intercept calls and move them around processors or within the processors of OS/400 servers. The OS/400 PASE AIX runtime environment is basically a set of APIs that can talk to the part of the S-Star and Power4 engines that run AIX code and run that code even as OS/400 is using other parts of the chip. The same principle would apply here.
And with the new hypervisor software layer that will debut for the Power5 “Squadron” servers this year, IBM could create an OS/400 or Linux microkernel, slap on some JVMs, and run it inside one or many partitions and create what amounts to dynamic, dedicated Java engines. Pricing these virtual Java engines would be a bit more tricky than the relative simple approach IBM is taking with the mainframe zAAP processors, of course. But a big, smart behemoth that likes to talk so much about its On Demand prowess could probably put some engineers and marketers in a room and hammer it all out fairly quickly–unless all that On Demand talk is just talk, like so many of IBM’s critics contend it is.
I happen to think that IBM can and should do something like I just described. It would be a great selling point for the iSeries, and I would be happy to be proven right and IBM’s critics proven wrong. A snappy name like the Java Bean Grinder would be cool, but IBMers would probably call it Java Assist Technology–OS/400 or some other nonsense. Whatever it might be called, it is a good idea. And whatever IBM does, it has to be open. Any J2EE code and any Web application server that supports Java that can run on the iSeries, be it IBM’s WebSphere, BEA Systems‘s WebLogic, or the open source JBoss app server, should be able to use the Java engines or Java partitions. And while I am thinking about it, any Web application servers that use ILE RPG and CGI to accomplish the same function as J2EE and a Web app server, like Business Computer Design International‘s WebSmart application server, should also have a similar partition or engine offering. Anything that keeps Web-style applications on the iSeries should be promoted, and promoted heavily.