As a general rule, if you're building a business computer and want to save as much as electricity as possible, the most highly virtualized (and virtualizable) platform wins. So attributes like massive caches and screaming I/O help enormously. (I think there was a Stanford study recently that figured this out.) Thus it's no surprise a modern mainframe is more energy efficient than anything else.
But in the Computerworld article referenced in the original story, IBM says the carbon program will also be available for its System p servers at some point in the future. My prediction is that you'll typically get fewer certificates if you move to System p versus System z, but it's likely businesses will do some of both depending on what sort of applications they're rehosting. There are some types of applications that will do better on System p, and there is some software that runs on AIX that doesn't run on z/OS or Linux.
Regarding SPARC it's impossible to say since Sun hasn't entered into any carbon credit auditing system yet. The IBM-Neuwing program is a first. However, my prediction is that you'll get even fewer certificates if you consolidate to SPARC. I say that simply because I assume IBM is acting in its own self-interest, and I'm sure they think the energy efficiency fight is one they can win against other vendors. In this case self-interest and environmentalism coincide. For any of these platforms, though, businesses will figure out whether the certificates favor certain platforms over others, and they'll do that application by application (or application function by application function). And many other factors will go into the decision as well, although most of those factors pull in the same direction as energy efficiency, such as software charges. One could even imagine that before long server vendors lagging in the energy efficiency department will start bundling carbon certificates with their servers in order to compete. Thus IBM adopting this program is a smart way to respond to an untapped market need and to raise the effective price of competing servers compared to IBM's. Very smart move.
By the way, the world has totally flipped on its head, and it would be extremely misleading to say an IBM mainframe is "proprietary" and X86 (for example) isn't. What does proprietary mean? You can run pure 100% GPL Linux on an IBM mainframe -- Debian, Slackware, CentOS, etc. -- and you don't even need a closed source driver as you usually need for X86 servers. IBM publishes extreme instruction-level detail in a free book called Principles of Operation, and it's so detailed and thorough that the open source community created an implementation of the instruction set called Hercules that actually works compared to still imperfect efforts like Bochs and QEMU. (Although IBM may assert patent claims on its processor architecture.) One company is porting OpenSolaris to System z, and they didn't even have to ring up IBM. In comparison, Intel and AMD also may assert patent claims, and AMD is suing Intel for alleged monopolistic behavior. Neither Intel nor AMD publish PoO-type documents (to that level of detail). Then there's Microsoft Windows, and it's hard to think of any more proprietary OS than that.
Also, IBM changed the way it charges for z/OS software about 7 years ago. Now almost everything is charged by the amount you actually use, something IBM calls Variable Workload License Charge (VWLC). If you run a little bit of DB2 in one LPAR (partition) but a lot of IMS in another, then you pay a little for DB2 and more for IMS. You also control exactly what you consume using something called softcaps, and you can set those either per-LPAR or for a group of LPARs. One interesting little twist to mainframe subcapacity licensing is that, if you need a little bit of WebSphere (and a lot of other IBM products), the lowest entry price (smallest license you can order) is for z/OS. You can order as little as 1 "Value Uni
There's very little information to go by, but chances are if you try to rationalize this particular IT project on the basis of generally accepted accounting principles or business economics you'll quickly go crazy. And actually I'd give you more than 400 years. First of all, you're assuming the best alternative is zero. Of course it isn't; not even close. Then, hardware costs have been declining, both in real and nominal terms, and mainframes are no different in that respect. There's also net present value: you could put $800 million into U.S. Treasuries, draw off $2M per year (never mind every two), and your principle would still increase. In other words, $800 million would buy you an infinite supply of IBM mainframes, forever.
Moreover, there's no reason why the GPS operators would even need their own, separate, siloed infrastructure. They could simply move to any pair (for high availability) of mainframe data centers anywhere within the military establishment, run on a couple LPARs, and get guaranteed, highest service levels. With zero additional operations staff in those data centers. That's what modern mainframes do. (Two is a large and sufficient number of machines for most organizations.) Running your own, separate, siloed, application-specific server infrastructure is extremely expensive and oh-so-1980s.
What's even more ironic is that Sun appears to be winding down its hardware business and just announced a big partnership with IBM, including probable support for Solaris on IBM System z mainframes. Computer processor R&D is expensive, and, much like Boeing and Airbus for airliners, there are only a small handful of companies that look like they'll be able to sustain this gargantuan effort. IBM is certainly one of them.
As a taxpayer I'm angry but unfortunately not surprised.
I didn't write the Wall Street Journal article, but I would assume the 135 million figure is significant because it refers to a large installed base that will get Open Document Format support. The fact Lotus Symphony is now available as a free download is wonderful and will add to ODF's marketshare, but it isn't the whole story.
....is actually quite good. It's a universal application, and it doesn't spin up the rainbow beach ball too often. It doesn't seem particularly demanding of memory. You can adjust the fonts, both using a menu from within Notes itself or by editing the now plain text INI file. (You had to download a separate IBM utility to edit the Notes 6.x for Mac proprietary binary INI file previously.)
The only feature gaps that I've found are the lack of Java support (not a problem for me) and a paucity of built-in file attachment viewers. If your Notes server is set up to handle attachment viewing on behalf of the client then it's not a problem. Of course opening the file, using whatever preferred application you wish, is still an option.
DB2 for z/OS pulls off this feat, when you configure it in a DB2 data sharing group (i.e. in a Parallel Sysplex). Yes, you can perform complete N+1 upgrades of the database server code, one member of the group at a time, while maintaining continuous business service.
Yes, it's an amazing piece of engineering. And it works.
First of all, that figure is $12,500 per year. Which isn't a lot of money.
OK, let's look at staffing first. Let's assume IBM got a very good ratio of server administrators to servers and could run those 4,000 servers with 100 administrators (40 to 1 ratio, which is very high). Let's assume IBM can get that number down to 30, i.e. one person per new mainframe server. Assuming a fully burdened staff expense of $100,000 per worker (salary, benefits, office space, telephone, ID badges, whatever), that's $1,750 of the savings right there. We have $10,750 to go.
Now let's look at electricity. Let's assume (conservatively) that each old server requires 300 watts. That's 0.3*8760 = 2628 Kwh. At $0.10 per Kwh that's $263 per year. Triple that to include the cooling costs. That's $3.1M in annual electricity for 4,000 servers. IBM says they can reduce that by 80%. That's another $631 in savings. We now have $10,119 to go.
Next up: network taps. You don't need most of that redundant Cisco gear, cabling, etc. any more. Figure $800 per year (full cost) for that stuff per server. We now have $9,319 to go.
Data center space costs money. (Osaka real estate is not cheap.) A System z9 EC requires about 58 square feet of space, including clearance. Let's double that for good measure. Let's assume IBM does a really good job and gets 20 old servers into the space one of these new mainframes requires. So 200 "footprints" are reduced to 30. That saves 19,720 square feet. Figure a couple hundred bucks a square foot for raised floor data center space (conservative again), and you take another $1,000 off. $8,319 to go.
If these servers are running Oracle Database, the annual software subscription and support is about $8,000 per CPU. Let's assume uni-processor CPUs (very conservative assumption). That means reducing 4,000 CPUs down to about 900 CPUs (assuming 30 processors in each of the new mainframes). That results in a savings of $6,200, and we now have $2,119 to go. Moreover, these 3,100 Oracle licenses can now be redeployed onto other servers somewhere else at IBM. (It's 3,100 fewer Oracle licenses that IBM has to buy.) Also, undoubtedly there is other software, like monitoring software. Let's make the assumption IBM gets this free.
Now I get to the stuff which is harder to estimate without more information but is no less real. Disaster recovery is comparatively cheaper on mainframes. (Mainframes have something called CBU -- Capacity Backup.) And it works better, too. Service Level Agreement penalties to IBM's customers are likely reduced with the new machines. IBM gets some money back by recycling the old machines (residual value). The technology refreshes (hardware replacements) are much cheaper on mainframes, both in terms of physical equipment and installation costs. (In a 5 year business case you'd have to include hardware refreshes.) They're probably also doing some disk and tape consolidation, and they're going to have SAN savings (fewer storage connections and switches). Disk space might go down at least slightly. There might be hardware maintenance expense (warranties), but perhaps IBM gets that for "free" on all its servers. All of these other factors could easily get past the remaining $2,119 figure.
Anyway, this is a very back-of-the-envelope analysis, and there are some transition costs to include. (Although there are also transition costs when simply replacing hardware during a normal refresh.) But yes, it appears IBM can easily make the case for the financial savings here. It's a pretty easy case, in fact.
What's really interesting is that IBM competes against other companies in the data center hosting business. If they can trim $250M off their data center expenses, some of that will go into reducing their bid price. And that means they'll be much more formidable as a competitor in this market and make more profits. This is a secondary effect, but it could be very big. Another secondary effect is that data center operators (outsourcers, private companies, and governments) will see these cost savings and want them also, buying more IBM mainframes. IBM wins again. Really smart move on IBM's part doing this 4000 to 30 consolidation, I'd say.
Actually, on a System z9 EC (Enterprise Class), a single CPU chip failure is not a "Call Home" repair event. Only the second CPU chip failure would result in an automatic call, while your business keeps running of course. (There are a minimum of two spares in each machine.) The average time to first failure for a particular machine is somewhere in the many decades range.
OK, just for fun (because it never actually happens in the real world), what happens with a triple failure? If you happen to have a "fully configured" mainframe -- all processors turned on -- then.... your business still keeps running. Yes, the system might lose some processing capacity, but it keeps running. The higher priority stuff (from a business view) takes precedence automatically, and life goes on. This is all on a single machine still.
If you've got an S18, S28, S38, or S54 model, then, at your business's convenience, the faulty hardware can be replaced. (You might do this at night, for example.) The repair technician tells the mainframe to "evacuate" memory on a portion of the machine while the OS and applications keep chugging along, possibly with reduced capacity, often not. (Depends on what configuration you choose.) When the evacuation is complete, the technician can pull a processor/memory group (called a "book"), insert the new one, bring the new one online, and... everything still keeps running. Again, this is all on a single machine -- no clusters required for any of this.
Yes, System z mainframes are engineered for 99.999+% availability. But it's important to define availability here very precisely. IBM defines this as business service: what the user gets. Therefore, planned downtime is just as bad as unplanned downtime. A lot of IT people get confused by this point, but it's very important. "Excuse me while I shut down credit card approvals for a couple hours to upgrade the database" and you'll be escorted out of the building promptly.
Now, there's nothing in the original story that talks about how the highest levels of availability are important to this particular collection of applications that IBM is consolidating. Indeed, though Linux is mighty fine on the mainframe -- the most highly available Linux -- it's no z/OS, the flagship mainframe operating system. Still, one would hope IBM would include in its cost calculations the cost of downtime. It's likely user interruptions will decrease as a result of moving this work to the mainframe. That means the users will be more productive, and there's a financial benefit to that. How big or how small depends on the applications and the users.
There are a lot of errors in your comments, unfortunately. Of course you can run Red Hat and SuSE concurrently in a single LPAR under z/VM, and multiple versions thereof. This has always been true, ever since Linux began running on mainframes many years ago. You might want to have more than one LPAR to run more than one version of (first level) z/VM, but you don't need many. Two or three for z/VM and Linux is typical and just fine. And it's not as if LPARs are in short supply on mainframes: up to 60 are available on a single machine (30 on the smaller model), so "spending" 1 to 3 is no big deal.
Re: Investing in new mainframes, come on, get real. It's so easy to find market data because companies like Gartner and IDC publish it, and IBM just announced its 8th straight quarter of mainframe hardware growth, something that hasn't happened since before Y2K. It's impossible to do that with "a few showboat customers."
And no, you simply cannot approach the level of virtualization these machines offer on any other system, at least for typical business computing, and still offer reliable service to users. In fact, in IBM's case many of the software licenses are presumably "free," and they still found big cost savings by taking 4,000 machines down to 30. For the rest of the world the mathematics in such situations are even more compelling.
....But it's not supported and never was. IBM declared support for z/OS 1.(4?) and above on the z9 models. OS/390 itself is out of support as well. In strict technical terms, it would have the best chance of running inside VM on a z9, possibly double virtualised (OS/390 inside an older version of VM inside the newest z/VM). (Yes, mainframes can n-virtualise, and there's negligible performance penalty for doing that.) Unsupported again, but technically it'd work.
Let's assume gdb actually works and delivers the information you want.
Were you running it at the time? In production? All the time? Did it catch the fault? And did the hardware/driver/OS stay up in order to catch it? Was there hardware key-protected memory so that you know exactly what put what into that memory location? Did a cosmic ray bounce an electron inside the microprocessor?
Say what you will about the mainframe, the original poster was right. Debugging, tracing, fault analysis, and related tasks are like nothing else around. These capabilities are embedded deep into the hardware levels, and you cannot escape them. The philosophy is that if you're going to run it you damn well better be able to troubleshoot it at all times. And I'm serious about that cosmic ray reference. The dirty little secret is that microprocessors, as they get faster and hotter and more dense, are getting less reliable and generate less consistent computations. Mainframe processors effectively run everything twice, compare, and reconcile automatically, and the layers above (OS, middleware, applications) have absolutely no clue it's happening. The mainframe never lets so much as a fault add or bit shift surface to the OS: it'll dynamically swap in a spare under the covers until the redundant circuitry fully agrees.
All modern mainframes (since at least 2000) can run the latest Java(TM): it's a standard, no extra charge feature in z/OS (the flagship operating system among the 5 available, Linux being another). So if you're running Java on the mainframe accessing DB2 on the mainframe you're going to see a much different number. (That's typically using something called JZOS, by the way, for Java batch programs. JZOS is free with z/OS, too.)
If it's J2EE (e.g. WebSphere Application Server for z/OS) then you'd typically be using the Type 2 JDBC driver to access DB2. As least as far as Java goes, that database access path is fast and tight.
In the modern mainframe (since 2004), your Java can run on a special Java accelerator called a zAAP. You turn on the zAAP on your z9 (latest model) or z890/z990 (prior generation model) and you pay zero extra (that'd be $0) for software but suddenly about 75% (give or take) of your WebSphere processing shifts over to the zAAP(s). The capacity you had been using on the main processors is now free for other work, or you can cap it and pay less for software, or buy less of it in the first place, or some combination.
So, yes, COBOL code accessing DB2 locally is fast, and Java code accessing DB2 over the network is slower. But Java code accessing DB2 locally is at least much closer to COBOL. You have choices.
Let me get this straight. You're spending $50M (and counting) -- $6.25M per year -- to create IT applications and infrastructure of some kind -- that's just to create it, not to run it or use it -- to avoid spending $3M per year? And you've wasted 8 years during which you could have actually delivered new business function -- code, middleware, whatever -- on your mainframe? And (probably) you're paying IBM's prices from 8 years ago, which have declined every year (at constant capacity) if you simply keep relatively current? And we haven't even begun to discuss whether any new infrastructure will actually work, consume more or less electricity, take up more or less data center space, recover more or less quickly in a disaster, stay up-and-running (with performance) more or less....
So when does the CIO get fired, and when will the bloody lot of you get outsourced for these stupid antics? It sounds like you've got an IT department that's killing your business. It also sounds like IBM and Fujitsu are happy to take money from fools.
So why not upgrade the OS to a supported version? If your hardware is recently purchased/new, it probably cannot even run too many releases of unsupported operating systems anyway. And all the latest IBM operating system versions run on all the mainframe models stretching back to the end of 2000 (three generations). IBM always has a lot of overlap.
If you have z/OS V1.x, the upgrade to 1.8 or (soon) 1.9 is free. If you have OS/390 still -- hard to imagine on recently purchased/new hardware since it doesn't run on the z9 anyway -- the upgrade to z/OS is probably better than free (i.e. you typically save money), and you usually save money on the other software that runs on z/OS. (z/OS introduced subcapacity licensing.) And you have a full year when you can run both on the same system for no additional charge to get the migration done.
An OS upgrade is extremely unlikely to break any applications. There's 40+ year old code that's still running, right along with 64-bit Java code written an hour ago. Your 17 to 18 year old code should be perfectly happy on the new OS. And here's a radical notion: you can actually change your code if you wish. You know, add features and functions. You're allowed to do that.:-) You run code as long as it has value on the mainframe, for as long as you wish, without the vendor saying, "Sorry, that code must die this year." Just keep your OS and middleware on at least relatively recent releases, that's all -- it's backward compatible. Change your code and add code as you want, when you want.
Google isn't stupid; if that sort of improvement were available globally they'd be using it.
Google isn't stupid, which is why they aren't running the world's most power-efficient data centers. Quite the contrary, actually. My educated guess is that Lexis-Nexis has a per-search energy use profile vastly lower than Google's. (No, I don't work for Lexis-Nexis nor have any inside information. I've just reviewed public information about them.)
Google has tons of money, so they don't particularly care about energy use right now. But that lack of caring will come to and end one way or another.
Congratulations on that (one-time?) 35% reduction. Seriously, that's a good job. Now, what's your annual server growth rate? How about growth rate in power and cooling? Are the CPU wattages declining? No?
"Joey, ever hear of a mainframe?"
There has been literally decades of research, and research is ongoing. There's no single good answer. High compression piston aircraft engines may be able to run on fuels with other additives, but all the reformulations discovered so far are much more toxic than the current 100LL formulation.
Some of the technical solutions include shipping 100LL without the lead (which mid-compression engines can probably run OK), electronic ignition systems, and diesel (jet fuel) retrofit with new engines. Whole new, small aircraft, particularly from Diamond Aircraft, run on Jet-A. The lead additive (TEL) is getting more expensive, so price is encouraging some movement in this direction anyway, particularly outside the U.S.
It's important to keep some perspective here, though. The amount of lead released into the atmosphere by piston aircraft engines is incredibly miniscule, and it's not released in the ways automobiles did (i.e. near the ground, in lung-concentrated ways). There are about 5,000 public airports in the U.S., and the vast majority of those have very limited numbers of aircraft operating on the ground for very brief periods of time. So unless you live on a taxiway at a busy small aircraft airport, and breathe deeply for some years, you're OK.
There are many, many places where environmental protection money would be more wisely spent. The simple act of burning coal, for example, is incredibly, vastly more dangerous than anything the entire piston aircraft engine fleet could do. That said, it would probably make sense for the government to give the engine industry (mainly Lycoming and Continental) a bit of a nudge, telling them to find any solution they wish to stop producing new aircraft engines that run only on leaded fuels by a date certain (say, 10 years out). In all probability they can recertify with a combination of electronic ignition and the same 100LL formulation but without TEL, and they can do that relatively inexpensively. If the feds made every aircraft owner who replaced their engines eligible for fuel tax rebates for a period of, say, 5 years from date of installation, that'd probably get the job done to get the fleet converted. But nobody is in a rush to do this because nobody at the EPA sees a public health problem here.
There are many, many COBOL books available on Amazon.com, including some very recent ones. I suggest reading through the customer reviews and picking up a couple or three to get started.
There are some universities starting to provide distance learning in this area, by the way. Marist College comes to mind as one example.
I don't think this is a really strong argument. Theoretically you could buy a long term futures contract for your energy needs, just like many airlines do for jet fuel. If the problem is energy price stability then the financial markets can handle that -- especially if you're willing to spend a large amount of capital on a sophisticated home energy system.
Most home heating oil companies, for example, will sell you a one year futures contract with a guaranteed price for next winter. In principle these contracts could be longer term if someone wanted them.
...how does the copyright holder distinguish between the purchaser engaging in illegal distribution vs being the victim of theft?
They don't. But the person who possesses someone else's watermarked media files has some explaining to do. That explaining could take the form of a simple purchase receipt. You can legally resell copyrighted works, even watermarked ones, just as you can sell a portrait painting -- as long as you transfer or destroy all your copies.
The signed, portrait painting is a good analogy. It's pretty easy to figure out whether someone has proper title to the Mona Lisa. The original purchaser and any potential subsequent owner both have ample incentives to play by the rules.
Slashdot Mirror
As a general rule, if you're building a business computer and want to save as much as electricity as possible, the most highly virtualized (and virtualizable) platform wins. So attributes like massive caches and screaming I/O help enormously. (I think there was a Stanford study recently that figured this out.) Thus it's no surprise a modern mainframe is more energy efficient than anything else.
But in the Computerworld article referenced in the original story, IBM says the carbon program will also be available for its System p servers at some point in the future. My prediction is that you'll typically get fewer certificates if you move to System p versus System z, but it's likely businesses will do some of both depending on what sort of applications they're rehosting. There are some types of applications that will do better on System p, and there is some software that runs on AIX that doesn't run on z/OS or Linux.
Regarding SPARC it's impossible to say since Sun hasn't entered into any carbon credit auditing system yet. The IBM-Neuwing program is a first. However, my prediction is that you'll get even fewer certificates if you consolidate to SPARC. I say that simply because I assume IBM is acting in its own self-interest, and I'm sure they think the energy efficiency fight is one they can win against other vendors. In this case self-interest and environmentalism coincide. For any of these platforms, though, businesses will figure out whether the certificates favor certain platforms over others, and they'll do that application by application (or application function by application function). And many other factors will go into the decision as well, although most of those factors pull in the same direction as energy efficiency, such as software charges. One could even imagine that before long server vendors lagging in the energy efficiency department will start bundling carbon certificates with their servers in order to compete. Thus IBM adopting this program is a smart way to respond to an untapped market need and to raise the effective price of competing servers compared to IBM's. Very smart move.
By the way, the world has totally flipped on its head, and it would be extremely misleading to say an IBM mainframe is "proprietary" and X86 (for example) isn't. What does proprietary mean? You can run pure 100% GPL Linux on an IBM mainframe -- Debian, Slackware, CentOS, etc. -- and you don't even need a closed source driver as you usually need for X86 servers. IBM publishes extreme instruction-level detail in a free book called Principles of Operation, and it's so detailed and thorough that the open source community created an implementation of the instruction set called Hercules that actually works compared to still imperfect efforts like Bochs and QEMU. (Although IBM may assert patent claims on its processor architecture.) One company is porting OpenSolaris to System z, and they didn't even have to ring up IBM. In comparison, Intel and AMD also may assert patent claims, and AMD is suing Intel for alleged monopolistic behavior. Neither Intel nor AMD publish PoO-type documents (to that level of detail). Then there's Microsoft Windows, and it's hard to think of any more proprietary OS than that.
Also, IBM changed the way it charges for z/OS software about 7 years ago. Now almost everything is charged by the amount you actually use, something IBM calls Variable Workload License Charge (VWLC). If you run a little bit of DB2 in one LPAR (partition) but a lot of IMS in another, then you pay a little for DB2 and more for IMS. You also control exactly what you consume using something called softcaps, and you can set those either per-LPAR or for a group of LPARs. One interesting little twist to mainframe subcapacity licensing is that, if you need a little bit of WebSphere (and a lot of other IBM products), the lowest entry price (smallest license you can order) is for z/OS. You can order as little as 1 "Value Uni
There's very little information to go by, but chances are if you try to rationalize this particular IT project on the basis of generally accepted accounting principles or business economics you'll quickly go crazy. And actually I'd give you more than 400 years. First of all, you're assuming the best alternative is zero. Of course it isn't; not even close. Then, hardware costs have been declining, both in real and nominal terms, and mainframes are no different in that respect. There's also net present value: you could put $800 million into U.S. Treasuries, draw off $2M per year (never mind every two), and your principle would still increase. In other words, $800 million would buy you an infinite supply of IBM mainframes, forever.
Moreover, there's no reason why the GPS operators would even need their own, separate, siloed infrastructure. They could simply move to any pair (for high availability) of mainframe data centers anywhere within the military establishment, run on a couple LPARs, and get guaranteed, highest service levels. With zero additional operations staff in those data centers. That's what modern mainframes do. (Two is a large and sufficient number of machines for most organizations.) Running your own, separate, siloed, application-specific server infrastructure is extremely expensive and oh-so-1980s.
What's even more ironic is that Sun appears to be winding down its hardware business and just announced a big partnership with IBM, including probable support for Solaris on IBM System z mainframes. Computer processor R&D is expensive, and, much like Boeing and Airbus for airliners, there are only a small handful of companies that look like they'll be able to sustain this gargantuan effort. IBM is certainly one of them.
As a taxpayer I'm angry but unfortunately not surprised.
I didn't write the Wall Street Journal article, but I would assume the 135 million figure is significant because it refers to a large installed base that will get Open Document Format support. The fact Lotus Symphony is now available as a free download is wonderful and will add to ODF's marketshare, but it isn't the whole story.
....is actually quite good. It's a universal application, and it doesn't spin up the rainbow beach ball too often. It doesn't seem particularly demanding of memory. You can adjust the fonts, both using a menu from within Notes itself or by editing the now plain text INI file. (You had to download a separate IBM utility to edit the Notes 6.x for Mac proprietary binary INI file previously.)
The only feature gaps that I've found are the lack of Java support (not a problem for me) and a paucity of built-in file attachment viewers. If your Notes server is set up to handle attachment viewing on behalf of the client then it's not a problem. Of course opening the file, using whatever preferred application you wish, is still an option.
Here is the list of operating systems that will run Microsoft Visual Studio 2005:
In addition to the list of operating systems above, here is the list of operating systems that will also run Eclipse:
DB2 for z/OS pulls off this feat, when you configure it in a DB2 data sharing group (i.e. in a Parallel Sysplex). Yes, you can perform complete N+1 upgrades of the database server code, one member of the group at a time, while maintaining continuous business service.
Yes, it's an amazing piece of engineering. And it works.
First of all, that figure is $12,500 per year. Which isn't a lot of money.
OK, let's look at staffing first. Let's assume IBM got a very good ratio of server administrators to servers and could run those 4,000 servers with 100 administrators (40 to 1 ratio, which is very high). Let's assume IBM can get that number down to 30, i.e. one person per new mainframe server. Assuming a fully burdened staff expense of $100,000 per worker (salary, benefits, office space, telephone, ID badges, whatever), that's $1,750 of the savings right there. We have $10,750 to go.
Now let's look at electricity. Let's assume (conservatively) that each old server requires 300 watts. That's 0.3*8760 = 2628 Kwh. At $0.10 per Kwh that's $263 per year. Triple that to include the cooling costs. That's $3.1M in annual electricity for 4,000 servers. IBM says they can reduce that by 80%. That's another $631 in savings. We now have $10,119 to go.
Next up: network taps. You don't need most of that redundant Cisco gear, cabling, etc. any more. Figure $800 per year (full cost) for that stuff per server. We now have $9,319 to go.
Data center space costs money. (Osaka real estate is not cheap.) A System z9 EC requires about 58 square feet of space, including clearance. Let's double that for good measure. Let's assume IBM does a really good job and gets 20 old servers into the space one of these new mainframes requires. So 200 "footprints" are reduced to 30. That saves 19,720 square feet. Figure a couple hundred bucks a square foot for raised floor data center space (conservative again), and you take another $1,000 off. $8,319 to go.
If these servers are running Oracle Database, the annual software subscription and support is about $8,000 per CPU. Let's assume uni-processor CPUs (very conservative assumption). That means reducing 4,000 CPUs down to about 900 CPUs (assuming 30 processors in each of the new mainframes). That results in a savings of $6,200, and we now have $2,119 to go. Moreover, these 3,100 Oracle licenses can now be redeployed onto other servers somewhere else at IBM. (It's 3,100 fewer Oracle licenses that IBM has to buy.) Also, undoubtedly there is other software, like monitoring software. Let's make the assumption IBM gets this free.
Now I get to the stuff which is harder to estimate without more information but is no less real. Disaster recovery is comparatively cheaper on mainframes. (Mainframes have something called CBU -- Capacity Backup.) And it works better, too. Service Level Agreement penalties to IBM's customers are likely reduced with the new machines. IBM gets some money back by recycling the old machines (residual value). The technology refreshes (hardware replacements) are much cheaper on mainframes, both in terms of physical equipment and installation costs. (In a 5 year business case you'd have to include hardware refreshes.) They're probably also doing some disk and tape consolidation, and they're going to have SAN savings (fewer storage connections and switches). Disk space might go down at least slightly. There might be hardware maintenance expense (warranties), but perhaps IBM gets that for "free" on all its servers. All of these other factors could easily get past the remaining $2,119 figure.
Anyway, this is a very back-of-the-envelope analysis, and there are some transition costs to include. (Although there are also transition costs when simply replacing hardware during a normal refresh.) But yes, it appears IBM can easily make the case for the financial savings here. It's a pretty easy case, in fact.
What's really interesting is that IBM competes against other companies in the data center hosting business. If they can trim $250M off their data center expenses, some of that will go into reducing their bid price. And that means they'll be much more formidable as a competitor in this market and make more profits. This is a secondary effect, but it could be very big. Another secondary effect is that data center operators (outsourcers, private companies, and governments) will see these cost savings and want them also, buying more IBM mainframes. IBM wins again. Really smart move on IBM's part doing this 4000 to 30 consolidation, I'd say.
Oracle Database is available for both Linux on z and z/OS....
But it'd be extremely unlikely you'd want to switch from DB2 for z/OS. Even Larry Ellison concedes that.
Actually, on a System z9 EC (Enterprise Class), a single CPU chip failure is not a "Call Home" repair event. Only the second CPU chip failure would result in an automatic call, while your business keeps running of course. (There are a minimum of two spares in each machine.) The average time to first failure for a particular machine is somewhere in the many decades range.
OK, just for fun (because it never actually happens in the real world), what happens with a triple failure? If you happen to have a "fully configured" mainframe -- all processors turned on -- then.... your business still keeps running. Yes, the system might lose some processing capacity, but it keeps running. The higher priority stuff (from a business view) takes precedence automatically, and life goes on. This is all on a single machine still.
If you've got an S18, S28, S38, or S54 model, then, at your business's convenience, the faulty hardware can be replaced. (You might do this at night, for example.) The repair technician tells the mainframe to "evacuate" memory on a portion of the machine while the OS and applications keep chugging along, possibly with reduced capacity, often not. (Depends on what configuration you choose.) When the evacuation is complete, the technician can pull a processor/memory group (called a "book"), insert the new one, bring the new one online, and... everything still keeps running. Again, this is all on a single machine -- no clusters required for any of this.
Yes, System z mainframes are engineered for 99.999+% availability. But it's important to define availability here very precisely. IBM defines this as business service: what the user gets. Therefore, planned downtime is just as bad as unplanned downtime. A lot of IT people get confused by this point, but it's very important. "Excuse me while I shut down credit card approvals for a couple hours to upgrade the database" and you'll be escorted out of the building promptly.
Now, there's nothing in the original story that talks about how the highest levels of availability are important to this particular collection of applications that IBM is consolidating. Indeed, though Linux is mighty fine on the mainframe -- the most highly available Linux -- it's no z/OS, the flagship mainframe operating system. Still, one would hope IBM would include in its cost calculations the cost of downtime. It's likely user interruptions will decrease as a result of moving this work to the mainframe. That means the users will be more productive, and there's a financial benefit to that. How big or how small depends on the applications and the users.
There are a lot of errors in your comments, unfortunately. Of course you can run Red Hat and SuSE concurrently in a single LPAR under z/VM, and multiple versions thereof. This has always been true, ever since Linux began running on mainframes many years ago. You might want to have more than one LPAR to run more than one version of (first level) z/VM, but you don't need many. Two or three for z/VM and Linux is typical and just fine. And it's not as if LPARs are in short supply on mainframes: up to 60 are available on a single machine (30 on the smaller model), so "spending" 1 to 3 is no big deal.
Re: Investing in new mainframes, come on, get real. It's so easy to find market data because companies like Gartner and IDC publish it, and IBM just announced its 8th straight quarter of mainframe hardware growth, something that hasn't happened since before Y2K. It's impossible to do that with "a few showboat customers."
And no, you simply cannot approach the level of virtualization these machines offer on any other system, at least for typical business computing, and still offer reliable service to users. In fact, in IBM's case many of the software licenses are presumably "free," and they still found big cost savings by taking 4,000 machines down to 30. For the rest of the world the mathematics in such situations are even more compelling.
....But it's not supported and never was. IBM declared support for z/OS 1.(4?) and above on the z9 models. OS/390 itself is out of support as well. In strict technical terms, it would have the best chance of running inside VM on a z9, possibly double virtualised (OS/390 inside an older version of VM inside the newest z/VM). (Yes, mainframes can n-virtualise, and there's negligible performance penalty for doing that.) Unsupported again, but technically it'd work.
Let's assume gdb actually works and delivers the information you want.
Were you running it at the time? In production? All the time? Did it catch the fault? And did the hardware/driver/OS stay up in order to catch it? Was there hardware key-protected memory so that you know exactly what put what into that memory location? Did a cosmic ray bounce an electron inside the microprocessor?
Say what you will about the mainframe, the original poster was right. Debugging, tracing, fault analysis, and related tasks are like nothing else around. These capabilities are embedded deep into the hardware levels, and you cannot escape them. The philosophy is that if you're going to run it you damn well better be able to troubleshoot it at all times. And I'm serious about that cosmic ray reference. The dirty little secret is that microprocessors, as they get faster and hotter and more dense, are getting less reliable and generate less consistent computations. Mainframe processors effectively run everything twice, compare, and reconcile automatically, and the layers above (OS, middleware, applications) have absolutely no clue it's happening. The mainframe never lets so much as a fault add or bit shift surface to the OS: it'll dynamically swap in a spare under the covers until the redundant circuitry fully agrees.
All modern mainframes (since at least 2000) can run the latest Java(TM): it's a standard, no extra charge feature in z/OS (the flagship operating system among the 5 available, Linux being another). So if you're running Java on the mainframe accessing DB2 on the mainframe you're going to see a much different number. (That's typically using something called JZOS, by the way, for Java batch programs. JZOS is free with z/OS, too.)
If it's J2EE (e.g. WebSphere Application Server for z/OS) then you'd typically be using the Type 2 JDBC driver to access DB2. As least as far as Java goes, that database access path is fast and tight.
In the modern mainframe (since 2004), your Java can run on a special Java accelerator called a zAAP. You turn on the zAAP on your z9 (latest model) or z890/z990 (prior generation model) and you pay zero extra (that'd be $0) for software but suddenly about 75% (give or take) of your WebSphere processing shifts over to the zAAP(s). The capacity you had been using on the main processors is now free for other work, or you can cap it and pay less for software, or buy less of it in the first place, or some combination.
So, yes, COBOL code accessing DB2 locally is fast, and Java code accessing DB2 over the network is slower. But Java code accessing DB2 locally is at least much closer to COBOL. You have choices.
Let me get this straight. You're spending $50M (and counting) -- $6.25M per year -- to create IT applications and infrastructure of some kind -- that's just to create it, not to run it or use it -- to avoid spending $3M per year? And you've wasted 8 years during which you could have actually delivered new business function -- code, middleware, whatever -- on your mainframe? And (probably) you're paying IBM's prices from 8 years ago, which have declined every year (at constant capacity) if you simply keep relatively current? And we haven't even begun to discuss whether any new infrastructure will actually work, consume more or less electricity, take up more or less data center space, recover more or less quickly in a disaster, stay up-and-running (with performance) more or less....
So when does the CIO get fired, and when will the bloody lot of you get outsourced for these stupid antics? It sounds like you've got an IT department that's killing your business. It also sounds like IBM and Fujitsu are happy to take money from fools.
That's what it sounds like.
So why not upgrade the OS to a supported version? If your hardware is recently purchased/new, it probably cannot even run too many releases of unsupported operating systems anyway. And all the latest IBM operating system versions run on all the mainframe models stretching back to the end of 2000 (three generations). IBM always has a lot of overlap.
If you have z/OS V1.x, the upgrade to 1.8 or (soon) 1.9 is free. If you have OS/390 still -- hard to imagine on recently purchased/new hardware since it doesn't run on the z9 anyway -- the upgrade to z/OS is probably better than free (i.e. you typically save money), and you usually save money on the other software that runs on z/OS. (z/OS introduced subcapacity licensing.) And you have a full year when you can run both on the same system for no additional charge to get the migration done.
An OS upgrade is extremely unlikely to break any applications. There's 40+ year old code that's still running, right along with 64-bit Java code written an hour ago. Your 17 to 18 year old code should be perfectly happy on the new OS. And here's a radical notion: you can actually change your code if you wish. You know, add features and functions. You're allowed to do that. :-) You run code as long as it has value on the mainframe, for as long as you wish, without the vendor saying, "Sorry, that code must die this year." Just keep your OS and middleware on at least relatively recent releases, that's all -- it's backward compatible. Change your code and add code as you want, when you want.
Google isn't stupid, which is why they aren't running the world's most power-efficient data centers. Quite the contrary, actually. My educated guess is that Lexis-Nexis has a per-search energy use profile vastly lower than Google's. (No, I don't work for Lexis-Nexis nor have any inside information. I've just reviewed public information about them.)
Google has tons of money, so they don't particularly care about energy use right now. But that lack of caring will come to and end one way or another.
Congratulations on that (one-time?) 35% reduction. Seriously, that's a good job. Now, what's your annual server growth rate? How about growth rate in power and cooling? Are the CPU wattages declining? No? "Joey, ever hear of a mainframe?"
Fiber optics are still constrained by the speed of light. Yes, that matters. Often a lot.
So Dell PC servers now have old fashioned, pipes-in-the-data-centre liquid cooling, while IBM mainframes do not.
We have come full circle, haven't we?
There has been literally decades of research, and research is ongoing. There's no single good answer. High compression piston aircraft engines may be able to run on fuels with other additives, but all the reformulations discovered so far are much more toxic than the current 100LL formulation.
Some of the technical solutions include shipping 100LL without the lead (which mid-compression engines can probably run OK), electronic ignition systems, and diesel (jet fuel) retrofit with new engines. Whole new, small aircraft, particularly from Diamond Aircraft, run on Jet-A. The lead additive (TEL) is getting more expensive, so price is encouraging some movement in this direction anyway, particularly outside the U.S.
It's important to keep some perspective here, though. The amount of lead released into the atmosphere by piston aircraft engines is incredibly miniscule, and it's not released in the ways automobiles did (i.e. near the ground, in lung-concentrated ways). There are about 5,000 public airports in the U.S., and the vast majority of those have very limited numbers of aircraft operating on the ground for very brief periods of time. So unless you live on a taxiway at a busy small aircraft airport, and breathe deeply for some years, you're OK.
There are many, many places where environmental protection money would be more wisely spent. The simple act of burning coal, for example, is incredibly, vastly more dangerous than anything the entire piston aircraft engine fleet could do. That said, it would probably make sense for the government to give the engine industry (mainly Lycoming and Continental) a bit of a nudge, telling them to find any solution they wish to stop producing new aircraft engines that run only on leaded fuels by a date certain (say, 10 years out). In all probability they can recertify with a combination of electronic ignition and the same 100LL formulation but without TEL, and they can do that relatively inexpensively. If the feds made every aircraft owner who replaced their engines eligible for fuel tax rebates for a period of, say, 5 years from date of installation, that'd probably get the job done to get the fleet converted. But nobody is in a rush to do this because nobody at the EPA sees a public health problem here.
There are many, many COBOL books available on Amazon.com, including some very recent ones. I suggest reading through the customer reviews and picking up a couple or three to get started. There are some universities starting to provide distance learning in this area, by the way. Marist College comes to mind as one example.
Can banks ever truly replace mattresses?
I don't think this is a really strong argument. Theoretically you could buy a long term futures contract for your energy needs, just like many airlines do for jet fuel. If the problem is energy price stability then the financial markets can handle that -- especially if you're willing to spend a large amount of capital on a sophisticated home energy system.
Most home heating oil companies, for example, will sell you a one year futures contract with a guaranteed price for next winter. In principle these contracts could be longer term if someone wanted them.
They don't. But the person who possesses someone else's watermarked media files has some explaining to do. That explaining could take the form of a simple purchase receipt. You can legally resell copyrighted works, even watermarked ones, just as you can sell a portrait painting -- as long as you transfer or destroy all your copies.
The signed, portrait painting is a good analogy. It's pretty easy to figure out whether someone has proper title to the Mona Lisa. The original purchaser and any potential subsequent owner both have ample incentives to play by the rules.