Right... In a situation where we consolidate 200 databases (with licenses) to 2 or 3 engines, it is a win.
When you consolidate 200 different applications to two new IFLs (that is 400 license/engines) and then may need to license those 200 different application on the two existing IFLs, which they will never execute on (another 400 license/engines), you start loosing your software advantage very quickly. The hardware is already a lot more expensive then the Intel side. You just can't justify server consolidation just on hardware savings, it just costs more. But when you throw in software savings, manpower, ease of disaster recovery etc, you can justify things. But hardware and software costs are things that any accountant can see. Real dollars. All the rest of the stuff is soft dollars. Informed people know there are savings and have gut feels that justify things. Try explaining those things to a government watchdog reporter. You got 5 minutes...now go... Soft dollars savings just can't easily be explained. Another example, it has been interesting trying to explain, how spending $560K for a new mainframe, to replace 204 existing servers, will save us, perhaps millions over 3 years. Will there ever be a record of these savings? No. When a department finds out that we are going to take over their database server, what will they do? 1. Gee, thanks, here is the money, for you, that I would have spent on support over 3 years? That includes hardware, software and manpower. Noop. 2. Gee, thanks, At the end of the fical year, the money I didn't have to spend will go back into general revenue? Noop. 3. Gee, thanks. I want it done this week. (And then I will take the funds I would have spent and will be able to fund other projects on my list.) ding ding ding...we have a winner. The only hard numbers which appear in the budget, is hardware support costs (if there is a support contract), software annual support costs (if support is being bought). Those number might be fed back to general revenue as savings. But basically, no one will know how much money is saved, as they don't want next years budget to be reduced by that amount. (It happens the same way in corporate also.) And then the reporter asks...in 30 seconds, can you explain what happened to all the saving you projected? Just laugh and walk away... Anyway, it is the software side that can still be the monster. Kind of reminds me of tiered pricing on the S390 side. As long as you only have a few licensed products, you are ok. But instead of 10 licensed products on a Group 30 processor, have 50 licensed products on a Group 50 processor, and the weight of the software charges, sinks you. (Or makes you convert to MVS to get measured usage charges, instead of tiered charges.) Tom Duerbusch THD Consulting --- Rich Smrcina <[EMAIL PROTECTED]> wrote: > Like Alan and others have said, this is negotiable. > Check with your > vendors to see how flexible they are. > > What you also need to account for is that if you > have 200 database > servers, you are now paying for that software for > 200+ engines. > Consolidated to your 3 IFLs will drop that to 3 > engines. The same holds > true for the other software. > > Tom Duerbusch wrote: > > Perhaps...I never thought we needed more than 256K > > either<G>. > > > > Whether it is 32 or 8 IFL engines. In a mixed > > application environment, if an application that > > supports 8 users and is on 1 IFL engine, you have > to > > license it for all engines (the default...as > > mentioned, you can negoiate with the vendors). > > > > My initial concern was how, in a box with 1 390 > engine > > and 1 IFL engine, do we keep from being charged > for 2 > > licenses for any "linux" type software, as the > > software can run on either engine. > > > > OK that is apparently on the honor system. > > > > Then I started questioning multiple IFL engines. > In > > our first large project, we are planning to > > consolidate 204 database servers to the mainframe. > > > > Could have fooled me. I had no idea we had 204 > Intel > > servers out there, much less 204 database servers! > > And I'm told we have another 200 database servers > plus > > all the application servers! We are a small, > local > > government! > > > > Ok moving all of this to VM/Linux/Oracle, I don't > mind > > the software charges. But if we start tackling > the > > application servers, each one, may be a different > > product and would need to be licensed for each IFL > > engine. Most will serve 5-10 users. > > > > Now if each application costs $2k per engine and > we > > can get 50 of these consolidated on an IFL, that > is > > $100K for software. No biggie. > > > > But I thought I would have to license for the 2 > Oracle > > IFLs also (another $200K), plus I now have to > license > > Oracle and Websphere and of course z/VM on the > > application IFL (add another $150K). > > > > Now if I go to a forth IFL (not going to happen on > the > > z/890 as one engine is s390), then it would be > another > > $100K for the additional applications being > supported > > on the 4th IFL, plus $100K for the additional > license > > for the software on the first application IFL, > plus > > $150 for another license of Oracle and Websphere > > (which will never use cycles on these IFLs) plus > z/VM. > > > > So we are now up to a software charge of $350K for > the > > 4th IFL. And it keeps getting worse with more > unique > > applications being loaded on. > > > > As long as we only pay for some large applications > > that take a large percentage of IFL(s), and/or > only > > use a variety of small, free/cheap, software, > server > > consolidate keeps working well as we scale up. > > > > As I don't know much about the pricing in the > server > > world, (perhaps everyone just pays it without > > question), but I wanted to gain insight on how > things > > scale up. So when the non-trivial servers are > > targetted for consolidation to the mainframe, I > can > > stop that, or at least warn of the cost > considerations > > as IFLs are added. > > > > There is a lot of concern in government about > 9/11, > > terriorist, Microsoft/viruses, etc. I can > envision a > > push to put everything back on a common platform, > with > > a duplicate platform at a disaster site. > > > > It would be really helpful, if the licensing could > be > > arraged for all engines in the "licensed" lpar. > Each > > lpar would have x engines and support a certain > > software mix. Another lpar would have a different > > software mix and software charges would only be > for > > those engines in that lpar. > > > > IBM would need to have something to be able to > > restrict the number of engines available to an > lpar. > > Still allowing some engines to be shared but to > cap > > the max capacity of that lpar. Venders may need a > > piece of code that checks to be sure it is running > on > > a licensed lpar...LPAR04?...check. LPAR05?..no > go. > > > > A couple IFLs, not a big deal. But about 7 IFLs, > and > > it start costing a million to add another IFL. Of > > course, you wouldn't, it would be cheaper to buy > > another box long before then. > > > > In my spreadsheet projections, it is cheaper to > buy > > another z/890 then to add in a third IFL if the > IFL, > > not only needed to license all current software > for > > that engine, but any new software to make use of > that > > IFL would have to be licensed for all 3 IFL > engines. > > Cheaper to buy another z/890 and when they hit the > > used market, it may be cheaper to only have a > single > > IFL per box. (Can we rack mount z/890s? <G> I > know > > we can't, but it looks like we start slipping back > to > > multiple physical servers.) > > > > Tom Duerbusch > > THD Consulting > > --- Dennis Wicks <[EMAIL PROTECTED]> wrote: > > > >>I think there must be some confusion somewhere. > IFL > >>\= LPAR. > >>I doubt anyone other than JPL, NOAA, NASA and > other > >>such > >>huge places would ever need 32 processors, IFL or > >>otherwise. > >>That is a *HUGE* amount of processing power! > >> > >> > >> > >>|--------+----------------------------> > >>| | Tom Duerbusch | > >>| | <[EMAIL PROTECTED]| > >>| | scity.com> | > >>| | Sent by: Linux on | > >>| | 390 Port | > >>| | <[EMAIL PROTECTED]| > >>| | ST.EDU> | > >>| | | > >>| | | > >>| | 04/05/2005 12:04 | > >>| | PM | > >>| | Please respond to | > >>| | Linux on 390 Port | > >>| | | > >>|--------+----------------------------> > >> > >> > >>---------------------------------------------------------------------------------------------------------------------------| > >> | > >> > >> | > >> | To: [email protected] > >> > >> | > === message truncated === ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
