>Has anybody seen any updates to the 3/31/2007 date for End-of-Service on >z/OS 1.5? The IBM web site still has an "*" next to it indicating it has >not been officially announced yet. >Is there any offering available from IBM that will still get you z/OS >1.5 for those of us still stuck on G5 hardware? >Dennis..
I've asked and haven't heard anything that would suggest a service extension (as least not without a fee). Everybody is saying "plan now, act soon." However, I'm hearing reports of used z800s diving well into the five figures (U.S. dollars), so the 64-bit hardware has gotten pretty inexpensive (i.e. less than a single mid-range UNIX server) at just the right time, thank goodness. I'm familiar with a county government that did exactly that (G5 class to z800), and it went very smoothly (and actually will save their taxpayers a bit of money because maintenance is lower and software is a touch lower in their case). I always recommend running a full set of numbers and "what ifs?" Including a check to see if an IFL or two would be useful to save IT money through server consolidation. (All the 64-bit boxen support Hipersockets which have the interesting side effect of making z/OS work less hard servicing requests from onboard Linux versus any offboard servers, and that can be financially beneficial too.) So why is 64-bit becoming a base requirement for z/OS? It's only for good technical reasons, I assure you -- you don't make too many architectural changes, even improvemens, without addressing somebody's business requirement. We saw some limits approaching and had to begin the process back in the late 1990s for the 64-bit transition. (Since we're talking about mainframes, it's a nearly decade long transition -- it has to be at a reasonably slow pace.) A good example is DB2: DB2 V8R1 requires a 64-bit system because we have some customers that were stretching the limits of V7, and V8 offers constraint relief. SAP now requires DB2 V8. We also have a 64-bit Java now because there were some customers running out of heap space (in Java batch, notably, to avoid garbage collection during long batch job), and some areas (WebSphere Portal is a good example) where we really need 64-bit very soon. Linux is another area where there are many 64-bit needs, and USS needs it (C/C++) to keep developers happy. And we're going to see more and more 64-bit subsystems and components. All that means you've got to do everything in the right sequence, and the operating system is one of those things that has to get 64-bit componentry, even for some core functions that previously ran 31-bit. Get enough of those and before long you can't figure out good ways to keep retrofitting back into 31-bit without compromising what you're trying to do 64-bit. (And "forking" has its own big headaches.) One of the last SHAREs had a really interesting technical presentation on what's going on inside z/OS in terms of 64-bit development, especially from a programming language perspective. It was over my head lots of times, but it was still really interesting. :-) Recommended stuff. So that's where we're at. Sometimes when I talk with a business manager I point out that there really aren't many servers that last (in terms of providing productive business services and functional benefit) as long as mainframes do. You don't *have* to buy them very often, especially if you buy the latest model if/when you do upgrade. (Yes, I know, some shops buy every new model that comes out and have very good reasons for doing so. But there's always a good set of technical and/or financial reasons for shops that do that.) And when you do upgrade you keep your processor capacity (or in the case of IFLs and zAAPs your processor counts), so you don't keep buying processors every three years. And yes, I know, somebody is going to chime in and say they've got five year old (or older) distributed servers running something, but see how long non-mainframe folks last if you shut off all hardware purchasing for five years. :-) Don't know if any of the above helped, but I try. Please note, as always, that I don't speak for IBM if an official capacity (ESPECIALLY when it comes to prices or selling anything) even though I work for them and am thus occasionally biased despite efforts to the contrary. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect IBM Americas zSeries/z9 Software Phone: +1 312 529 1612 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
