I am not sure what to say. Throw hardware at the issue is an easy and progressive fix ( Moore's law).
I am with the balanced approach. Put the effort in and determine where the biggest bang for the buck is. Not to give development a pass.. But they have agendas and time lines and people demanding things. Some saying about honey and bees comes to mind. Harping on right and wrong will carry with sys progs and the hardcore.. And be lost on those that you need to be involved. Getting upper management "on board" in the hard case s... Will definitely include cost justifications. Rob Schramm On Apr 6, 2015 4:50 PM, "Farley, Peter x23353" <[email protected]> wrote: > Tim, > > Though your points are well spoken and reasoned, you still did not address > the basic organizational issue the OP is facing - How does any application > team or management justify the level of profligacy described, all by > itself? While it may be true that the fixed costs of the organization's > currently financed MSU's are "there to be used", as you imply, being > responsible for pushing those financed MSU's over the current limit on a > regular basis, or seriously impacting the SLA's of other parts of the > organization should, by rights, involve both executive and financial > management teams in making a decision as to the wisdom (or not) of devoting > some reasonable application developer time to a reasonable (i.e., not > obsessive) performance optimization effort. How does any mere application > management make that serious business judgment all by itself? > > That is the part of the whole scenario which (it appears to me) the OP's > executive management are not seeing, or at least are not being made clearly > aware of. > > On the other hand, said executive management may be of the same blindered > type as John McKown has told us he suffers under, in which case all bets > are off and the devil takes the hindmost. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Timothy Sipples > Sent: Monday, April 06, 2015 12:55 AM > To: [email protected] > Subject: Re: A New Performance Model ? > > >Highly skilled development talent takes performance and resource > >utilization into consideration during design, development, turning and > >testing. > > Agreed, but only to the degree merited in the circumstances. Highly skilled > development talent and management also know where best to allocate their > precious efforts, in business priority order, and when to stop (or at least > pause) in their efforts lest they incur costs without adequate returns. > > >Based on what was described, 0c4 and 0c7 abends were eliminated by grossly > >over allocating tables to eliminate memory overlay. > >By my experience, this does not sound like highly skilled talent, > >regardless of expense. > > Quite possibly! But that only reinforces my point. Perhaps the organization > underpaid (in the circumstances) for talent and thus obtained a level of > talent highly correlated to that underpayment. There's also often some > degree of functional risk in performance optimization efforts regardless of > expertise, and that risk has a cost, too. > > Anyway, I have no clue what the "best" answer is from afar in these > particular circumstances, and no one else afar should either. :-) Maybe > this organization's development management made exactly the correct call in > their particular circumstances, and maybe they didn't. The former is at > least plausible, and we cannot and should not reflexively assume the > latter. > > By the way, the fact you're paying $X million per year for anything in IT > now doesn't mean that you'll pay twice $X million if this particular > development team doesn't do what you think they ought to do and what you > think they could do, even if they caused a doubling of peak "MIPS." Isn't > *anybody* familiar with basic cost concepts such as fixed costs and > marginal costs? Those concepts shouldn't be too hard to grasp. Airlines, > for example, certainly understand those concepts. That's why they generally > push as hard as they can to *increase* fleet utilization and passenger load > factors, to keep their airplanes moving and carrying as many fare-paying > passengers as possible every possible minute they can as long as they can > generate a profit on each trip. > > Will payroll for the operations team increase if the development team > doesn't (or cannot) reduce peak 4HRA "MIPS" by XX? That'd be nice if you're > part of the operations team, but sadly, no. Generally speaking that > particular part of the IT budget won't change. The development team cannot > materially affect those fixed costs, in general, as an example. > > These really aren't hard concepts to grasp, I hope. Some of us occasionally > go buy a beer. Others of us spend 10 hours per bar outing searching for > coupons to get a 10% discount on the same beers, perhaps in vain. Which > approach is best if you want a beer? I don't know, and you don't know > either. "It depends." How valuable is your time? How valuable is that > hypothetical 10% discount to you? Do you derive value from the discount > hunt itself, and the longer the hunt the more value you derive? If your > date sees you present a coupon for your beer, do you scare your date off, > and what's that cost? Does that 10% discount require adding your name to a > mailing list, adding more junk mail to your inbox? What's that cost? Should > you buy your beer at a bar at all? Perhaps the best answer in your > circumstances is you should never end up at the bar -- you should just keep > hunting for coupons. :-) Or perhaps you should just go have a beer, at a > bar, and enjoy yourself in your profligacy. Allegedly there was a certain > IT multi-billionaire who was/is rather infamously well known for spending a > considerable amount of time in the supermarket checkout line digging > through his wallet for a couple 20 cent off coupons to present to the > cashier, considerably delaying those behind him in line. The people waiting > for him to dig out his coupons thought he was nuts. They were probably > right. > > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA > E-Mail: [email protected] > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
