To amplify a part of what you said @Tim Sipples a goodly part of MY case load is in support of my Software Group VP Ray Jones in helping z/OS customers manage their usage and hence part of their software bill. Others in IBM have complementary roles. And some of you here have definitely been party to that.
Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Timothy Sipples <sipp...@sg.ibm.com> To: IBM-MAIN@listserv.ua.edu Date: 19/02/2014 09:11 Subject: Re: Optimization, CPU time, and related issues Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> Ed Jaffe opines: >Of course, "Fugget about it" is expected from IBM, but there are >software vendors making a comfortable living helping their customers >save serious cash by minimizing their monthly peak R4HAs. Some of them >spread out batch workload; some of them raise, lower, and move LPAR caps >around; some are simply far more CPU efficient than popular alternatives. Who said "Fugget about it"? Not me. I think I wrote rather the opposite. More importantly, I also *do* the opposite. I'll tell you how to run your systems at peak efficiency (if I know), and I'm very happy to do that. If you reduce your peak four hour rolling average you'll "probably" save mainframe money. Whether that's "serious" money or not is highly situational, but note that it's only ever mainframe-related cash. I think what I wrote was very clear in highlighting that if it costs you $1,000,000 in non-mainframe money to save $100,000 in mainframe money, that's, well, supremely dumb! And that supremely dumb act seems to happen way too often. In other words, I do try to keep a "Check If Stupid" circuit always active. And that's really important. You've utterly lost the plot if MSU reduction is a goal unto itself, without any context whatsoever. Shooting half your end users dead may be an effective way of reducing peak 4HRA MSUs, but that'd be another example of "stupid" and some other pejoratives besides. But let's suppose there is a reasonable, positive business case for taking action X to reduce peak MSUs by Y. Let's suppose for sake of argument you can improve the bottom line by $50. Should you go work on that $50 savings project, or should you go work on the $50,000 savings project first? I'd vote for door #2. So, to recap, there are at least two "check if stupid" steps. One step is whether there's any positive business case at all. The second, if there's a positive business case, is whether it's the first project to tackle, or whether there are more rewarding projects that should come first. You optimize when (and only when) it makes overall business sense, and you first spend your time on the most rewarding projects, not the least. That's my point, and I think it should have been obvious in what I wrote. -------------------------------------------------------------------------------------------------------- Timothy Sipples VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
