by Anura Guruge,
the editor at large for IT In-Depth

At $125,000 the zAAP Java accelerator for z890 and z990 mainframes is, to say the least, an intriguing proposition.  Since the potential performance gains possible with a zAAP depends, entirely, on the exact composition of the Java code that is to be executed, and as such can be rather variable, there are no ‘MIPS’ or SPECjbb2000 type ratings for this accelerator – that I like to refer to as the Java grinder.  So there is a leap of faith factor involved here.

One cannot, however, be too skeptical (let alone cynical) given that the zAAP is from none other than IBM itself.  Furthermore, the zAAP was announced on April 7, 2004, the 40^th birthday of IBM mainframes, as a kind of technological commemorative feature.  So one has to assume that this is not just a rather extravagantly costly way to get bragging rights at SHARE – possibly with a gaudy lapel pin that reads “My zAAP is Up, Is Yours?”

In reality it is possible that the real benefit offered by the zAAP has more to do with software pricing than with performance.  This is because IBM does not count zAAPs as CPUs when calculating and charging for mainframe software.

A zAAP does not alter the model or IBM's MSU (Millions of Service Units) ratings for a mainframe.  Thus having one or more zAAPs does not result in an increase in mainframe capacity-based software pricing.  This is the raison d'être for the zAAP.  After you have paid the up-front $125,000, you get additional Java-specific processing power with no (one-time or recurring) price increases for the Java applications that will benefit from this added CPU capacity.  It is, in effect, a cost-based incentive to run Java applications on z/OS.

The recently announced WebSphere Application Server for z/OS V6.0.1 makes a point of stressing its support for this Java-specific accelerator.  This obviously makes sense given the Java-centricity of WAS.  In reality, WAS was targeted from day one as the ‘killer app.’ for zAAP and support for zAAP was included in WAS V5.1 for z/OS – albeit with z/OS 1.6(+), since z/OS(.e) 1.6 is a prerequisite for this processor.  Java applications running with CICS 2.3(+), IMS V7(+) and DB2 V7(+) can also expect to see performance gains with the zAAP – but yet again subject to that z/OS or z/OS.e 1.6 prereq.  To this end note, in case you happened to have overlooked it, that z/Linux, at least at present, does not support zAAPs – though one hopes that this will get rectified soon.

Getting a zAAP

IBM positions the zAAP as an attractively priced specialized processing unit that provides a strategic z/OS Java execution environment for customers who desire the powerful integration advantages and traditional Qualities of Service (QoS) of the zSeries (where to be fair to IBM, one has to note, that it has also dropped list price of the zAAP by $3K, since the original announcement).  The pricing rationale alluded to here, in reality, refers to the possible reduction in software pricing discussed above.

In general, any unassigned [i.e. unused] ‘business’ PUs (processor units) on a z890 or z990 MCM can be configured as a zAAP – and it is even possibly to have On/Off Capacity on Demand (CoD) with zAAP for temporary activation.

Note that there are 8 ‘business’ PUs available on the 12 PU z990 MCM – since 2 PUs are permanently allocated as System Assist Processors (SAPs) and two more kept as backup spares in the event of PU failures.  There are 4 ‘business’ PUs available on the 5 PU z890 MCM, with one PU permanently allocated as a SAP.

A zAAP, under no circumstances, can be used on its own.  It will only work in conjunction with at least one CP.  Thus when it comes to the zAAP, one has to think in terms of z/OS(.e) 1.6 LPARs powered by one or more CPs – with one or more zAAPs alongside the CPs to crank through the appropriate Java code.  On a given machine [i.e. central electronic complex (CEC)] you cannot have more zAAPs than you standard CPs.  On a LPAR basis, however, it is possible for a given LPAR to have more zAAPs than CPs. Given these configurational caveats it kind of goes without saying that you cannot IPL a zAAP (per se) and that a zAAP on its own cannot run any operating systems.  This is a pivotal and fundamental difference between zAAPs and the zSeries Integrated Facility for Linux (IFL) processors.  IFLs are not dependant on CPs and can run Linux OSs on their own steam.

In the context of a given LPAR, a zAAP (or zAAPs) designed to operate asynchronously from the general purpose CPs.  The zAAPs are tasked with executing Java code under the control of the IBM Java Virtual Machine (JVM).  So one can think of zAAPs as specialized, hardware accelerator for IBM’s JVM.  It is also expected that there will be no modifications required to Java applications in order to be able to gainfully exploit the acceleration promised by the zAAP.  A zAAP thus minimizes JVM relates processing cycles that have to be performed by a CP.  CP capacity thus freed up can now be used to handle non-Java workloads.

How Much of a zAAP You Can Get

Given that the performance gains possible with a zAAP are contingent on the nature of your Java workload, IBM provides various estimation tools to help you determine what kind of ‘zap’ you could expect with a zAAP.  You can find these tools, which range of Excel worksheets to rather arcane White Papers, on IBM’s zSeris Web site – obviously under zAAP.

The bottom line here is that a zAAP, even at $125K, is less costly than a zSeries general CP (which, alak, is not something you want to dwell upon for too long because it really drives home the fact that mainframes, even in CMOS, are still kind of costly).  So if you have a lot of Java code to run, then using a zAAP might be a way to improve performance and get more non-Java capacity without having to pay ‘full whack’ for a general purpose CPs.  One thing is, however, for sure.  This is not something you should rush into without doing some real serious workload estimates, cost analysis and with any luck – a money-back option from IBM (which in theory, shouldn’t be that hard since you could possibly try it out using On/Off CoD).

  Read the Exclusive zAAP interview with IBM's José Castaño