Every time a mainframe story comes up on Slashdot we seem to get the skeptics who point out that an X86 processor core can add or multiply two numbers (stored in registers anyway) about as fast as a single System z10 core, at least as long as they're integers. (z10s have hardware decimal floating point.) Based on this brilliant SPECint-y observation, combined with the fact that a System z10 EC Linux processor has an advertised one-time charge of $125K, these "experts" thus conclude that no one could possibly buy a mainframe because it's just so darn expensive. (Note that's one-time charge, folks: if you do a hardware model upgrade typical IBM practice is to charge you something for the frame swap but not to charge you again for turning on the processors.) Of course, in the same discussion people don't bother to explain why the same argument also holds for SPARC CPUs. Heck, why not run business applications on Sony Playstation 3s or ARMs? They're even "cheaper."
May I humbly point out that IBM just posted (yesterday) another record quarter for mainframe sales. Revenues were up 25 percent, with double digit growth in every region of the world. Because prices are higher? No, the opposite: shipped capacity was up 49 percent; specialty capacity (including Linux processors) was up 120 percent. And IBM has been posting quarters like this for years now. This mainframe stuff is wildly successful and gaining marketshare.
Why? Because, with all due respect, you're an idiot if you stop your careful business case analysis at the first sentence above. Unless you're running SETI@Home, rendering the next Pixar movie, or simulating nuclear explosions, business applications across many users just don't run that way. Companies (particularly CFOs) and big data center managers are not (generally) idiots. They buy this stuff because it works wonderfully and because it's cost-effective, taking all costs into consideration. Think $125K (once) is a lot of money? What's your salary, dude? Who are the richest single human beings in the software industry, and did they get that way because software is free? And how much did it cost the London Stock Exchange when they couldn't trade? Are you the guy who wants to explain why you have to build another $20M data center because you can't power or cool yet another X86 chip? In the real world, there are single companies running hundreds of these mainframe CPUs. And they run at 80%+ busy 24 hours a day, by the way.
Honestly, there are way too many Slashdotters who are much more the stubborn non-thinkers that they probably accused mainframe-skilled people of being a few years ago. It's a different world: grow up. The boring but wonderful truth is that -- surprise! -- different servers are good at different things! Intel/AMD X86 servers are useful in certain ways, and so are System z servers. Even in the same data center. Wow, what a concept!
SPARC and X86 are recompiles from each other already, never mind 32-bit v. 64-bit. z/Architecture is now another choice. Which is why OpenSolaris for System z will be of primary interest to companies that have their own in-house applications available to recompile. (Vendor applications are another question, at least initially.)
Yes, you could move from Solaris to Linux, and many people do. Some people don't want to. This is another choice. You can run multiple operating systems (including Linux) concurrently on a mainframe of course, and almost 100% of mainframe owners do. So you can mix and match. Run DB2 on z/OS and your in-house C/C++ application on OpenSolaris on the same machine, as one example.
Firewire is actually fairly common on even budget PC notebooks, including Dells, so this omission by Apple is all the more perplexing. And Apple still doesn't offer Blu-ray drives or 3G wireless at any price on any model. (No 3G wireless option from the iPhone company!) It also amazes me that their latest hardware refresh still caps RAM at 4G maximum. Even Dell has figured out how to go to 8G max on a notebook.
That said, there is some great design in these new MacBooks. But Apple engineers waxing eloquently about "unibody" construction (it isn't, by the way) when they forgot the damn Firewire port is a bit too much to stomach.
If your sole consideration is application availability, then your idea might make sense. But since you said you don't trust the application hosting company's "robustness," do you still trust them to protect and secure your data adequately? In other words, if you don't trust your IT service supplier in one dimension, why would you still trust them in other service quality dimensions?
Have you thought about establishing a contract with a formal Service Level Agreement (SLA), including penalties and escrow (or equivalent) for non-performance? That would seem to be a much more straightforward and comprehensive way to establish "trust."
If all those households adopted fibre, then none of them would pay for ADSL. So you would have to subtract all current ADSL revenues from the pool of money available to fund this infrastructure. That's a big subtraction.
Chances are excellent that most households which already have ADSL would not switch to fibre unless the difference in price is zero (or very nearly zero). Slashdot audience aside, most households are perfectly content with ADSL "last mile" speeds, at least with the present range of Internet-delivered services.
Put these two facts together and one quickly concludes that, if the cost of the infrastructure is accurate, in order to execute the project the vast majority of funding would come from sources other than household rate payers. I really don't see the point given that there are likely much more attractive alternative business cases, including some combination of urban fibre, wireless, and improved copper-based technologies. Which coincidentally is exactly the approach Japan is taking. New high-rise apartment buildings in urban areas tend to get fibre, most of the rest of the country gets progressively faster ADSL, and various wireless data services keep getting more prevalent. Much of Tokyo has cheap 802.11b/g service available, for example, and the mobile telephone carriers keep boosting their data speeds.
The London Stock Exchange did not run mainframes 8 years ago. (At least not what most people think of when they see the word "mainframes.") They ran Tandem/HP NonStop systems.
Keep an eye on this IBM contests page. IBM should announce a "Master the Mainframe" contest for 2008. (There's one for Australia listed already.) Sign up and enjoy -- that's a great way to get hands-on z/OS learning experience.
The C programming language was invented at Bell Labs starting in 1969 and was, in turn, closely based on the B programming language invented much earlier. COBOL and C are both 3rd generation languages and fairly described as approximate contemporaries of one another. There's nothing inherently "more modern" about a C program, and there are a lot of business programmers who would argue C is much less modern than COBOL, particularly COBOL 2002. They certainly can defend that argument in dollar value and lines of code: COBOL is much more pervasive than C for business application programming. C tends to be pervasive in systems (such as operating systems and middleware) programming. COBOL fans would also have a strong claim on higher developer productivity, particularly for maintenance. C is admittedly comparatively harder to maintain.
Ah, but you say that C has its object-oriented cousin, C++. There's Objected Oriented COBOL (OO COBOL) also, so no extra points there, sorry. And the Java, C#, and Smalltalk (!) programmers all think C++ is ancient and crusty anyway.
Of course all of these programming languages (and others) run on mainframes -- yes, even C#, since Mono runs on mainframes -- so I'm not sure what your point is.
Actually, IBM has been putting a lot of POWER inspiration into its z10 processors, although they are not at all the same. That means a z10 core is clocked at 4.4 GHz. It also has hardware decimal floating point, something nothing else has (except POWER6), which speeds floating point calculations by about 3 orders of magnitude versus software.
These processors are state-of-the-art, even in raw computational performance terms.
And scaling up a single mainframe gets exponentially more expensive; the price buying more commodity servers stays constant, meaning a linear cost of scaling.
Why do IT people (I'm assuming) make such lousy economists?
Think about it for just half a second. If you want to double the transactional capacity ("throughput") of your mainframe, you turn on more processor(s) inside the same box. (It's almost always inside the same box. A single mainframe can have massive capacity.) And you only do so when the mainframe is 100% busy for sustained periods, which it gracefully handles by the way without choking. You have zero reconfiguration to do to hardware, software, or applications: it's "on tap." (In fact, the machine itself can provision itself nowadays.) This is very cheap: doubling costs way, way less than the initial allocation. Also, up to 32 machines can share memory and operate as one, so if you are unusual and hit a single machine limit, no problem. It's only past 32 that you resort to partioning, traditional clustering, etc. -- and you've still got a lot more weapons at your disposal.
If you want to double your actual transactional capacity with highly distributed servers, you...well, it may be impossible. You better hope you have highly segmented and partitioned work for those servers to do, and that it is extremely well balanced so that it fits into little server buckets. The burden is mostly or entirely on you, the application developer, to figure that out -- and that's horribly expensive. (Because the work never is balanced, you have to install a bunch of servers that don't run continuously at near 100% busy, so you get less real-world performance out of each processor anyway.) But at the very least you have to more than double the number of boxes. And you have a lot of knobs to twist and turn to get your work settled into its new, large number of machines, so you better hope you don't need that extra capacity NOW. (Can't process those credit card transactions during a spike in demand? Sorry about that -- I guess your credit card company will just have skip collecting those millions of dollars.) And you get to hire and pay some more people to install, configure, and maintain those extra boxes. You also get to find more space in your data center (if you have it), consume more than double the power (if you have it), and run the air conditioning more than twice as hard (if you can). You pay Oracle, Microsoft, et. al. at least double, too. (That's not how mainframe softwre works: there are strong price curves, not lines.)
Fortunately there are some IT-economists in the world who understand this stuff.
Most routers are cheap. (Apple's is overpriced-cheap; the point stands.) A bunch of them are free after rebates. Considering that, it's a wonder they keep running for more than 5 minutes. They come off the same assembly lines as those Norcent (who?) $15 DVD players.
You can buy reliable routers of course, from the C company, or the N company, or the J company, or a couple others. That's what corporations buy. What I wonder, though, is whether there's a middle ground: a "pro-sumer" router. Maybe somebody has got some suggestions.
I've always wondered why Steve Jobs didn't announce a dual-architecture strategy from the get-go. But perhaps that was the plan all along, and Apple simply needed to announce "Intel only" to get all their developers moved as quickly as possible to universal binaries. Now that Microsoft and Adobe, the last holdouts, have complied, Apple can go back to a dual (or even tri, with iPhone's ARM) architecture approach, choosing the right processor core for the right device and maximizing its flexibility and distinctiveness.
For example, the PowerPC core would be perfect for AppleTV and possibly a new Mac nano, where the cost of an Intel chip simply doesn't make sense. Apple is probably losing money on every AppleTV box right now. Every universal binary already runs on PowerPC, so all the applications and development ecosystem are already in place. The fact VMware and Parallels don't run on PowerPC is a feature, not a bug: Apple can wean some more users away from Microsoft Windows as certain devices hit the market and get some better market segmentation. Users who want Intel can buy Intel, and users who want alternative form factors, alternative power consumption profiles, lower cost, and/or new device categories can get PowerPC under the hood and still run the full Mac OS X portfolio of software. And having their own chip company helps keep Intel honest. Apple probably didn't like Intel's forced march from Santa Rosa to Penryn. That was inconsistent with Apple's longer product cycles. And all the game consoles are PowerPC-based, so that could be appealing if Apple ever wants to entice some game developers over to some of their devices. (Games do tend to work down on the iron.) IBM continues to underwrite PowerPC for its own server lines and has cranked up POWER6 to 5.0 GHz in its servers, way beyond Intel's best, so it's still an architecture with a lot of interesting advantages.
First of all, I suspect you'll get a fair number of comments arguing against attending a liberal arts college. You're asking a Slashdot audience, so approach such comments with caution.
I've interviewed and hired some employees, and I have also interviewed dozens of students applying to one of America's most elite universities for admission (or much more often rejection). (I also had a similar decision to make at age 17.) Above all else I look for candidates who can learn quickly and who can communicate well. That second attribute is arguably less common among graduates from technical institutions, but communication starts with your resume (or a campus recruiting event, or whatever), not with the mere identity of your college, so I keep an open mind and would invite you to an interview if the signs are otherwise positive. I also look for inquisitiveness: are you a person who is inherently curious about the world? I look for other attributes, too, but those three are priorities.
But even before you get to an interview or apply for a job, do you know what you want to do when you grow up? A lot of prospective college students are not sure, and many or most change their minds. Some colleges provide more options than others if you do change your mind. I would recommend using college as a vehicle to explore your curiosities. That journey of exploration builds confidence, and confident, thoughtful people often interview better. If you are already sure about your path, great, go chase your dream. If you are not, then go explore what fascinates you to build your dream.
I love this "single point of failure" argument. It's a fallacy. The only single point of failure with a single mainframe is the building it physically sits in. A single mainframe is internally redundant in every possible respect you can think of (and several you didn't think of). It is that cluster you talk about fondly, except there's no (error-prone) self-assembly and no particular management burden required. It. Just. Works.
But if you're concerned about a building failure -- fire, flood, whatever -- you can buy a second machine. IBM will sell that second machine to you at a lower price. You can put the second machine in a second building, you can run fiber (preferably with two separate physical paths) between the two machines, keep them many tens of kilometers apart, and run them as a single, seamless cluster (called a Geographically Dispersed Parallel Sysplex). And, as a programmer, you have absolutely zero coding responsibility to make that all work. If anything bad happens all your transactions instantly flip over to the other site, in-flight, real-time. And you don't lose a single byte or a single customer, and you can prove you didn't. You can also service any element of that cluster -- any element, from software to hardware to network to whatever -- without any interruption in business service. Yes, you can upgrade your database engine version while everybody's credit cards keep working. Neat party trick, that, but it's business-as-usual for mainframes.
Scalable? Each machine contains up to 64 main processors (and a minimum of two spares!) running at 4.4 GHz with more cache (and more cache levels, including copious shared cache) than anything else. (Even the clock speed argument is gone. It's a faster clock speed than X86.) Plus scores of secondary processors -- the main processors only do real work, not encryption or I/O. They don't even handle clustering -- there are dedicated processors for that. You can stuff 1.5 TB of RAM in each frame. And you can have a single cluster -- which behaves like a single logical machine from a programmer's point of view -- containing up to 32 of these machines. That's a single "machine" with 2048 main processors and hundreds (thousands?) of assist processors. Beyond that you can still do everything an Intel cluster can, like conventional load-balancing (e.g. HTTP spraying) across multiple 2048-CPU clusters. But no one has yet invented a core banking system, for example, that exceeds even a couple of these 64-way machines for a large Chinese bank, to give you some perspective.
No, this stuff is in a different league. Please read up on it sometime before dismissing it offhand. I don't dismiss the value of X86 blades for certain applications, but this mainframe stuff is very different and has important roles. Telecom switching, maybe maybe not. Telecom billing, you bet.
Mainframes, for example? Google's current deployment architecture is simply very energy- (and space-) intensive. Different servers are optimized for different types of computing, and Google does a lot of what mainframes do best. Maybe Google will figure that out before trashing the environment any more.
I think there's a lot of misleading information in the original article, so I'm glad you dug up the truth. To expand on what you discovered, in 2000 (7 years ago this month) IBM began shipping its 64-bit z900 model. At virtually the same time you could boot the operating system into 64-bit mode, and you got a substantial subcapacity software discount as soon as you did that. The same year, the University of Manitoba bought the now-obsolete 31-bit [sic] Amdahl 415, probably with full knowledge that the 64-bit revolution was already in motion. By early 2001, 64-bit Linux appeared. UoM couldn't run it. By that time, if it wasn't clear before, Amdahl was telling the newspapers they would not develop 64-bit technology, so UoM had to know. In 2002, IBM introduced the 64-bit z800, a smaller machine than the z900. UoM didn't buy one. In 2004, IBM introduced the 64-bit z890, an even better smaller machine, with still lower software charges, more configuration choices, and various other improvements. UoM didn't buy one. Also in 2004, IBM introduced 64-bit DB2. UoM couldn't run it. In 2005, UoM bought an incredibly crusty 31-bit [sic] Amdahl 1015, which couldn't run 64-bit software IBM introduced now 5 years prior. In 2006, IBM introduced the 64-bit System z9 BC, with even lower software charges, even more configuration choices, various other improvements, and slashed the hardware price up to 50%. UoM didn't buy one. By this time z800 prices were crashing into the US$30K to $40K range on the secondary market, lower than the price of a mediocre distributed UNIX server. UoM didn't buy one. In late 2006, IBM introduced 64-bit WebSphere Application Server. UoM couldn't run it. In the spring of 2007, IBM introduced CICS Transaction Server Version 3.2 with 64-bit features. UoM couldn't run it. At about the same time, IBM introduced the second version of 64-bit DB2. UoM couldn't run that either. In March, 2007, after literally years of notice, IBM discontinued support for 31-bit z/OS, the last version that can run on an Amdahl. On April 1, 2007, UoM was unsupported.
At the end of 2007, UoM unplugged their thoroughly rotted, year 1999-priced, can't-educate-anybody-on-anything-still-relevant, non-IBM mainframe that couldn't run software that IBM introduced over the past 7 years. Why should anyone be surprised that an organization would unplug technology they mismanaged so badly?
The original Computerworld article cited is confusing, but it refers to UNIX mainframes. The most likely educated guess is they're talking about high-end UNIX servers from Sun, Hewlett-Packard, and/or IBM, not what we would generally think of as true mainframes, notably IBM's System z.
Yes, among System z's five popular operating systems z/OS contains a complete and certified UNIX(TM) implementation (called z/OS UNIX System Services). And yes, System z runs 100% GPL open source kernel.org Linux. And yes, OpenSolaris on z will be z's OS #6 before too long, and that's clearly UNIX(TM) too. But I doubt the article is talking about any of these technologies, based on the context of the article. There are not 2,500 U.S. hospital IBM mainframes (the number of McKesson hospital customers cited), for example. Maybe there should be.
Computerworld's editors seem to be on vacation, unfortunately, so their usually good copy editing is suffering, resulting in some gibberish articles. This week they also reported that Steve Jobs and The Woz approached Commodore in 1982 to talk about the latter company selling the Apple II, pointing out that Apple's two founders didn't have enough money to launch the product, worked out of a basement, and the safety and stability of cashing out for a couple hundred Gs was better than the alternative. Unfortunately for Computerworld they got the date wrong: by 1982 Apple was doing just fine, and The Woz was doing Nissan commercials.
The short answer is yes. In typical real world data centers most X86 processors burn a lot of watts (and generate heat, which must be cooled), take up a lot of space, do only one thing (e.g. serving files, running a firewall, churning through some PHP to compose a page, or something else), and are busy an average of 5% over their powered up lifetimes, give or take. They are also often I/O starved (cache misses, waiting on data from disk) and do more "housekeeping" work (encryption, I/O, etc.) You need to cluster them for higher availability, doubling energy consumption, plus add disaster recovery servers. Virtualization, such as VMware, provides some benefit, but it's still very difficult in the real world to make large efficiency improvements.
Mainframe processors (which are z/Architecture CPUs, not POWER6 by the way) spend their entire powered on lives consuming less electricity (and generating less heat), take up less space, do hundreds of things (virtualization), and are busy an average of 80% or more over their powered up lifetimes. (It's not uncommon for them to run flat out at 100% round the clock.) They are rarely I/O starved (cache misses are rare), and they do almost no housekeeping work because low power specialized support processors take care of that. You can use virtual clusters on a single server, because everything inside the server is redundant but in a low power way. (If a CPU fails, for example, the system swaps in a spare dynamically without even the OS having a clue it happened.) DR is also more power efficient.
But regardless of the reasons, what's most interesting about this development is that server energy consumption is now going to be subject to exact, real world measurement. The measurements are in pure business terms: if you reduce power consumption in your data center while presumably still running your business, you get credits (worth money) you can sell. I think that's the fairest way to separate vendor hype from reality, and to encourage businesses to actually reduce their power consumption in the most effective ways possible. How much total, real business computing activity can a particular processor support per watt per year? These certificates will answer that.
There are degrees of better. A Toyota Camry gets better gas mileage than a Lincoln Navigator, and a Toyota Prius gets better gas mileage than a Camry. System p does well, and System z does really well, basically.
Watts per core is interesting but is not even close to the whole game. Mobile Intel processors consume relatively few watts, for example, but typically they aren't well suited to highly concentrated and virtualized business computing. They're great for notebook computers, though. It's really about how many users you can serve across 100+ diverse business applications using a given processor consuming a certain number of watts (and how reliably, securely, predictably, etc.)
First of all, there are five operating systems available for System z, including Linux and z/OS. You do not need z/OS to run Linux, although you do need Linux to run z/OS. (The Hardware Management Console is Linux-based.)
But since you mentioned JCL (Job Control Language), a unique z/OS feature, it's interesting that UNIX doesn't seem to have any analog to it. (Shell scripts aren't really the same thing at all. They're more analogous to TSO and REXX.) It's certainly a simple syntax and arguably quite a bit easier to learn than shell scripts. That said, nowadays people write a lot less JCL since the serious usability improvements, e.g. modern development tools, tend to do it all for you, e.g. compiling your code.
Slashdot Mirror
Uh, no. z/Architecture and POWER have different instruction sets.
Every time a mainframe story comes up on Slashdot we seem to get the skeptics who point out that an X86 processor core can add or multiply two numbers (stored in registers anyway) about as fast as a single System z10 core, at least as long as they're integers. (z10s have hardware decimal floating point.) Based on this brilliant SPECint-y observation, combined with the fact that a System z10 EC Linux processor has an advertised one-time charge of $125K, these "experts" thus conclude that no one could possibly buy a mainframe because it's just so darn expensive. (Note that's one-time charge, folks: if you do a hardware model upgrade typical IBM practice is to charge you something for the frame swap but not to charge you again for turning on the processors.) Of course, in the same discussion people don't bother to explain why the same argument also holds for SPARC CPUs. Heck, why not run business applications on Sony Playstation 3s or ARMs? They're even "cheaper."
May I humbly point out that IBM just posted (yesterday) another record quarter for mainframe sales. Revenues were up 25 percent, with double digit growth in every region of the world. Because prices are higher? No, the opposite: shipped capacity was up 49 percent; specialty capacity (including Linux processors) was up 120 percent. And IBM has been posting quarters like this for years now. This mainframe stuff is wildly successful and gaining marketshare.
Why? Because, with all due respect, you're an idiot if you stop your careful business case analysis at the first sentence above. Unless you're running SETI@Home, rendering the next Pixar movie, or simulating nuclear explosions, business applications across many users just don't run that way. Companies (particularly CFOs) and big data center managers are not (generally) idiots. They buy this stuff because it works wonderfully and because it's cost-effective, taking all costs into consideration. Think $125K (once) is a lot of money? What's your salary, dude? Who are the richest single human beings in the software industry, and did they get that way because software is free? And how much did it cost the London Stock Exchange when they couldn't trade? Are you the guy who wants to explain why you have to build another $20M data center because you can't power or cool yet another X86 chip? In the real world, there are single companies running hundreds of these mainframe CPUs. And they run at 80%+ busy 24 hours a day, by the way.
Honestly, there are way too many Slashdotters who are much more the stubborn non-thinkers that they probably accused mainframe-skilled people of being a few years ago. It's a different world: grow up. The boring but wonderful truth is that -- surprise! -- different servers are good at different things! Intel/AMD X86 servers are useful in certain ways, and so are System z servers. Even in the same data center. Wow, what a concept!
SPARC and X86 are recompiles from each other already, never mind 32-bit v. 64-bit. z/Architecture is now another choice. Which is why OpenSolaris for System z will be of primary interest to companies that have their own in-house applications available to recompile. (Vendor applications are another question, at least initially.)
Yes, you could move from Solaris to Linux, and many people do. Some people don't want to. This is another choice. You can run multiple operating systems (including Linux) concurrently on a mainframe of course, and almost 100% of mainframe owners do. So you can mix and match. Run DB2 on z/OS and your in-house C/C++ application on OpenSolaris on the same machine, as one example.
Someone is already working on bringing Microsoft Windows to the mainframe. Who could have imagined.
Firewire is actually fairly common on even budget PC notebooks, including Dells, so this omission by Apple is all the more perplexing. And Apple still doesn't offer Blu-ray drives or 3G wireless at any price on any model. (No 3G wireless option from the iPhone company!) It also amazes me that their latest hardware refresh still caps RAM at 4G maximum. Even Dell has figured out how to go to 8G max on a notebook.
That said, there is some great design in these new MacBooks. But Apple engineers waxing eloquently about "unibody" construction (it isn't, by the way) when they forgot the damn Firewire port is a bit too much to stomach.
If your sole consideration is application availability, then your idea might make sense. But since you said you don't trust the application hosting company's "robustness," do you still trust them to protect and secure your data adequately? In other words, if you don't trust your IT service supplier in one dimension, why would you still trust them in other service quality dimensions?
Have you thought about establishing a contract with a formal Service Level Agreement (SLA), including penalties and escrow (or equivalent) for non-performance? That would seem to be a much more straightforward and comprehensive way to establish "trust."
If all those households adopted fibre, then none of them would pay for ADSL. So you would have to subtract all current ADSL revenues from the pool of money available to fund this infrastructure. That's a big subtraction.
Chances are excellent that most households which already have ADSL would not switch to fibre unless the difference in price is zero (or very nearly zero). Slashdot audience aside, most households are perfectly content with ADSL "last mile" speeds, at least with the present range of Internet-delivered services.
Put these two facts together and one quickly concludes that, if the cost of the infrastructure is accurate, in order to execute the project the vast majority of funding would come from sources other than household rate payers. I really don't see the point given that there are likely much more attractive alternative business cases, including some combination of urban fibre, wireless, and improved copper-based technologies. Which coincidentally is exactly the approach Japan is taking. New high-rise apartment buildings in urban areas tend to get fibre, most of the rest of the country gets progressively faster ADSL, and various wireless data services keep getting more prevalent. Much of Tokyo has cheap 802.11b/g service available, for example, and the mobile telephone carriers keep boosting their data speeds.
The London Stock Exchange did not run mainframes 8 years ago. (At least not what most people think of when they see the word "mainframes.") They ran Tandem/HP NonStop systems.
Keep an eye on this IBM contests page. IBM should announce a "Master the Mainframe" contest for 2008. (There's one for Australia listed already.) Sign up and enjoy -- that's a great way to get hands-on z/OS learning experience.
The C programming language was invented at Bell Labs starting in 1969 and was, in turn, closely based on the B programming language invented much earlier. COBOL and C are both 3rd generation languages and fairly described as approximate contemporaries of one another. There's nothing inherently "more modern" about a C program, and there are a lot of business programmers who would argue C is much less modern than COBOL, particularly COBOL 2002. They certainly can defend that argument in dollar value and lines of code: COBOL is much more pervasive than C for business application programming. C tends to be pervasive in systems (such as operating systems and middleware) programming. COBOL fans would also have a strong claim on higher developer productivity, particularly for maintenance. C is admittedly comparatively harder to maintain.
Ah, but you say that C has its object-oriented cousin, C++. There's Objected Oriented COBOL (OO COBOL) also, so no extra points there, sorry. And the Java, C#, and Smalltalk (!) programmers all think C++ is ancient and crusty anyway.
Of course all of these programming languages (and others) run on mainframes -- yes, even C#, since Mono runs on mainframes -- so I'm not sure what your point is.
Actually, IBM has been putting a lot of POWER inspiration into its z10 processors, although they are not at all the same. That means a z10 core is clocked at 4.4 GHz. It also has hardware decimal floating point, something nothing else has (except POWER6), which speeds floating point calculations by about 3 orders of magnitude versus software.
These processors are state-of-the-art, even in raw computational performance terms.
And scaling up a single mainframe gets exponentially more expensive; the price buying more commodity servers stays constant, meaning a linear cost of scaling.
Why do IT people (I'm assuming) make such lousy economists?
Think about it for just half a second. If you want to double the transactional capacity ("throughput") of your mainframe, you turn on more processor(s) inside the same box. (It's almost always inside the same box. A single mainframe can have massive capacity.) And you only do so when the mainframe is 100% busy for sustained periods, which it gracefully handles by the way without choking. You have zero reconfiguration to do to hardware, software, or applications: it's "on tap." (In fact, the machine itself can provision itself nowadays.) This is very cheap: doubling costs way, way less than the initial allocation. Also, up to 32 machines can share memory and operate as one, so if you are unusual and hit a single machine limit, no problem. It's only past 32 that you resort to partioning, traditional clustering, etc. -- and you've still got a lot more weapons at your disposal.
If you want to double your actual transactional capacity with highly distributed servers, you...well, it may be impossible. You better hope you have highly segmented and partitioned work for those servers to do, and that it is extremely well balanced so that it fits into little server buckets. The burden is mostly or entirely on you, the application developer, to figure that out -- and that's horribly expensive. (Because the work never is balanced, you have to install a bunch of servers that don't run continuously at near 100% busy, so you get less real-world performance out of each processor anyway.) But at the very least you have to more than double the number of boxes. And you have a lot of knobs to twist and turn to get your work settled into its new, large number of machines, so you better hope you don't need that extra capacity NOW. (Can't process those credit card transactions during a spike in demand? Sorry about that -- I guess your credit card company will just have skip collecting those millions of dollars.) And you get to hire and pay some more people to install, configure, and maintain those extra boxes. You also get to find more space in your data center (if you have it), consume more than double the power (if you have it), and run the air conditioning more than twice as hard (if you can). You pay Oracle, Microsoft, et. al. at least double, too. (That's not how mainframe softwre works: there are strong price curves, not lines.)
Fortunately there are some IT-economists in the world who understand this stuff.
Looks like Cisco has something in this category. It's about $329 on Amazon.
Most routers are cheap. (Apple's is overpriced-cheap; the point stands.) A bunch of them are free after rebates. Considering that, it's a wonder they keep running for more than 5 minutes. They come off the same assembly lines as those Norcent (who?) $15 DVD players.
You can buy reliable routers of course, from the C company, or the N company, or the J company, or a couple others. That's what corporations buy. What I wonder, though, is whether there's a middle ground: a "pro-sumer" router. Maybe somebody has got some suggestions.
TC-PIP would only be a permitted assignment for a civil aircraft registered in Turkey.
The state is issuing your choice among these substitutes: TIT TNA SOB POS FAG FUK SUK PEE ASS POO DIE
I've always wondered why Steve Jobs didn't announce a dual-architecture strategy from the get-go. But perhaps that was the plan all along, and Apple simply needed to announce "Intel only" to get all their developers moved as quickly as possible to universal binaries. Now that Microsoft and Adobe, the last holdouts, have complied, Apple can go back to a dual (or even tri, with iPhone's ARM) architecture approach, choosing the right processor core for the right device and maximizing its flexibility and distinctiveness.
For example, the PowerPC core would be perfect for AppleTV and possibly a new Mac nano, where the cost of an Intel chip simply doesn't make sense. Apple is probably losing money on every AppleTV box right now. Every universal binary already runs on PowerPC, so all the applications and development ecosystem are already in place. The fact VMware and Parallels don't run on PowerPC is a feature, not a bug: Apple can wean some more users away from Microsoft Windows as certain devices hit the market and get some better market segmentation. Users who want Intel can buy Intel, and users who want alternative form factors, alternative power consumption profiles, lower cost, and/or new device categories can get PowerPC under the hood and still run the full Mac OS X portfolio of software. And having their own chip company helps keep Intel honest. Apple probably didn't like Intel's forced march from Santa Rosa to Penryn. That was inconsistent with Apple's longer product cycles. And all the game consoles are PowerPC-based, so that could be appealing if Apple ever wants to entice some game developers over to some of their devices. (Games do tend to work down on the iron.) IBM continues to underwrite PowerPC for its own server lines and has cranked up POWER6 to 5.0 GHz in its servers, way beyond Intel's best, so it's still an architecture with a lot of interesting advantages.
First of all, I suspect you'll get a fair number of comments arguing against attending a liberal arts college. You're asking a Slashdot audience, so approach such comments with caution.
I've interviewed and hired some employees, and I have also interviewed dozens of students applying to one of America's most elite universities for admission (or much more often rejection). (I also had a similar decision to make at age 17.) Above all else I look for candidates who can learn quickly and who can communicate well. That second attribute is arguably less common among graduates from technical institutions, but communication starts with your resume (or a campus recruiting event, or whatever), not with the mere identity of your college, so I keep an open mind and would invite you to an interview if the signs are otherwise positive. I also look for inquisitiveness: are you a person who is inherently curious about the world? I look for other attributes, too, but those three are priorities.
But even before you get to an interview or apply for a job, do you know what you want to do when you grow up? A lot of prospective college students are not sure, and many or most change their minds. Some colleges provide more options than others if you do change your mind. I would recommend using college as a vehicle to explore your curiosities. That journey of exploration builds confidence, and confident, thoughtful people often interview better. If you are already sure about your path, great, go chase your dream. If you are not, then go explore what fascinates you to build your dream.
Good luck.
I love this "single point of failure" argument. It's a fallacy. The only single point of failure with a single mainframe is the building it physically sits in. A single mainframe is internally redundant in every possible respect you can think of (and several you didn't think of). It is that cluster you talk about fondly, except there's no (error-prone) self-assembly and no particular management burden required. It. Just. Works.
But if you're concerned about a building failure -- fire, flood, whatever -- you can buy a second machine. IBM will sell that second machine to you at a lower price. You can put the second machine in a second building, you can run fiber (preferably with two separate physical paths) between the two machines, keep them many tens of kilometers apart, and run them as a single, seamless cluster (called a Geographically Dispersed Parallel Sysplex). And, as a programmer, you have absolutely zero coding responsibility to make that all work. If anything bad happens all your transactions instantly flip over to the other site, in-flight, real-time. And you don't lose a single byte or a single customer, and you can prove you didn't. You can also service any element of that cluster -- any element, from software to hardware to network to whatever -- without any interruption in business service. Yes, you can upgrade your database engine version while everybody's credit cards keep working. Neat party trick, that, but it's business-as-usual for mainframes.
Scalable? Each machine contains up to 64 main processors (and a minimum of two spares!) running at 4.4 GHz with more cache (and more cache levels, including copious shared cache) than anything else. (Even the clock speed argument is gone. It's a faster clock speed than X86.) Plus scores of secondary processors -- the main processors only do real work, not encryption or I/O. They don't even handle clustering -- there are dedicated processors for that. You can stuff 1.5 TB of RAM in each frame. And you can have a single cluster -- which behaves like a single logical machine from a programmer's point of view -- containing up to 32 of these machines. That's a single "machine" with 2048 main processors and hundreds (thousands?) of assist processors. Beyond that you can still do everything an Intel cluster can, like conventional load-balancing (e.g. HTTP spraying) across multiple 2048-CPU clusters. But no one has yet invented a core banking system, for example, that exceeds even a couple of these 64-way machines for a large Chinese bank, to give you some perspective.
No, this stuff is in a different league. Please read up on it sometime before dismissing it offhand. I don't dismiss the value of X86 blades for certain applications, but this mainframe stuff is very different and has important roles. Telecom switching, maybe maybe not. Telecom billing, you bet.
Mainframes, for example? Google's current deployment architecture is simply very energy- (and space-) intensive. Different servers are optimized for different types of computing, and Google does a lot of what mainframes do best. Maybe Google will figure that out before trashing the environment any more.
I think there's a lot of misleading information in the original article, so I'm glad you dug up the truth. To expand on what you discovered, in 2000 (7 years ago this month) IBM began shipping its 64-bit z900 model. At virtually the same time you could boot the operating system into 64-bit mode, and you got a substantial subcapacity software discount as soon as you did that. The same year, the University of Manitoba bought the now-obsolete 31-bit [sic] Amdahl 415, probably with full knowledge that the 64-bit revolution was already in motion. By early 2001, 64-bit Linux appeared. UoM couldn't run it. By that time, if it wasn't clear before, Amdahl was telling the newspapers they would not develop 64-bit technology, so UoM had to know. In 2002, IBM introduced the 64-bit z800, a smaller machine than the z900. UoM didn't buy one. In 2004, IBM introduced the 64-bit z890, an even better smaller machine, with still lower software charges, more configuration choices, and various other improvements. UoM didn't buy one. Also in 2004, IBM introduced 64-bit DB2. UoM couldn't run it. In 2005, UoM bought an incredibly crusty 31-bit [sic] Amdahl 1015, which couldn't run 64-bit software IBM introduced now 5 years prior. In 2006, IBM introduced the 64-bit System z9 BC, with even lower software charges, even more configuration choices, various other improvements, and slashed the hardware price up to 50%. UoM didn't buy one. By this time z800 prices were crashing into the US$30K to $40K range on the secondary market, lower than the price of a mediocre distributed UNIX server. UoM didn't buy one. In late 2006, IBM introduced 64-bit WebSphere Application Server. UoM couldn't run it. In the spring of 2007, IBM introduced CICS Transaction Server Version 3.2 with 64-bit features. UoM couldn't run it. At about the same time, IBM introduced the second version of 64-bit DB2. UoM couldn't run that either. In March, 2007, after literally years of notice, IBM discontinued support for 31-bit z/OS, the last version that can run on an Amdahl. On April 1, 2007, UoM was unsupported.
At the end of 2007, UoM unplugged their thoroughly rotted, year 1999-priced, can't-educate-anybody-on-anything-still-relevant, non-IBM mainframe that couldn't run software that IBM introduced over the past 7 years. Why should anyone be surprised that an organization would unplug technology they mismanaged so badly?
The original Computerworld article cited is confusing, but it refers to UNIX mainframes. The most likely educated guess is they're talking about high-end UNIX servers from Sun, Hewlett-Packard, and/or IBM, not what we would generally think of as true mainframes, notably IBM's System z.
Yes, among System z's five popular operating systems z/OS contains a complete and certified UNIX(TM) implementation (called z/OS UNIX System Services). And yes, System z runs 100% GPL open source kernel.org Linux. And yes, OpenSolaris on z will be z's OS #6 before too long, and that's clearly UNIX(TM) too. But I doubt the article is talking about any of these technologies, based on the context of the article. There are not 2,500 U.S. hospital IBM mainframes (the number of McKesson hospital customers cited), for example. Maybe there should be.
Computerworld's editors seem to be on vacation, unfortunately, so their usually good copy editing is suffering, resulting in some gibberish articles. This week they also reported that Steve Jobs and The Woz approached Commodore in 1982 to talk about the latter company selling the Apple II, pointing out that Apple's two founders didn't have enough money to launch the product, worked out of a basement, and the safety and stability of cashing out for a couple hundred Gs was better than the alternative. Unfortunately for Computerworld they got the date wrong: by 1982 Apple was doing just fine, and The Woz was doing Nissan commercials.
The short answer is yes. In typical real world data centers most X86 processors burn a lot of watts (and generate heat, which must be cooled), take up a lot of space, do only one thing (e.g. serving files, running a firewall, churning through some PHP to compose a page, or something else), and are busy an average of 5% over their powered up lifetimes, give or take. They are also often I/O starved (cache misses, waiting on data from disk) and do more "housekeeping" work (encryption, I/O, etc.) You need to cluster them for higher availability, doubling energy consumption, plus add disaster recovery servers. Virtualization, such as VMware, provides some benefit, but it's still very difficult in the real world to make large efficiency improvements.
Mainframe processors (which are z/Architecture CPUs, not POWER6 by the way) spend their entire powered on lives consuming less electricity (and generating less heat), take up less space, do hundreds of things (virtualization), and are busy an average of 80% or more over their powered up lifetimes. (It's not uncommon for them to run flat out at 100% round the clock.) They are rarely I/O starved (cache misses are rare), and they do almost no housekeeping work because low power specialized support processors take care of that. You can use virtual clusters on a single server, because everything inside the server is redundant but in a low power way. (If a CPU fails, for example, the system swaps in a spare dynamically without even the OS having a clue it happened.) DR is also more power efficient.
But regardless of the reasons, what's most interesting about this development is that server energy consumption is now going to be subject to exact, real world measurement. The measurements are in pure business terms: if you reduce power consumption in your data center while presumably still running your business, you get credits (worth money) you can sell. I think that's the fairest way to separate vendor hype from reality, and to encourage businesses to actually reduce their power consumption in the most effective ways possible. How much total, real business computing activity can a particular processor support per watt per year? These certificates will answer that.
There are degrees of better. A Toyota Camry gets better gas mileage than a Lincoln Navigator, and a Toyota Prius gets better gas mileage than a Camry. System p does well, and System z does really well, basically.
Watts per core is interesting but is not even close to the whole game. Mobile Intel processors consume relatively few watts, for example, but typically they aren't well suited to highly concentrated and virtualized business computing. They're great for notebook computers, though. It's really about how many users you can serve across 100+ diverse business applications using a given processor consuming a certain number of watts (and how reliably, securely, predictably, etc.)
First of all, there are five operating systems available for System z, including Linux and z/OS. You do not need z/OS to run Linux, although you do need Linux to run z/OS. (The Hardware Management Console is Linux-based.)
But since you mentioned JCL (Job Control Language), a unique z/OS feature, it's interesting that UNIX doesn't seem to have any analog to it. (Shell scripts aren't really the same thing at all. They're more analogous to TSO and REXX.) It's certainly a simple syntax and arguably quite a bit easier to learn than shell scripts. That said, nowadays people write a lot less JCL since the serious usability improvements, e.g. modern development tools, tend to do it all for you, e.g. compiling your code.