When IBM introduced the zIIP, it sounded like a great idea. Here was an engine that would run at full speed, even on kneecapped processors, and didn't count against capacity-based software licenses. A few minutes later, we found out there were some catches.
Getting onto a zIIP
The first hurdle in getting onto a System z Integrated Information Processor (zIIP) is creating the right kind of dispatchable work unit. ZIIP-eligible code must run under enclave Service Request Blocks (SRBs). Sadly, the interface for creating enclave SRBs is unpublished and must be purchased from IBM. This effectively limits the interface for vendors interested in exploiting the new engine type.
The second obstacle in getting onto a zIIP is the so-called generosity factor -- the percentage of time that a given workload can run on a zIIP. From what I've been able to piece together, the zIIP interface includes a table that lists each eligible workload and its corresponding generosity factor. The operating system (OS) references this table before dispatching work to the specialty engine.
The last challenge has to do with queuing theory. The IEASYSxx IIPHONORPRIORITY parameter controls where zIIP work goes when the specialty processors are busy. When set to Yes the workload goes to a general central processor (CP) when the zIIPs are saturated. The lack of queuing limits zIIP utilization percentages depending on system business. IBM's answer, of course, is to buy an equal number of zIIPs and CPs for each processor. With enough specialty engines, the total zIIP workload will increase, even if a percent busy of individual processors goes down.
Otherwise, setting IIPHONORPRIORITY to No makes zIIP work wait until a specialty processor becomes available. This increases zIIP utilization, but could cause response time problems for online workloads.
IBM ponies up
Over the years, IBM has added software that can run on zIIPs. However, a pattern soon emerged where the zIIP-eligible products tended to fit niches where IBM needed a competitive edge. A high-level description would consist as follows:
DB2 distributed data facility
Distributed data facility (DDF) is one of the best ways to get work on zIIPs. However, in addition to the restrictions mentioned above, the work must be a remote request from a DDF to a native stored procedure. Regular stored procedures need not apply. Note that IBM uses this feature to make DB2 more competitive with distributed system database management systems. IBM's DB2 utilities also allow some work to be offloaded to zIIPs, making the product more competitive against other companies in this software space.
XML System Services
Parsing extensible markup language (XML) is very CPU-intensive, so it makes sense to move this type of processing onto zIIPs. Doing so allows mainframe shops to play in Web services without buying additional CPs to wade through Simple Object Access Protocol messages. In turn, this makes the z processors more competitive for service-oriented architecture applications.
Portions of network processing, such as Internet Protocol security cryptography, are zIIP-eligible. This keeps a process-intensive workload out of the way of more mundane processing and avoids costly CP upgrades. Likewise, it makes the mainframe more attractive as a highly secure communications server.
z/OS Global Mirror
Global Mirror replicates data over geographic distance using host resources. Being able to run the workload on zIIPs, instead of taking the overhead out of general CPs, is a nice bonus and helps IBM's product compete with hardware solutions.
Z/OS 1.11 can run System z Application Assist Processor (zAAP)-eligible workloads on zIIPs. While this doesn't have an immediate effect, it does have consequences. First, I wouldn't buy any new zAAPs. Second, if you can justify the cost, convert underused zAAPs to zIIPs. Java will still run on the specialty processors, and the new zIIPs will soak up any additional workload you can throw their way.
Independent software vendors (ISVs) are slowly embracing the zIIP. The amount and type of zIIP workload will vary, as each ISV must weigh the value of running on a specialty processor against lost revenue due to deferred customer processor upgrades. For example, most ISV fees are based on CP processing power, and not specialty engines. Therefore, if they change their software to run on zIIPs, customers won’t have to buy as many CPs. The CP’s they don’t buy represent lost revenue for the ISV.
Syncsort repackaged the more CPU-intensive sort phases to run on zIIPs. However, the amount of zIIP workload depends on the input data along with the I/O intensity of the sort.
BMC Software Inc. began by shifting some of its MainView for z/OS monitor work onto zIIPs. Last year, they announced zIIP support for many of its DB2 database utilities to compete with IBM. Again, your mileage may vary depending on how the utilities operate on your databases, as well as BMC's generosity factor.
The elephant in the room is Neon Enterprise Software's zPrime, which breaks all of IBM's alleged zIIP restrictions and allows just about any workload to run on specialty engines. This relatively simple concept has embroiled Neon and IBM in a lawsuit that might be settled by the middle of this year. In the meantime, both companies are jockeying for position before the jury renders a decision.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.