Being “Smart” About How You Use Mainframe Specialty Engines
Let’s face it — shifting workload from the general purpose processor (GPP) to the zIIP, zAAP or IFL mainframe specialty engine is smart. Really smart. IBM’s desire to make the mainframe a more attractive platform for new workload may dramatically slash the cost of mainframe integration and SOA projects.
The reduction in CPU consumption offered by properly leveraging specialty engines tells a compelling story. Run your workload on a specialty engine and not only save money, but achieve higher performance. A no brainer, right? Well….not exactly! As you would imagine, all workloads are not created equal. A major issue is the ability to selectively choose which workload remains on the general processor, and which is sent to the specialty engine.
Just because you can send mainframe SOA or integration workload to a specialty engine does not mean you should. There are many use cases where it is much more efficient to NOT shift workload to a specialty engine. Why — because, there is overhead associated with moving workload from the GPP to the zIIP or zAAP engine. The cost will vary by situation, but a good rule of thumb is that if you shift “small” workloads from the GPP to a specialty engine the savings will not cover the CPU overhead of moving the workload.
Therefore, the “smart” approach to maximize savings and performance is to be able to discretely manage the workload that is sent to the specialty engine vs. what remains on the GPP.
Another degree of required flexibility is the ability for you to choose which specialty engine to utilize. Some enterprises will have a zIIP, others a zAAP, while others may have the zIIP, zAAP and IFL engines. Organizations simply have not made a strategic commitment to one engine vs. another. We often see companies starting with say a zAAP engine, and then change their mind and switch to a zIIP or IFL.
Therefore, the “smart” approach to de-risking your specialty engine commitment is to ensure the products you utilize for mainframe SOA and integration can leverage all three specialty engines, as well as not standing in the way of changing to a different specialty engine tomorrow.
Let me be clear — vendor solutions that mandate an “all or nothing approach” do so because of shortcomings in their vision and technology.
Using specialty engines is definitely smart, managing workload on a service by service basis to maximize MIPS savings without sacrificing one bit of performance is what we call “being smart about leveraging specialty engines.”
