I think you're right on it Bob. And I totally agree that perspective comes into play when looking at this, thanks.
For us taking delivery of WAS 3.02 back in 2001, as freeware if I remember correctly, seemed like a prudent move to save work from continually going to the other side. We had a development management type who worked mainframe and midrange/open who's vision was to deploy where he believed the work should be hosted. When we put WAS 3.02 up on a small RB6 G5 machine they jumped on it. It was not a pretty sight from a performance capacity perspective, in the early stages. My rants are in the archives here and on MXG. We managed to work out bugs in the application and as a single server instance I did not have to do much in WLM to find a spot for it in the hierarchy. We eventually upgraded to WAS 3.5 and then 4.0 (3.5 compatibility mode single server instance). All was still relatively good except for the CPU spins we would take which would bring the system to its knees - I built a resource group for those special occasions. When it was decided to move to WAS V5 that's when I started to really feel the pain due to the construct difference between single server instance and cell group. At this point we were already looking at z800 and then z890 and at that point, from a pure performance/cost perspective, the only option getting us out of that mess was a zAAP. The upgrade costs to support anything other than a similar speed z/890 w/zAAP were prohibitive. And to me personally, as the performance guy, I'm looking at it as a significant performance improvement over another knee-capped GP CP. I'm currently in a similar situation right now with an older z890 and similar speed GP CP's and no zAAP trying to shoehorn WAS V7. So while I agree Mark with your statements about engine switching overhead and running all GP CP's over a mix of GP & SP CP's there are obvious situations where a knee-capped machine w/SP CP's can out perform an all GP CP knee-capped machine. So in effect, this is my *perspective* of the overall situation and how we evolved with WAS on the mainframe. And while I did say in a previous post *something had to be done* I still feel something did have to be done to help supplement the CPU requirements of WAS while limiting is potential performance impact to the traditional work all running together on the same LPAR, from a performance perspective. I'm not talking about 10 way high speed machines here, I'm talking about a lot of folks just trying to move ahead with the technology in small and mid-size environments where the luxury of having full speed GP CP's is not an option. That costing/marketing gimmicks came into play is all good and added to helping customer stave off some of the migration to other platforms. --- On Fri, 2/5/10, Richards, Robert B. <robert.richa...@opm.gov> wrote: From: Richards, Robert B. <robert.richa...@opm.gov> Subject: Re: IBM countersues Neon over zPrime accelerator To: IBM-MAIN@bama.ua.edu Date: Friday, February 5, 2010, 12:06 PM Far be it from me to play the role of IBM's defender, but I cannot let this exchange go unchallenged. Here we have a case where Eric expresses an opinion and Paul treats it as fact and raises the stake in making IBM be the bad guy. Enough with revisionist history. I see it all the time in this town and am loathe to put up with it in my favorite industry. Eric's assertion is wrong (sorry Eric, but it is...customers always have choices. They may not like them, but they have them). At the time of its introduction, the zAAP was marketed to entice the Java crowd to come play on the big boys' machines at a cost that would not break their software budget's back. One of the many benefits to IBM was bragging rights of J2EE on all platforms, a very significant thing. The big boys observed that they finally had a way to run Java on the mainframe that would not break the software usage bank because of expensive Java cycles on general purpose processors. It was a win-win for the customers that could take advantage of it and, of course, IBM. Prior to that, IBM was not very successful at promoting Java on the mainframe, so as the passage of time has shown, the new strategy clearly worked. Assigning ulterior motives to things IBM does can be fun, bloodsport, like politics are in this town. But sometimes, IBM really does behave like the good corporate citizens they should be and are making a profit to boot. After all, are we not still a country that admires free enterprise? Oops, that slipped out..... :-) One comment to add to the processor discussion; IBM started marketing the 9672s with 12 CPs in every box when they determined that it was more cost-effective to do that than to produce the 4 and 8 CP models as well (G4/G5 timeframe?). Using microcode to control the power....who ever thought of that idea should still be trying to spend the bonus for that suggestion. Clearly, there are going to be folks that disagree with this post. I welcome your thoughts. For me, I'm thankful that IBM's technology has provided me with a career for the last thirty plus years. Bob ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
