John, In addition to the points raised previously -- there are many good ones -- there's also the issue of "One-Time Charge" (OTC) software to consider. I'll give you a typical scenario.
Let's suppose you have some z/OS tools, a couple CICS tools, a couple development tools, etc. Let's further suppose these OTC tools are licensed at 40 MSUs to your z9 BC, and you are not in arrears on your subscription and support (maintenance), so you can phone the vendor(s) and get support, get new versions at no additional charge, etc. So you're paying 40 MSUs of S&S per product per annum. Let's even assume all tools are licensed as sub-capacity (which is the "best case" scenario). Now you migrate to a z800. To maintain equal performance you would need about 50 MSUs on a z800. (That looks like a 2066-002 to me, which is 60 MSUs -- z800 capacity is a lot "lumpier" than z9 BC or z10 BC capacity. But let's ignore full capacity complications for now and assume the "best case.") And that means you now must pay all your OTC vendors an up-front license payment for the 10 additional MSUs. That's not good. "Ah" (somebody says), "no problem, we purchased 50 MSUs of those products some time ago, so we've got 10 MSUs to burn." Well, perhaps (if you did), but it doesn't really work that way. You've only been paying for 40 MSUs of S&S, not 50. (I've never seen anybody pay for S&S they don't need. If you are, stop doing that now.) So yes, you have the licenses sitting on the shelf, but you're in big arrears on those 10 MSUs of S&S you didn't pay. So you have to pay multiple years of back maintenance, plus (typically) a penalty. And you have to pay the back maintenance up-front, before deployment to the z800. (And generally back maintenance is not considered a capital investment, so no tax benefits for you.) If you don't pay the back maintenance, the vendor won't support *any* of your MSUs. Also, if the vendor introduced a new version (or multiple versions) while you were not paying the higher maintenance, you do not have a license for 50 MSUs of the new version. You only have a license for 40 MSUs of the new version plus 10 MSUs of the old version. So if you try to run 50 MSUs of the new version on the z800, you are violating the license terms. You still must pay for those 10 MSUs. And of course your forward S&S has a higher price, because it's now 50 MSUs instead of 40. And growth (transaction volumes, etc.) now costs more and/or you're that much closer to caps/tiers. Clearly none of this is good. ....Actually, what you should be looking at is a z10 BC business case (in at least a couple variations -- at least one of which should be a "what if I optimized *all* of my IT?" case), comparing that with alternatives. One variation on that business case might be to put your z9 BC into a Capacity Backup (CBU) disaster recovery role if you don't have that currently. (Of all the business risks -- and costs -- lack of DR is, generally speaking, gigantic. Especially in your industry.) There's also the new Architecture Level Set (ALS) issue. Let me ask a serious set of questions (which you may wish to pass along): 1. Is it your organization's practice to purchase 2002 vintage Intel/AMD servers in 2009 (and to run them for some years forward)? If not, why not? The 2002 vintage used servers are "cheaper," aren't they? 2. Understanding that a mainframe is an entire "data center in a box" -- and I think you only have one of them presently -- is it your organization's practice to make sure that *every* Intel/AMD server in your entire data center is 2002 vintage hardware, and never anything newer? 3. Has your organization *ever* replaced multiple 2006 or 2007 vintage Intel/AMD servers with 2002 vintage servers? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [email protected] ---------------------------------------------------------------------- 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
