Data Center Strategies for the CIO
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,
Requires Free Membership to View
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.
Communication server
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.
Java
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.
Other vendors
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.
This was first published in April 2011
Join the conversationComment
Share
Comments
Results
Contribute to the conversation