|Issue 2, 2012||Download pdf|
By Angelika Siffring, Vice President, ETS Product Management and
Bruce Beaman, Senior Director, Adabas and Natural Product Marketing, Software AG
Bruce Beaman, Senior Director, Adabas and Natural Product Marketing, Software AG
Software AG’s zIIP Enabler for Natural takes advantage of IBM’s innovation in specialty engines to lower the mainframe’s Total Cost of Ownership (TCO) by moving almost all Natural batch workload from IBM General Purpose Processors (GPPs) to less expensive zIIP processors for execution. This provides a low-cost alternative to increasing capacity on existing GPPs for customers reaching their z/OS capacity limit. Since no changes to the Natural application are required, this is also a low-risk solution that is easy to deploy.
For the past 20 years, the perceived cost of running business workloads on a mainframe drove companies to consider
alternative hardware platforms employing operating systems such as UNIX, Windows and Linux. New workloads created by IBM WebSphere, which encouraged the pervasive use of CPU-intensive Java-based applications, required increases in mainframe capacity but businesses were reluctant to invest so heavily in new mainframe hardware.
Today, judicious exploitation of IBM’s innovative zIIP processors can increase effective capacity by moving eligible work from the General Purpose Processor (GPP) to zIIP, thereby reducing the need for costly upgrades and improving total cost of ownership. Like the zAAPs (Application Assist Processors for Java code execution, XML parsing, etc.) and IFLs (Integrated Facility for Linux execution) that preceded zIIPs, these processors can be purchased for significantly less money than equivalent GPP capacity. This means any infrastructure or application functions that can be diverted to a zIIP run at a much lower cost.
zIIP Enabler for Natural
zIIP Enabler for Natural moves the batch workload from the GPP by switching to service request block (SRB) execution mode whenever possible. By keeping the overhead involved with switching to a minimum while maximizing the execution time on the zIIP processor, reductions in GPP CPU of up to 95% can be achieved.
Figure 1: Available capacity is increased by moving a significant portion of Natural Batch to zIIP as displayed in this zIIP usage report
As you see in Figure 1, by leveraging the zIIP we can use more capacity (blue line) than what is available on the GPP (red line). We can use this additional capacity only because we can exploit the zIIP processor. The green areas represent the capacity used by Natural batch with everything above the brown line running on zIIP and everything below running on GPP.
The total amount of load that can be directed to zIIP depends on numerous factors such as the structure of batch applications, user exits, file I/O, 3GL components, external Sort, and other software competing for zIIP capacity.
zIIP Enabler for Natural is a great example of customer-driven development. An extensive one-year Early Customer Review (ECR) program preceded the GA release in December 2011. The insights provided from the ECR participants were instrumental in improving the product. Especially helpful was the collaboration between Software AG and a large IT solution provider in Austria who took the bold step and tried zIIP Enabler for Natural in production.
The most important lesson learned from the ECR was that switching between GPP and zIIP is expensive, increasing overall CPU time and job duration. Here are a few details about how some product enhancements implemented in zIIP Enabler for Natural through the ECR program significantly reduced switches and greatly improved the benefits of leveraging the zIIP:
- Caching – Because I/Os cannot be executed on zIIP processors, batch applications using print or work files on a frequent basis can cause many switch backs from zIIP to GPP – eating up the savings from the zIIP offload. By using Print- / Work-File caching to reduce the number of switches, this limitation for zIIP was eliminated. Even non-zIIP enabled batch applications benefit from this feature.
- New Adabas Communication – To avoid switches for Adabas calls altogether, Software AG R&D implemented a new form of communication for ADALNK to communicate with the Adabas Nucleus. This new communication does not require the return from zIIP to the GPP, thus reducing the number of switches dramatically and allowing even more CPU consumption to be moved to the zIIP.
The new Adabas communication was breakthrough in reduction of overhead. The improved product was put back into production by the ECR customer for their end of quarter batch processing and the results were more than satisfying. The total number of switches went from millions to just a few by using the new Adabas communication.
While the total CPU consumption (time on GPP + time on zIIP) is still slightly larger than running on GPP alone, this overhead is perfectly acceptable as most of the load is now running on the low-cost zIIP. For example, our ECR participant only saw a 10% increase in CPU overhead for a total CPU of 110%. However, since about 80% of the total CPU time was directed to zIIP, the GPP load was reduced from 100% to 22%.
Monitoring zIIP Exploitation
zIIP Enabler for Natural provides statistics on how much load is moved to zIIP as well as how much load could not be moved due to limits on zIIP capacity. You can forecast how much load can be directed to zIIP in your environment from statistical reporting. Even if you currently don’t have any zIIPs in place, the statistics will tell you how much load could be moved to zIIP for each Natural batch job as IBM has added “PROJECTCPU” as an option in PARMLIB member IEAOPTxx. With Natural v8, output of statistics can be controlled globally via a Natural parameter. In previous versions, modifications to the JCL were required to obtain statistics.
With webMethods Optimize for Infrastructure you have additional means of monitoring zIIP exploitation. webMethods Optimize for Infrastructure provides a single holistic view across your Software AG product landscape to let you identify potential problems at a glance as well as identify opportunities for performance improvement by evaluating Key Performance Indicators (KPIs).
Now you can also monitor the impact zIIP Enabler for Natural has on your system from a single, web-based dashboard as shown in Figure 2. These new monitoring features added to Optimize also provide an accumulated view of overall zIIP utilization as well as trend analysis over certain time frames. Here you can easily measure the CPU savings achieved with zIIP Enabler for Natural.
Figure 2: New zIIP Monitoring in Optimize for Infrastructure
What zIIP Enabler Means To You
By zIIP enabling your Natural applications, you can:
- Reduce Mainframe Operating Costs - Realize significant GPP CPU savings, often between 50% to 90% or more, thus reducing the overall total cost of computing on the z/OS mainframe.
- Postpone Hardware Upgrades - For customers who are reaching their z/OS capacity limit, this low-cost alternative to increasing capacity on existing GPPs allows you to stay longer with your existing hardware.
- Save Software Costs - Most software is priced based on the capacity represented by or the utilization of the configured GPP, independent of any specialty engines. Consequently, any work moved off the GPPs to zIIP is free from a software perspective.
- Improve Price-Performance Ratio - Achieve higher throughput with the low-cost computing power of the zIIP and defer processor upgrades—and their attendant software costs—significantly improving mainframe price-performance and further reducing the mainframe’s TCO.
* IBM zIIP engine - available on z9, z10, z196 and z114 processors
* z/OS version 1.6 or higher
* Natural v4.2 SP7 and up
* An Authorized Service Manager (ASM) has to run to allow a Natural session to use the privileged functions
* Natural Batch applications
Ask your Software AG sales representative today about projecting your ROI for zIIP Enabler for Natural, before even acquiring zIIP processors. Software AG will conduct a free Proof-of-Value Approach by
- Selecting some critical batch jobs with high CPU-usage and long run-times
- Running select jobs without and then with zIIP-enabled Natural
- Analyzing the results to determine your specific ROI