Sometimes we might lose sight that change can be evolutionary as opposed to revolutionary and this certainly applies to IBM Mainframe specialty engines, for example:
- 1997: Internal Coupling Facility (ICF)
- 2000: Integrated Facility for Linux (IFL)
- 2004: System z Application Assist Processor (zAAP)
- 2006: System z Integrated Information Processor (zIIP)
To assist with lower IBM software pricing, arguably the ICF offering became the de facto standard for a Mainframe user to be considered “actively coupled”. Therefore deploying two or more eligible IBM Mainframes, physically attached via coupling links to a common Coupling Facility (I.E. ICF).
The Integrated Facility for Linux (IFL) is a processor dedicated to Linux workloads on IBM System z servers. The IFL is supported by the z/VM virtualization software and the Linux operating system. Most customers have at least dabbled into this technology, while some are using this technology extensively, primarily for distributed server consolidation.
Somehow the zAAP specialty engine has become the “black sheep” of the family where the current zEC12 and zBC12 are planned to be the last System z servers to offer support for zAAP specialty engine processors.
As of z/OS V1.11, functionality was delivered enabling zAAP eligible workloads to run on zIIP engines. This function allowed both zIIP & zAAP-eligible workloads to process on zIIP. This capability was ideal for customers with insufficient zAAP or zIIP eligible workload to justify a specialty engine. Whereas the combined eligible workloads increase the ROI metrics for zIIP deployment. The zAAP specialty engine is primarily targeted for web-based applications and SOA-based technologies, namely Java and XML.
So for z/OS type workloads, we must “zIIP Into The Future”…
Sometimes we need to look at the big picture, where the IBM organization is comprised of many business units, including the Mainframe business unit. The Mainframe business unit itself contains many groups, including, but not limited to, the Hardware and Software groups.
As we all know, z/OS software TCO is significant and so this translates into higher revenues for the IBM Mainframe software group; but what about the IBM Mainframe hardware group? Perhaps the specialty engines, primarily in the form of zIIP will generate revenue stream for this business unit. Along with the introduction of zBC12 & zEC12 servers, IBM increased the zIIP to General Purpose (CP) engines ratio to 2:1; meaning you can have 2 zIIP specialty engines with the same capacity as an associated CP engine. Previously the maximum ratio allowed was 1:1 (Specialty:CP).
What workloads are zIIP eligible? Over time and since 2006 the amount of workload that is zIIP eligible has increased, primarily due to software development and upgrade efforts of IBM and the 3rd party ISV community:
- DB2 for z/OS exploits the zIIP capability for portions of eligible data serving, pureXML and utility workloads
- Other 3rd party DBMS solutions, including ADABAS & IDMS offload workload to zIIP
- Most Systems Management tools (E.g. OMEGAMON, MAINVIEW, RMF, SYSVIEW, et al)
- z/OS XML System Services for eligible XML validating and non-validating workloads
- Other z/OS functions including /OS Communications Server, Global Mirror, CIM Server, et al
What are the benefits of deploying a zIIP specialty engine?
- Lower acquisition and maintenance costs, when compared with general CP
- zIIP engines run at full rated CP speed
- Offload work (CPU) from General Purpose (CP) engines
- No cost for Sub-Capacity eligible IBM software (I.E. WLC)
So, one must draw one’s own conclusions, but seemingly the deployment of zIIP engines is a “no brainer”!
Hmmm, once again, evolution is a good thing and the zIIP engine has an 8 year history and its predecessor zAAP, a 10 year history. This ~10 year period has allowed for user experiences and IBM function developments to evolve a more stable and rounded offering and as previously stated, a product for the IBM Mainframe Hardware group to focus upon.
From a customer viewpoint, zIIP deployment requires a Capacity Planning evolution, which should be reasonably straightforward. The big difference is the CP to zIIP offload consideration and some of the lessons learned include:
- Software costs – Multiple-Processors; CP to zIIP Offload Rate; zIIP utilization
- Hardware costs – Installed Books (total MSU/MIPS capacity); Additional LPAR(s)
- Peak CPU utilization – Safeguard that zIIP exploitation reduces peak CPU usage
- CPU per Transaction – Slight increase in CPU (not necessarily elapsed time) as workload switches from CP to zIIP
- zIIP utilization – Early experiences indicate ~50% zIIP engine busy is a good number
In conclusion, zIIP deployment has been gradual and evolutionary, but many factors indicate that zIIP is here to stay and it is the future. Seemingly from an IBM viewpoint, with benefit for the Mainframe Hardware Group in terms of the eradication of the zAAP engine, the increase in CP:zIIP ratio to 2:1 and the associated customer benefits of Sub-Capacity software pricing. From a customer viewpoint, ignoring these pointers might not be wise, as z/OS software costs are significant and CPU resource requirements keep increasing. Adding extra zIIP CPU capacity reduces hardware and associated software costs and so this is the “no brainer” observation that can’t be ignored for much longer…