Miklos, In addition to Jim Marshall's excellent comments, I think you may wish to test capacity increases using the z9 BC. One standard way to do that is to get On/Off Capacity on Demand (OOCoD). That should let you test a higher processor capacity for as little as one day and pay only for that processor-day.
I think you currently have a 2066-0C1 model. I have slightly different numbers than Jim for what would be a doubling of capacity, which I define as increasing the approximate transactional capacity measurement by at least 100%. I think you'd have these (ultimate) model choices in the z9 BC (2096-xxx): 1 CP: 2096-V01 - 42 MSUs full capacity 2 CPs: 2096-P02 - 41 MSUs full capacity 3 CPs: 2096-N03 - 43 MSUs full capacity 4 CPs: 2096-M04 - 45 MSUs full capacity Your current 2066-0C1 is 25 MSUs full capacity, so your MSUs will not double when you double capacity with a z9 BC. If you want to double your MSUs, the closest matches would be a 2096-Q02 or 2096-W01 (47 MSUs), or a 2096-O03 or 2096-R02 (52 MSUs). However, typically a -Q02 will provide about 134% more transactional capacity than your current system. Your IBM software charges should not double when your double your MSUs, even if you are licensed for full capacity. (Not even close.) There's no "wrong" answer here: how many CPs you should get depends on your workload(s). Usually a performance expert can look at your current system's workload (and trends) and predict, with a reasonable degree of confidence, which configuration makes the most sense. Or you can test. Or a little of both. Note that on the z9 BC you have 7 engines you can configure, and up to four of those can be CPs, so you'll want to keep the 7 and 4 numbers in mind as you plan for growth. If you're adding a lot of zAAPs, zIIPs, IFLs, or ICFs, then these numbers might be relevant. I totally agree with Jim that you only need to buy what you need. If you really are doubling, go for it. If not, estimate your growth and work with vendors to get sensible, strategic multi-year contracts. If that means someone wants to sell you something you don't need right away, that's fine and *might* even make sense, but just make sure it makes sense within your overall business case. As a slight digression, one of my personal ongoing frustrations is that a lot of customers buying a new mainframe (or upgrading to a new model) don't also pause briefly to (re)consider software contracts. Yes, you can (and do) pay for IBM software month-to-month (z/OS, z/VSE, DB2, etc.) But if you know you're going to pay for at least a certain amount of DB2, IMS, CICS, z/OS, MQ, etc. for two years, or three years, or whatever, then tell IBM (Software) that! If you're buying the machine, you're probably not buying to run it only one month. If you tell IBM about your probable MLC, then IBM can offer you an Enterprise License Agreement (ELA) or similar. And an ELA could get you access to "cool" new one-time charge (OTC) software for your System z. If anyone needs suggestions about what OTC products to pick in their particular situation, I'm full of suggestions. The rough analogy here is flying a particular airline regularly but refusing to give the airline your frequent flyer number. I don't know why anyone would do fail to do that, yet some people do. Another possible consideration is what to do with the z800. You can upgrade the z800 to the z9 BC and keep the serial number if you like. If it's your only machine -- no Parallel Sysplex -- then you will need to take a scheduled outage to do that, but many, many customers take that path. (Sounds like you might have Parallel Sysplex, though, although maybe logically within a single frame?) You can also get a brand new machine (new serial number) and sell the old one (or return it if the lease has ended). Or send the old one to my home, freight pre-paid, as a donation.... :-) Yet another possible option that may make sense is to move the z800 to a second location, put it on "cold standby" (no software charges), and use it as a disaster recovery machine. Then, whenever the next model comes out, get that model (within a reasonable period of time) and move the z9 BC over to replace the z800. From that point on you maintain an "N-1 Cold Standby" disaster recovery strategy. Whether this strategy makes sense or not depends on a number of factors, financial and otherwise. You may already have a disaster recovery strategy in place -- maybe even a better one. But I thought I'd mention it as it can often be a very good strategy. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM 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
