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] > > | > | cc: > > | > | Subject: Re: Per engine pricing.. > > | > > >---------------------------------------------------------------------------------------------------------------------------| > > > > > Now that is the kind of response, I, a mainframe > type, can work with. > On the 390 side there is little negotiation on > number of engines, just > on price. (OK so the net result may be the same > thing.) > > Assuming that this consolidation project goes > anywhere near plans, I > can see a lot of other "loads" being migrated, which > then pushs us to > another IFL and potentionally another license for > every product (right > now, without much software, a second IFL is going to > cost about $150K in > software charges. As the number of unique software > products increase, > the number of licenses * processors increase...I > worry about moving us > towards a $300k- $400k software bill for each new > IFL. It seems like we > are back to some simular to tiered software charges > that historically > limited us from increasing the 390 workload.) > > As I said before, going to 32 IFLs in a mixed load > environment, doesn't > seem to scale well. > > I would rather have a 'roadmap' that all vendors may > sign on to, that > sets some terms and limits instead of each shop > having to negotiate > starting at square one. Not every shop has the > talent for this. > > Tom Duerbusch > THD Consulting > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
