Although originally late to the game, IBM has done a great job making Java a viable application execution environment on System z and z/OS. IBM continues to show their commitment to executing Java on System z by adding instructions that improve the performance of Java on the z196. In my opinion, this continues to be an important step in keeping the platform relevant and vibrant for today's application programmers. However, in the beginning, keeping this commitment was somewhat problematic.

As pointed out quite cogently by Cheryl Watson in her tuning letter:

"The current problem with z/OS pricing is that most software is charged on the size of the machine, not the amount of usage of the software.So if you want to move a new workload onto z/OS that requires more MIPS, the cost of some of the other work on the system will also increase.This has been a problem ever since I was first involved in chargeback in the late '60s.You might be running an IMS system and want to add a WebSphere application to the machine and double the number of MIPS. The IMS system, which is serving the same number of customers as before, and using the same amount of CPU as before, will now cost more because the machine is bigger."

As we all know, Java tends to use a little bit more CPU than its compiled cousins (see COBOL and PL/I), so if you were to say, replace your CICS/COBOL app with a Websphere®/Java app in the same z/OS LPAR as your DB2, you might see a MIPS increase anywhere in the range of 10-50X of what the COBOL app was consuming. I think it would be fair to imagine that the early customers thought that Java and Websphere for z/OS (need proper name and tm) was nothing more than a conspiracy by IBM (and by extension, any of the ISVs that they dealt with) to extricate additional money from their budget.  This is where zAAPs come in. The System z Application Assist Processor was created to solve this "capacity crisis" by partitioning the work within the LPAR into two parts: 

1. Java (and anything else so designated by IBM) and
2. everything else. 

In so doing, customers would be able to take advantage of this new technology without the software licensing "sticker shock" that would be associated with a massive MIPS uplift, as IBM and the ISVs agreed to continue to calculate capacity based on general purpose (GP) MIPS.

Not far behind the zAAP came the zIIP. The System z Integrated Information Processor was initially enabled to reduce the cost of DB2 processing associated with queries coming in from the network (maybe there was a drastic increase in requests from the network because customers couldn't afford to execute their Java apps on z/OS???). Of course you can see where this would illogically end, with a new kind of specialty engine for every new kind of work.Fortunately, IBM capped this at two kinds of engines and then basically killed off the distinction between zAAP and zIIP with the introduction of "zAAP on zIIP capability." This probably made z/OS capacity planning experts sad because even just a handful of distinct specialty engine types would have promised to create a whole new industry, like how the complicated tax code in the United States has spawned companies just focused on income tax preparation. Today, IBM, CA and other ISVs have been providing "zIIP enablement" for products in their portfolios.

So that's sort of the story on why specialty engines are good for z/OS. What would make them better? I'd recommend that you take a look at who has been doing enablement, either directly for zIIP or by implementing feature functions in Java and what that implementation is for. I will submit that there are, broadly, two kinds of implementation:

1. One that entices you to use something new because it won't have a drastic effect on your general purpose MIPS (I call this "the carrot"),
2. One that provides a demonstrable savings to your environment; that is, the implementation takes something that you are currently doing today on general purpose MIPS and makes it zIIP eligible (I call this "beneficial").

I'll submit that most new Java implementations are of the first type. Here at CA Technologies, we've embraced Java in two of the products that are key to our Mainframe 2.0 initiative: CA Mainframe Software Manager (CA MSM) and CA Mainframe Chorus. Using Java as the primary programming language allowed us to enable newer members of our community to take part in the development of the products. It also allowed us to build on top of a body of work done by many others, both at CA and in the open source community which accelerated the development of both products. Finally, because the products offload the bulk of their processing to specialty engines, we are able to deliver new functionality which streamlines the management of your environment, executing those functions on lower cost capacity, without incremental MIPS growth (read that as,"You don't have to buy more general purpose processors and incur additional software charges.").

As a customer of the z/OS platform, I suggest you look to see who is in a leadership position on the second type.  At CA Technologies, we've been developing the capabilities to implement zIIP broadly across our portfolio. Starting with NetMaster® and other products with very heavy CPU needs, we've implemented this technology as a way to "reduce the MIPS footprint" of our products, including enabling substantial offloads on our CA Datacom® and CA IDMS^TM database management products. And, we haven't stopped there. We plan to continue to provide offload capability in more and more of our products.