....I am making an argument against the idea that you can have "four nines" availability out of a single server.
And yet, in the real world, that's what many single frame mainframe shops manage. Probably because a single frame isn't at all a single frame internally. The only singleton in the equation is the cabinet itself, and (but only if the operator wants) any particular operating system/middleware/application instances that the operator chooses to run that way (which would typically be development instances, not production).
No, they're doing that because somebody had a memory leak 30+ years ago (back when those might have mattered from a system stability point of view), told the operators to reboot (IPL) every week, and the operators have never updated their procedure manuals. I'm not joking. If you tap an operator on the shoulder and say, "Stop rebooting now," problem solved. (Or, for the ultra-conservatives, switch to once every month, then once every year, then not at all.)
Or, in the alternative, somebody decided 30+ years ago that they'd tell the users the system would be unavailable each weekend for a couple hours for "system maintenance" (back when that might have made sense), then, many years ago (and particularly with Parallel Sysplex), when the operators no longer needed the "maintenance window," nobody bothered to tell the users the good news and make it official. Again, I'm not joking. I was at a meeting at a Fortune 100 company where the conversation went something like this.... Web service team: "We need 24 hour Internet access, but you're down every weekend for 4 hours. We want to move off." Mainframe operator: "You need 24 hours? OK, you have 24 hours." Web service team: "But you didn't do anything." Mainframe operator: "We stopped IPL'ing that LPAR at least 10 years ago, and I'm now declaring you have a 24 hour Service Level Agreement. I'll update our SLA just after our meeting. Need anything else?" Web service team: "Uh, that'll do."
If you want 99.999+ percent business service uptime, factoring in both planned and unplanned outages, and even disaster recovery, just ask for it. (Or ask for some other level if that's too much.) It's no myth, it's the owner's choice, consistent with their budget and "reasonable" (but not superhuman) operations staff.
Good question. There are two physical sizes available: a System z10 BC and System z10 EC. The BC is roughly the same size as a single conventional rack of pizza box servers, and the EC is a double wide (about two racks). In refrigerator terms that's probably closer to the JennAir (or two for the EC) but well shy of the cow locker. Here's a picture of the EC shown to scale with two IBM executives: http://japan.zdnet.com/news/hardware/story/0,2000056184,20368219,00.htm?tag=z.keyword.st
Emulating a $500 PC Server on a $500,000 mainframe... yeah, that sounds real cost-effective!
Then why aren't you driving a Yugo (I presume)? It has a lower price, doesn't it?:-)
If you run this simultaneously in 1000 virtual machines, do you need 1000 Windows licenses?
That's up to Microsoft. I can't wait to see Microsoft's mainframe price list.:-) But if Microsoft wants to be competitive with Oracle and IBM, to pick a couple software vendor examples, then for server software at least (e.g. Microsoft SQL Server) they'd license by core. And yes, a core is a core is a core. How the price of that Yugo looking?:-)
Most of that thousands to one virtualization is based on the same idea that is driving commodity virtualization ala ESX, most servers spend most of their time idle.
That's part of it, but it's not the only part. Otherwise we'd see thousands of virtual machines on a single ESX core, and that's just not what's happening. (The virtualization ratios per core are pretty small. Still useful, though.) Virtualization also places heavy stresses on cache, memory, and I/O performance. IBM System z10 machines are no slouches on CPU -- they have the highest clock speed (4.4 GHz) CPUs with more than 2 cores (they're quad) on the market -- but they balance that with kick-ass cache, main memory, and I/O performance. They also have hypervisors (PR/SM and z/VM) which are extremely refined and uniquely co-evolved with the hardware over decades. Add that all together and you begin to understand why the virtualization ratios get much higher in real world use.
Yes, the usual myriad of analysts (Gartner, Forrester, etc.) have looked at the issue, and, to net it out, they find both IBM System z virtualization and VMware useful and cost-effective. ("Both" is often the right answer, because some workloads do better on one or the other, and most businesses have a mix of workload types.) One bright dividing line has been that VMware obviously can virtualize Microsoft Windows directly (such as Microsoft Exchange and Microsoft SQL Server), while System z could not. But System z has been adding whole operating systems to its virtualization repertoire, including OpenSolaris for System z and now (with Mantissa) Microsoft Windows, so it's moving into new ground.
Cost isn't the only issue of course. Qualities of Service (QoS) are also important. It's undisputed that IBM System z offers the highest QoS characteristics attainable for any particular operating system(s) that run on it. (That is, if you run, say, Linux on an IBM mainframe, from a QoS point of view it'll be the best Linux possible.) High QoS requirements form another bright dividing line.
If you have, say, 1.000 virtual Windows desktops on one mainframe you will still need to employ all the staff that would be needed to run a 1.000 machine network minus the staff needed for dealing with hardware failure.
Really? Because that's not how it works for Linux on IBM mainframes, and there's plenty of experience with that. There really are fewer operations staff required, and those fewer staff deliver much higher quality service.
To keep the answer simple, a single mainframe is a cluster. Everything inside is redundant and hot swappable. And it offers those advantages whether or not the software cares to know about it, and without a single dollar of extra labor. (Although, if the operating system and middleware participate, such as z/OS and DB2 data sharing to pick an example, even more amazing things are possible.)
For example, if a CPU core fails, an IBM System z mainframe will detect it, prevent the mis-executed instruction from surfacing to the operating system, take the core offline, provision a spare core, and continue executing without interruption. All without even the operating system programmer having to write a single (probably buggy) line of code. That's just one example. There are huge differences and huge advantages for many (not all) businesses and applications.
Good point. The first comment about "unusual word sizes" was really pretty funny, because the commenter quite obviously has little understanding of computing history. It was the IBM System/360 (the ancestor to today's IBM System z mainframe) that defined the 8-bit byte and 32-bit word as industry standards, influencing CPU architectures (including Intel's) right to the present day. Otherwise we'd probably have multiples of 6 or possibly 7 bits as our foundational standard for computing. (And there was a lot of pressure during the System/360's design to cheapen up the hardware and slice off a bit or two.)
Perhaps the original commenter would like to open up a command line in Microsoft Windows Vista and count the default number of columns. That number is 80. Why 80? Because, coincidentally about 80 years ago, someone at IBM decided that tabulating cards should be 80 columns wide, and IBM's cards were more popular than Remington's. Yes, Grasshopper, Microsoft Windows has an "unusual" column width that persists to this day.
Sorry, you're quite wrong in multiple ways. The first way you're wrong is that, if Mantissa's z/VOS runs X86 software, it runs X86 software. That would include IEEE floating point, Windows Solitaire, whatever. The second way is that mainframes have always been able to execute IEEE floating point in software, but they (also) in hardware implement IBM floating point. (Thus programmers generally used the hardware implementation in their applications, and why not? But nothing prevented them from running IEEE floating point calculations.) The third way you're wrong is that IBM's System z9 was the first machine in the world to implement IEEE754(r) decimal floating point in microcode. Today the only CPUs in the world that implement IEEE754(r) fully in hardware are POWER6 and System z10. And it looks like it'll stay that way: Intel and IBM just disagree about this aspect of CPU design.
I have never heard of a ballistic missile that could not be tracked back to its point of origin. That means if Iran ever launches a missile as a weapon it'll be her last.
Satellite links, primarily as backup. LEO satellites are better, if possible.
Microwave links, again primarily as backup. Requires line of sight hops but might be appropriate to "skip over" certain places. The taller the towers, the more geography that can be skipped.
Tethered balloons. (The U.S. uses these on its borders in its aerostat system.)
A polar cable route, such as Norway to Alaska to Japan. With global warming this route becomes increasingly practical, but it might be technically possible already with the help of a submarine.
Mesh hops. Scatter numerous radioisotope-powered repeaters along the sea bed and let them chat with each other. Drop a few more every so often to keep the mesh sufficiently healthy.
Local network rerouting. As a backup, reroute traffic over the various national short-haul networks between India and Europe. Pay for carriage and let the various countries in between compete.
None of those things can cause physical harm to a child (or adult, for that matter). What you're talking about is exclusively (and very speculatively) psychological harm.
But by that standard telephones in the house are also dangerous, because junior could ring up a sex line and learn about the mechanics of... well, whatever. The radio is dangerous, too, because junior could listen to Rush Limbaugh. (Rush is even on during playtime. Think of the children!)
You've stumbled onto the correct answer, though. Would I ever let my child use the telephone, listen to the radio, or surf the Internet unsupervised? No, not until certain ages at least, which I should decide based on my most qualified assessment of the child's maturity level. And at least with the Internet I can put a lock on the PC or Mac and require a user ID and password. (I can also quite easily force browsers to only visit certain sites, like Sesame Street's.) I can even cart the whole kit with me if it's a notebook or lock it in a safe if I want. I have far more parental control options available, none of which have anything to do with the government.
I've seen 8 year olds riding Tokyo's subway system solo. The instant any of them show any signs of confusion or distress -- and that's very rare, since their parents teach them how to ride -- any number of genuinely helpful adults (plural) in the vicinity come to their rescue. This is all perfectly normal, and it's entirely within the physical world. Everyone is safe.
The Internet is not even physical. There's always a wire (or wireless connection) separating its participants. Simply combine the Internet with a parent or responsible adult and it's safer (psychologically) than even the Tokyo Metro. (And it's always physically safer.) If government simply concentrated on promoting and supporting good parenting, that'd solve myriad problems. [How about starting by allowing all qualified parent(s), including same-sex parents, to adopt?] The Internet is not a parent any more than a subway car or glass of milk is, so it's ridiculous that any government would try to make the Internet a parent.
The Obama campaign will almost certainly send out text message updates with election results from their point of view. Details (and other text commands) are at http://www.barackobama.com/mobile. If you want lots of updates text FOLLOW BARACKOBAMA to 40404 or use Twitter. (I can't find anything similar from the McCain campaign.) Or better yet you can get a life and volunteer now through Election Day (and even a little beyond) for your preferred candidate running at any level. It's far more enjoyable and interesting than sitting next to a bunch of buzzing electronics.
There's no question that Apple's iPhone/iPod touch behavior is anti-competitive. As Apple gains market power, rising toward #1 in the smartphone market, such behavior might also be illegal in at least some jurisdictions. Apple needs to tread very carefully here.
Anyone can sign up. The current contest iteration is running through the end of the year. There are some COBOL programming exercises. This contest is also a recruitment vehicle. You could end up with a full-time job if you do OK in the contest and want the job.
The bundled Microsoft Windows license, which is still way too difficult to shake loose, is a significant "Microsoft tax." In fact, it's the single most expensive component in most PCs. As the price of other PC components continues to fall, the Microsoft tax is becoming more onerous as a greater share of the cost structure, causing consumers and vendors to rebel increasingly. The tax is particularly acute with netbooks, so Linux is gaining a significant foothold in that market segment.
Microsoft's share price has been stagnant for a long time, and the company has been reluctant to reduce their software pricing. (Actually, their prices keep increasing, and the "anti-piracy" features are growing increasingly annoying to everyone.) This is not a sustainable business model. I think some people at Microsoft sense this and are trying to find various solutions, including more Google-like delivery models and increased segmentation. The explosion in the number of Windows flavors is one example of increased segmentation, juicing the balance sheet near-term but exacerbating the long-term problems. Apple continues to "skim the cream" off the top of the PC market, gaining share each quarter, and Linux netbooks are a growing threat on the low end. Apple now has a $999 MacBook which will sell huge numbers, so they're doing some more segmentation, too. Devices like the iPhone/iPod touch and Google's Android platform are raising questions about the very need for PCs. Open Office and its cousins, like Lotus Symphony and NeoOffice, are disrupting the Microsoft Office franchise. It's a good time for Microsoft to be paranoid.
IBM publishes lots of mainframe benchmarks and has for years. They're called LSPR tables, and there's a ton of data available. There are several different types of workloads measured. But there's this mythology out there, including among many on Slashdot, that benchmarks give you a single number and then you just pick the higher number and you're done. Oh, that'd be so simple and wonderful, but it just doesn't work that way. First of all, your workloads (and time of day patterns) won't match the ones in LSPR (or any other benchmark) exactly, so you have to run some careful adjustments. If you're comparing to some other environment, you have to correlate LSPR values with other values (such as rPerfs or VMmarks or whatever), which also aren't going to match your actual workloads. And then you've got a whole bunch of other considerations, like software licensing and labor costs, capacity and virtual image provisioning capabilities, disaster recovery and other non-functional requirements, data center space/power/cooling limitations, proximity effects for data access (one area where large SMP architectures really shine), execution integrity, and so on. These and other factors go into a careful business case analysis.
But you know what? I think VMware and Xen are wonderful, too. But they have significant limitations. They aren't universal solutions either. I don't know why this is so hard for people to understand, but let me repeat: there's huge mainframe growth because people are running business case analyses and coming to the thoughtful conclusion that they do have a vital role -- probably along with VMware and/or Xen -- in their infrastructure. And they use benchmarks as part of the equation, but frankly they're a necessary but overwhelmingly not sufficient requirement in the overall calculus.
Do people really think somebody buys a mainframe (or indeed, any high-end server) on a whim, without assessment and justification? Come on.
Sure they do, at least in most mainframe operational organizations. (Non-mainframe operations are a different story. You ask "what about avoiding planned outages?" and they look at you funny.) In fact, it's even possible the reboots aren't actually happening, but the operators have reserved the right (in the SLA) to do them, so they declare that early Sunday mornings (for example) are planned outages. If you want a different SLA, ask for it. This certainly isn't a technical problem.
IBM: "Open source? Let me transfer you to our Global Technology Services organization who would be happy to write you a very special support contract at a fair price. They'll support just about anything you can imagine, including whole business processes. Would you like them to take over welfare payments, digital TV transition consumer rebate processing, and backoffice call center support functions too?"
I doubt there's a reason for the IPLs (reboots). If your mainframe operators are doing it, they're probably just doing it because (seriously) somebody had a memory leak 30 years ago and that was how they "fixed" it. And nobody bothered to update the procedures manual. Nor did anybody ask them, "Hey, can we improve the SLA (Service Level Agreement) here?" "Sure boss, I'll just stop IPLing. Let's try skipping the next one." That's usually how that conversation goes, seriously.
In fact, if you've got a Coupling Facility and two or more LPARs (partitions), even on a single machine, then you can reboot either of them as often as you want and no users will care. Transactions keep humming in CICSplex and IMSplex, databases keep running with DB2 data sharing, etc. If your operators haven't implemented that, that's their choice (or negligence?), not the technology's.
Slashdot Mirror
....I am making an argument against the idea that you can have "four nines" availability out of a single server.
And yet, in the real world, that's what many single frame mainframe shops manage. Probably because a single frame isn't at all a single frame internally. The only singleton in the equation is the cabinet itself, and (but only if the operator wants) any particular operating system/middleware/application instances that the operator chooses to run that way (which would typically be development instances, not production).
No, they're doing that because somebody had a memory leak 30+ years ago (back when those might have mattered from a system stability point of view), told the operators to reboot (IPL) every week, and the operators have never updated their procedure manuals. I'm not joking. If you tap an operator on the shoulder and say, "Stop rebooting now," problem solved. (Or, for the ultra-conservatives, switch to once every month, then once every year, then not at all.)
Or, in the alternative, somebody decided 30+ years ago that they'd tell the users the system would be unavailable each weekend for a couple hours for "system maintenance" (back when that might have made sense), then, many years ago (and particularly with Parallel Sysplex), when the operators no longer needed the "maintenance window," nobody bothered to tell the users the good news and make it official. Again, I'm not joking. I was at a meeting at a Fortune 100 company where the conversation went something like this.... Web service team: "We need 24 hour Internet access, but you're down every weekend for 4 hours. We want to move off." Mainframe operator: "You need 24 hours? OK, you have 24 hours." Web service team: "But you didn't do anything." Mainframe operator: "We stopped IPL'ing that LPAR at least 10 years ago, and I'm now declaring you have a 24 hour Service Level Agreement. I'll update our SLA just after our meeting. Need anything else?" Web service team: "Uh, that'll do."
If you want 99.999+ percent business service uptime, factoring in both planned and unplanned outages, and even disaster recovery, just ask for it. (Or ask for some other level if that's too much.) It's no myth, it's the owner's choice, consistent with their budget and "reasonable" (but not superhuman) operations staff.
You posted to Slashdot. You're using a thin client. It's called a Web browser. Welcome to the future.
Good question. There are two physical sizes available: a System z10 BC and System z10 EC. The BC is roughly the same size as a single conventional rack of pizza box servers, and the EC is a double wide (about two racks). In refrigerator terms that's probably closer to the JennAir (or two for the EC) but well shy of the cow locker. Here's a picture of the EC shown to scale with two IBM executives: http://japan.zdnet.com/news/hardware/story/0,2000056184,20368219,00.htm?tag=z.keyword.st
Emulating a $500 PC Server on a $500,000 mainframe... yeah, that sounds real cost-effective!
Then why aren't you driving a Yugo (I presume)? It has a lower price, doesn't it? :-)
If you run this simultaneously in 1000 virtual machines, do you need 1000 Windows licenses?
That's up to Microsoft. I can't wait to see Microsoft's mainframe price list. :-) But if Microsoft wants to be competitive with Oracle and IBM, to pick a couple software vendor examples, then for server software at least (e.g. Microsoft SQL Server) they'd license by core. And yes, a core is a core is a core. How the price of that Yugo looking? :-)
Most of that thousands to one virtualization is based on the same idea that is driving commodity virtualization ala ESX, most servers spend most of their time idle.
That's part of it, but it's not the only part. Otherwise we'd see thousands of virtual machines on a single ESX core, and that's just not what's happening. (The virtualization ratios per core are pretty small. Still useful, though.) Virtualization also places heavy stresses on cache, memory, and I/O performance. IBM System z10 machines are no slouches on CPU -- they have the highest clock speed (4.4 GHz) CPUs with more than 2 cores (they're quad) on the market -- but they balance that with kick-ass cache, main memory, and I/O performance. They also have hypervisors (PR/SM and z/VM) which are extremely refined and uniquely co-evolved with the hardware over decades. Add that all together and you begin to understand why the virtualization ratios get much higher in real world use.
Yes, the usual myriad of analysts (Gartner, Forrester, etc.) have looked at the issue, and, to net it out, they find both IBM System z virtualization and VMware useful and cost-effective. ("Both" is often the right answer, because some workloads do better on one or the other, and most businesses have a mix of workload types.) One bright dividing line has been that VMware obviously can virtualize Microsoft Windows directly (such as Microsoft Exchange and Microsoft SQL Server), while System z could not. But System z has been adding whole operating systems to its virtualization repertoire, including OpenSolaris for System z and now (with Mantissa) Microsoft Windows, so it's moving into new ground.
Cost isn't the only issue of course. Qualities of Service (QoS) are also important. It's undisputed that IBM System z offers the highest QoS characteristics attainable for any particular operating system(s) that run on it. (That is, if you run, say, Linux on an IBM mainframe, from a QoS point of view it'll be the best Linux possible.) High QoS requirements form another bright dividing line.
If you have, say, 1.000 virtual Windows desktops on one mainframe you will still need to employ all the staff that would be needed to run a 1.000 machine network minus the staff needed for dealing with hardware failure.
Really? Because that's not how it works for Linux on IBM mainframes, and there's plenty of experience with that. There really are fewer operations staff required, and those fewer staff deliver much higher quality service.
Windows may still crash on a mainframe, but it'll crash perfectly, exactly as Microsoft intended (or at least coded), consistently every time.
To keep the answer simple, a single mainframe is a cluster. Everything inside is redundant and hot swappable. And it offers those advantages whether or not the software cares to know about it, and without a single dollar of extra labor. (Although, if the operating system and middleware participate, such as z/OS and DB2 data sharing to pick an example, even more amazing things are possible.)
For example, if a CPU core fails, an IBM System z mainframe will detect it, prevent the mis-executed instruction from surfacing to the operating system, take the core offline, provision a spare core, and continue executing without interruption. All without even the operating system programmer having to write a single (probably buggy) line of code. That's just one example. There are huge differences and huge advantages for many (not all) businesses and applications.
Good point. The first comment about "unusual word sizes" was really pretty funny, because the commenter quite obviously has little understanding of computing history. It was the IBM System/360 (the ancestor to today's IBM System z mainframe) that defined the 8-bit byte and 32-bit word as industry standards, influencing CPU architectures (including Intel's) right to the present day. Otherwise we'd probably have multiples of 6 or possibly 7 bits as our foundational standard for computing. (And there was a lot of pressure during the System/360's design to cheapen up the hardware and slice off a bit or two.)
Perhaps the original commenter would like to open up a command line in Microsoft Windows Vista and count the default number of columns. That number is 80. Why 80? Because, coincidentally about 80 years ago, someone at IBM decided that tabulating cards should be 80 columns wide, and IBM's cards were more popular than Remington's. Yes, Grasshopper, Microsoft Windows has an "unusual" column width that persists to this day.
Sorry, you're quite wrong in multiple ways. The first way you're wrong is that, if Mantissa's z/VOS runs X86 software, it runs X86 software. That would include IEEE floating point, Windows Solitaire, whatever. The second way is that mainframes have always been able to execute IEEE floating point in software, but they (also) in hardware implement IBM floating point. (Thus programmers generally used the hardware implementation in their applications, and why not? But nothing prevented them from running IEEE floating point calculations.) The third way you're wrong is that IBM's System z9 was the first machine in the world to implement IEEE754(r) decimal floating point in microcode. Today the only CPUs in the world that implement IEEE754(r) fully in hardware are POWER6 and System z10. And it looks like it'll stay that way: Intel and IBM just disagree about this aspect of CPU design.
I have never heard of a ballistic missile that could not be tracked back to its point of origin. That means if Iran ever launches a missile as a weapon it'll be her last.
None of those things can cause physical harm to a child (or adult, for that matter). What you're talking about is exclusively (and very speculatively) psychological harm.
But by that standard telephones in the house are also dangerous, because junior could ring up a sex line and learn about the mechanics of... well, whatever. The radio is dangerous, too, because junior could listen to Rush Limbaugh. (Rush is even on during playtime. Think of the children!)
You've stumbled onto the correct answer, though. Would I ever let my child use the telephone, listen to the radio, or surf the Internet unsupervised? No, not until certain ages at least, which I should decide based on my most qualified assessment of the child's maturity level. And at least with the Internet I can put a lock on the PC or Mac and require a user ID and password. (I can also quite easily force browsers to only visit certain sites, like Sesame Street's.) I can even cart the whole kit with me if it's a notebook or lock it in a safe if I want. I have far more parental control options available, none of which have anything to do with the government.
I've seen 8 year olds riding Tokyo's subway system solo. The instant any of them show any signs of confusion or distress -- and that's very rare, since their parents teach them how to ride -- any number of genuinely helpful adults (plural) in the vicinity come to their rescue. This is all perfectly normal, and it's entirely within the physical world. Everyone is safe.
The Internet is not even physical. There's always a wire (or wireless connection) separating its participants. Simply combine the Internet with a parent or responsible adult and it's safer (psychologically) than even the Tokyo Metro. (And it's always physically safer.) If government simply concentrated on promoting and supporting good parenting, that'd solve myriad problems. [How about starting by allowing all qualified parent(s), including same-sex parents, to adopt?] The Internet is not a parent any more than a subway car or glass of milk is, so it's ridiculous that any government would try to make the Internet a parent.
The Obama campaign will almost certainly send out text message updates with election results from their point of view. Details (and other text commands) are at http://www.barackobama.com/mobile. If you want lots of updates text FOLLOW BARACKOBAMA to 40404 or use Twitter. (I can't find anything similar from the McCain campaign.) Or better yet you can get a life and volunteer now through Election Day (and even a little beyond) for your preferred candidate running at any level. It's far more enjoyable and interesting than sitting next to a bunch of buzzing electronics.
There's no question that Apple's iPhone/iPod touch behavior is anti-competitive. As Apple gains market power, rising toward #1 in the smartphone market, such behavior might also be illegal in at least some jurisdictions. Apple needs to tread very carefully here.
Anyone can sign up. The current contest iteration is running through the end of the year. There are some COBOL programming exercises. This contest is also a recruitment vehicle. You could end up with a full-time job if you do OK in the contest and want the job.
The bundled Microsoft Windows license, which is still way too difficult to shake loose, is a significant "Microsoft tax." In fact, it's the single most expensive component in most PCs. As the price of other PC components continues to fall, the Microsoft tax is becoming more onerous as a greater share of the cost structure, causing consumers and vendors to rebel increasingly. The tax is particularly acute with netbooks, so Linux is gaining a significant foothold in that market segment.
Microsoft's share price has been stagnant for a long time, and the company has been reluctant to reduce their software pricing. (Actually, their prices keep increasing, and the "anti-piracy" features are growing increasingly annoying to everyone.) This is not a sustainable business model. I think some people at Microsoft sense this and are trying to find various solutions, including more Google-like delivery models and increased segmentation. The explosion in the number of Windows flavors is one example of increased segmentation, juicing the balance sheet near-term but exacerbating the long-term problems. Apple continues to "skim the cream" off the top of the PC market, gaining share each quarter, and Linux netbooks are a growing threat on the low end. Apple now has a $999 MacBook which will sell huge numbers, so they're doing some more segmentation, too. Devices like the iPhone/iPod touch and Google's Android platform are raising questions about the very need for PCs. Open Office and its cousins, like Lotus Symphony and NeoOffice, are disrupting the Microsoft Office franchise. It's a good time for Microsoft to be paranoid.
IBM publishes lots of mainframe benchmarks and has for years. They're called LSPR tables, and there's a ton of data available. There are several different types of workloads measured. But there's this mythology out there, including among many on Slashdot, that benchmarks give you a single number and then you just pick the higher number and you're done. Oh, that'd be so simple and wonderful, but it just doesn't work that way. First of all, your workloads (and time of day patterns) won't match the ones in LSPR (or any other benchmark) exactly, so you have to run some careful adjustments. If you're comparing to some other environment, you have to correlate LSPR values with other values (such as rPerfs or VMmarks or whatever), which also aren't going to match your actual workloads. And then you've got a whole bunch of other considerations, like software licensing and labor costs, capacity and virtual image provisioning capabilities, disaster recovery and other non-functional requirements, data center space/power/cooling limitations, proximity effects for data access (one area where large SMP architectures really shine), execution integrity, and so on. These and other factors go into a careful business case analysis.
But you know what? I think VMware and Xen are wonderful, too. But they have significant limitations. They aren't universal solutions either. I don't know why this is so hard for people to understand, but let me repeat: there's huge mainframe growth because people are running business case analyses and coming to the thoughtful conclusion that they do have a vital role -- probably along with VMware and/or Xen -- in their infrastructure. And they use benchmarks as part of the equation, but frankly they're a necessary but overwhelmingly not sufficient requirement in the overall calculus.
Do people really think somebody buys a mainframe (or indeed, any high-end server) on a whim, without assessment and justification? Come on.
Sure they do, at least in most mainframe operational organizations. (Non-mainframe operations are a different story. You ask "what about avoiding planned outages?" and they look at you funny.) In fact, it's even possible the reboots aren't actually happening, but the operators have reserved the right (in the SLA) to do them, so they declare that early Sunday mornings (for example) are planned outages. If you want a different SLA, ask for it. This certainly isn't a technical problem.
IBM: "Open source? Let me transfer you to our Global Technology Services organization who would be happy to write you a very special support contract at a fair price. They'll support just about anything you can imagine, including whole business processes. Would you like them to take over welfare payments, digital TV transition consumer rebate processing, and backoffice call center support functions too?"
Looks like upstream integration is the intention at least. OpenSolaris.org is hosting the current source.
I doubt there's a reason for the IPLs (reboots). If your mainframe operators are doing it, they're probably just doing it because (seriously) somebody had a memory leak 30 years ago and that was how they "fixed" it. And nobody bothered to update the procedures manual. Nor did anybody ask them, "Hey, can we improve the SLA (Service Level Agreement) here?" "Sure boss, I'll just stop IPLing. Let's try skipping the next one." That's usually how that conversation goes, seriously.
In fact, if you've got a Coupling Facility and two or more LPARs (partitions), even on a single machine, then you can reboot either of them as often as you want and no users will care. Transactions keep humming in CICSplex and IMSplex, databases keep running with DB2 data sharing, etc. If your operators haven't implemented that, that's their choice (or negligence?), not the technology's.