Al Sherkow refers to an excellent redbook ("z/OS System Programmers Guide
to Sysplex Aggregation"). I do want to point out one relatively recent
change after that redbook was published.Some customers reported that adding zAAPs and/or zIIPs caused workloads to shift to the specialty engines (as expected), but this shifting resulted in them falling below the "50% rule" on one or more machines. That was not IBM's intent. Therefore, while there is never any IBM software license charge associated with zAAP or zIIP capacity, for purposes of Parallel Sysplex aggregation the work running on zAAPs and/or zIIPs associated with each LPAR *does* count toward qualification. For example, let's suppose you have three LPARs on a machine, and this machine currently qualifies as a member of an aggregated Parallel Sysplex. Let's suppose only one of those LPARs is connected to the relevant Parallel Sysplex, and that single LPAR currently represents 55% of the prime shift workload on that machine. Let's further suppose about 20 of those 55 percentage points are consumed by an application running in WebSphere Application Server for z/OS. And let's suppose this is the only zAAP-eligible workload on the entire machine. Now you add a zAAP to that machine. Let's suppose the zAAP executes 15 of those 55 percentage points (i.e. 75% zAAP eligibility for that application). The zAAP has now reduced your 55% to about 47% (if my math is correct), but that's if you are only looking at CP (general purpose engine) capacity. Would adding this zAAP put your Parallel Sysplex aggregation for that machine in jeopardy? No. You count the normal prime shift workload *inclusive* of zAAP and zIIP workload in order to determine whether you meet the 50% rule. I think the redbook might say the opposite, but I am reliably informed that this zAAP/zIIP treatment is now in our customers' favor, as I described. I may have mentioned this information previously, but it probably bears repeating. As a side note, in another thread I alluded to the fact that Parallel Sysplex may have benefits that tend to reduce capacity needs (and/or defer capacity upgrade needs) in certain situations. Addition of a zAAP or zIIP to one member of a Parallel Sysplex is one such example. Eligible work on that machine would migrate to the zAAP or zIIP, freeing up CP capacity. With more CP capacity on that machine, workload could balance out from the other machine in a Parallel Sysplex. Capacity is more fungible across the Sysplex, and there are scenarios where that could offer benefits. (The benefits are in some ways similar to physical consolidation.) In particular, if you have two machines, and those two machines have peak four hour rolling averages each month that occur at substantially different times (or on different days), it's possible Parallel Sysplex would offer some peak-reducing advantages beyond the aggregation advantages. Please note that I am assuming a "reasonably well balanced" Parallel Sysplex, with enough workloads eligible to run on either member at any given time. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
