John: >From a memory circa 1980(s). A company in downtown in Chicago got thier >throats cut with upgrades to CPU capacity. I do not remember the upgrade but the software alone cost them $250,000 this was mostly (IIRC) a computer associates bill. Another big cost was a DB2 product add on. That had similar figures (cost wise). Within a few years they moved out of DT to the burbs and another big $$ was paid for the move.
The DB costs were totally out of line, IMO. Because of that the company I was working at the time refused to consider ever going to DB2. There were side issues that could have been worked out I belive but our show stopper was the size of our DB. My iffy memory from around the time out DB was 40 3350's (or was it 3330-11's ?) we were essentially out of space (floor wise) for more DASD. We were also growing leaps and bounds every year for the size of the DB. But our best guess at the time was that DB2 couldn't handle our environment. We were at the top end of storage and CPU with no where to go. We ended up with a consultants DB (which I will admit was fast and reasonably quick) so that staved off upgrade. I do not think we could have afforded anything like $512,000.00 for upgrades. We wanted the consultants product out but IBM could not come near replacing it. Ed ________________________________ From: John McKown <[email protected]> To: [email protected] Sent: Sat, April 16, 2011 6:58:30 AM Subject: Re: CPU utilization/forecasting On Sat, 2011-04-16 at 11:13 +0200, R.S. wrote: <snip> > Last, but not least: CPU granularity. > You cannot buy 5% CPU more, or 35%, or 41%. You can buy CP, not half of > it. Situation is much better for smaller machines - mix of n-WAY + > subcapacity levels gives you really good granularity. However neither > MSU, nor MIPS should be used for capacity planning beacuse YMMV (IBM words). > > So, rough estimations are quite OK here, especially that your business > growth estimates are also rough and are not proportional to CPU > consumtion. Not to mention unplanned, "small" enhancements... > > A very good point. I would restate in terms of MSUs since that's what we are billed on. We currently run a z9BC Q02. Which is rated at 46 MSUs. So that's generally 23MSUs per CP. So if we need only 10 more MSUs, we must go to a Q03 (assuming it were possible). But that would result in a machine with 69 MSUs whereas we only want 56 MSUs. Luckily, we can get the 56 MSUs billing we want by using "Group Capacity". I would say that if it were not for MSU based billing, everybody would be happy with just getting a new CP and having the excess just sitting around. In this case, the upgrade cost would only be the cost of a CP. But with tiered software costs, adding a new CP has financial considerations beyond the cost to acquire and maintain the CP. Especially if you have software which does not support sub-capacity billing. I hate tiered pricing. It is the main ammunition being used to eliminate the z. Not the reason, the reason is the the PHBs just don't want to be bothered with a multiplatform environment. It is more difficult for them to manage and they must learn how to manage something other than Windows. God forbid they should need to learn something new. Or do something other than what the Microsoft rep tells them to do. Hum, reminds me of the "glory days" of the past when IBM ruled and management obeyed. "The more things change. The more they stay the same." -- John McKown Maranatha! <>< ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
