This wouldn't really help use with zAAP. A zAAP runs only JVM based code. We don't have any. So I don't have any historical information to prove cost savings. My desire, perhaps insane, is to migrate some code for COBOL/CICS to Java/Websphere (or Tomcat or Jboss). But this is new work and we are not open, right now, to new ways of doing things. Especially if they require a capital outlay without a proven cost savings. To the best of my knowledge, the only thing we have which would use a zIIP is DFSORT. We don't have any RDMS at all. We are 100% pure VSAM.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Timothy Sipples > Sent: Wednesday, December 09, 2009 2:30 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Anybody compared: Java vs. intepreted REXX? > > The zAAP or zIIP procurement question has a relatively simple > answer (for a > static analysis). You just pull out the RMF report for at least your > monthly peak interval, find out how much (if any) zAAP- or > zIIP-eligible > workload was running at that interval, translate that into an > MSU count, > calculate what that means financially, then compare that > against acquiring > a zAAP or zIIP. (Or more than one.) If you have a > "non-trivial" amount of > eligible work, it'll make financial sense to do. > > That's the static analysis, for something that's already running. The > dynamic analysis is more interesting -- and more business > savvy -- because > it introduces the question, "So, what if I had a zAAP or a > zIIP (or both)? > What could I be doing different/better/more efficiently/with > higher service > qualities?" In other words, where should I be placing > particular business > application functions? > > And there's a simple, general answer to that question: the > mere existence > of zAAPs and zIIPs means that you should, at least at the > margins, place > more business application functions on System z which have > zAAP/zIIP-eligible work -- and use zAAP/zIIP to do it. That's why they > exist, after all. Assuming business function X has to run > *somewhere*, it > will not be free to run. It always costs money. So where does it make > financial sense to run? The zAAP/zIIP technology is one of > those things (on > a long and growing list -- the Solution Edition offerings are > additional > examples) that skews that decision more in favor of the mainframe. (Of > course, there are also the QoSes to consider, and those > certainly matter.) > > There are still many more elements to a proper dynamic > analysis. One I've > talked a lot about here are the proximity effects. That is, > if you simply > bring certain application functions together on one machine -- if you > co-locate them -- and compare that to deploying them on > multiple smaller > servers with LAN or WAN cables between them, you can see > different results, > often dramatically different. The speed of light and network > latency can > matter, a lot -- and they influence things like CPU (and > monthly peak four > hour rolling averages). Two plus two does not equal 4. Two > plus two often > equals 3, or even 1. > > Another one (that I've mentioned also, but will repeat) is > that (to a first > order approximation) unused CPU capacity below monthly peak is quite > literally free to use. OK, I guess that is a very notable > exception to the > "it will not be free to run" statement. On mainframes you > often do have > free capacity, and you can run additional business functions > for zero (or > darn near it) cost. There are many people who say that a > mainframe is batch > processing machine which offers free online, or an online processing > machine which offers free batch. That's another version of the "some > workloads really are free" reality. (As an aside: what is the correct > chargeback for a free workload? :-)) > > Finally, a couple comments about peak monthly MSUs. No, those > are not free. > Sorry about that. But here's what's true about them (assuming VWLC): > > 1. They're extremely granular compared to alternatives, not > "lumpy." If you > need 1 more MSU of DB2 (beyond a short duration spike), you > pay for only 1 > more MSU, for example. > > 2. There's a very sharp cost curve. If you double your MSUs, > your costs > don't increase double. Not anywhere near it. Thus your per-transaction > (total) costs fall dramatically as you grow. (And if you > double your MSUs > you're probably actually delivering *more* than twice as much > real work, > due to improved utilization efficiency for a variety of reasons.) > > 3. But if you have a bad month (or year, or two), your costs > *automatically* fall (along the curve in #2). Oracle (but one of many > examples -- basically *everyone* else) doesn't give you money > back on the > database license (or subscription) if you have a bad month > and only need > 11.6 CPUs instead of 18.5 (which is rounded up of course). > > I'm oversimplifying, yes, but not much., > > Sorry if I'm repeating old information, but this stuff is important. > Unfortunately a lot of people just don't understand it. IT > economics, which > includes mainframe economics, are quite "interesting." > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: timothy.sipp...@us.ibm.com > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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
