11 ms·

Western civilization runs on the mainframe

154 points by a2tech 16y ago

wallflower 16y ago
"According to Maclean, comparing mainframe performance against, say, Oracle running on an x86 server platform may yield similar results in a low usage scenario. However, a mainframe will prove its value as that application set scales up in volume. The difference isn’t in the CPU, which (in non-IBM cases) is the same on both sides of the comparison. Rather, the difference is in the architecture of the operating environment." http://www.processor.com/editorial/article.asp?article=articles/P3130/32p30/32p30.asp&guid= http://www.processor.com/editorial/article.asp?article=artic...
dan_sim 16y ago
In fact, western civilization runs on the mainframe AND excel. As a consultant, I see a lot of both...
- mkr-hn 16y ago
  More broadly, western civilization runs on entrenched systems which no one has the will to replace. Sometimes it's easier to stick with what you know works than to try the newer thing, and that's probably the reasoning used by the people making the buying decisions.
  - ramchip 16y ago
    Why would Excel need to be replaced? It's good software.
    - cadr 16y ago
      It isn't so much Excel as it is spreadsheets in general. The cycle I've seen is that when a group starts out, they use Excel because it is a rapid tool that they understand. But then they keep building on that until they have a very complicated mess on which they are dependent. Spreadsheets don't tend to have good tools for testing and can be very brittle, so they end up slowing things down and causing problems. There are some interesting case studies here: http://www.eusprig.org http://www.eusprig.org
    - gchpaco 16y ago
      An argument can be made for replacing brittle, difficult to follow twisty spreadsheet programs (which is a lot of what people do with Excel that they can't do with anything else) with more conventional programs; maintainability benefits could be significant, just to pick one low lying fruit. But there's no money in it.
    - mkr-hn 16y ago
      I was talking more about mainframes than Excel. I also posted that before the thread was full of comments that changed my view on mainframes. As for Excel, I've read about a lot of situations where it's used for things it's not a good fit for, especially situations where a simple database and frontend might be more appropriate.
jacquesm 16y ago
> The mainframe software market is twice as big as the Linux market That's one hell of a compliment for Linux then.
- njharman 16y ago
  I came here to mention that was the most stunning bit of the article. Not the fact. But that someone is using the size of the Linux market to demonstrate how large mainframe's share is. I'm old and have lived through the growth of Linux. Starting as nothing, through all the FUD, and naysayer pudits, and claims it was communist, and MS many monopolistic attempts to squash it, etc. Comments like that still make my jaw drop.
  - hernan7 16y ago
    ... and we are talking about "market", that is about usage of Linux that involve exchange of money, no? So that's even more impressive.
yummyfajitas 16y ago
Obviously there is a business use case for mainframes, these can't all be legacy systems. But what is it? Can someone who has worked with such a system shed some light?
- gaius 16y ago
  1) If you need to do a lot of relatively simple things bloody quickly. There's nothing in the Unix world that can match the TPS of a mainframe. "Eventually consistent" just doesn't cut it for credit card auths. That is the real difference between mainframes and supercomputers. A supercomputer is about computation, a mainframe is about I/O. 2) Extreme reliability. There are mainframe clusters in production with a continual service availability for decades. Again, nothing in the Unix world can touch this.
  - rbranson 16y ago
    1) I refuse to believe banks and insurance companies have I/O that can't be satiated by commodity hardware. InfiniBand QDR can transfer 40Gbit/sec with 1µsec latency. That's easily 200,000 synchronous round-trip messages per second PER link. If you can deal with higher latency, those can be aggregated and you can easily exchange tens of millions per second. Let's take this one step further: ECNs and automated trading systems. Their latency and I/O requirements make banks look like amateurs, yet they almost entirely run on off-the-shelf hardware and systems. Billions are at stake in these systems. 2) When was the last time Google or Amazon or NASDAQ or Arca was actually out of service because of hardware failure or maintenance?
    - gaius 16y ago
      You have to compare like with like. A tickstream is more like writing to an in-memory ring buffer than it is to a database. Or a tick is like a UDP packet compared to an X400 email. Even the ECNs run their backoffices on mainframes. I would be willing to bet that Amazon do their warehouse and logistics operations on a mainframe too.
      - 16y ago
mseebach 16y ago
So that's a $6 billion profit for keeping western civilisation open for business? I'm not sure I'm buying the premise that that is somehow unreasonable.
- jacquesm 16y ago
  In fact, at that price it's cheap.
- ugh 16y ago
  I don’t think that’s the point of the article.
- Herring 16y ago
  You shouldn't buy that premise, because that's not what the article claimed was unreasonable.
ssp 16y ago
Fake Steve on mainframes: http://www.fakesteve.net/2009/10/why-ibm-is-in-trouble-with-antitrust.html http://www.fakesteve.net/2009/10/why-ibm-is-in-trouble-with-... http://www.fakesteve.net/2009/10/case-against-ibm-continued.html http://www.fakesteve.net/2009/10/case-against-ibm-continued....
- vdm 16y ago
  Priceless.
GavinB 16y ago
It's hard to think of it as a monopoly when the same services can be performed by a rack of servers running other software. For any type of data processing that mainframes perform, I'm sure you can find examples of similar jobs running in server farms. You can't define mainframes as a separate market just because they're physically large.
- jacquesm 16y ago
  The whole point is that you can't. > You could perform the same services by a rack of servers running OTHER software. But with the software that is there today the cost of re-writing it would be prohibitive and that's why the mainframe market is still as large as it is. It's nothing to do with them being physically large. Converting a couple of billions of lines of COBOL to something more modern, re-test the whole thing and add a bunch of magic to get the same kind of reliability is not a task any sane CTO at a bank or insurance company is going to sign off on.
  - sophacles 16y ago
    Not to mention, the system interface provided by mainframes has inherent failover capabilities. This means the cobol software is intentionally less robust in the "what happens if a part of the system fails" area, as that is something that rarely happens in a way that actually affects app level software.
    - wmf 16y ago
      I think people are assuming that if you ported your COBOL app to a cluster you'd use some kind of middleware that provides the same "inherent" reliability that the mainframe environment provides. The cost of such middleware is an open question.
- gaius 16y ago
  Well, this is kind of "the web is the whole of computing" mentality. You pick up the phone, you get a dial tone, not a fail whale. You put in a plug, you get electricity. When a bank's core systems go down, it makes the evening news. It's a whole 'nother world from OMG sharding RoR lol that web kids think is "scalability".
ronnier 16y ago
What does Eastern civilization run on?
- maukdaddy 16y ago
  Redframes.
  - deleted 16y ago
    [deleted]
  - chunkbot 16y ago
    This belongs on reddit.
jakevoytko 16y ago
There's no pressing reason for a company to toss its legacy mainframes. What VP would sign off on replacing core systems that run an international corporation? The downsides are infinite! I mean, are you insane? Just throw money at an "expensive" COBOL programmer and get out of my office! I grilled an employee at a Major Package Shipping Company a few years ago about their infrastructure, and it's pretty stereotypical: a few mainframes that were coded decades ago in COBOL and an expensive team of legacy programmers performing surgical tweaks. They're porting unimportant side systems to modern hardware + languages (ostensibly so the mainframe programmers can focus on the major systems), but there are no plans to replace the core. Ever. Replacement systems just aren't good enough to consider switching the heart of their company. And so it will continue until there's a compelling storyline for dropping mainframes
- mey 16y ago
  These corporations may not see it, because they do not understand it, but having such legacy systems a risk to their operations. The longer they wait to migrate, the more expensive it will be, and the harder it will be to attract talent to the project. There may come a point where they can no longer find anyone to support their hardware or software, and it'll force them to stagnate against their competition who may be able to provide better or different offerings because they are not tied to a system they can't modify. My understanding of business is that you should never stagnate, and always keep advancing. People that I've talked to who have worked with such systems indicated that they built giant shims around the systems in other languages to allow them to be adaptable. In theory this gives them a clear interface definition (it may be huge, thousands of method signatures, and possible direct schema access, but it can still be a clear interface) to boot strap a core system replacement in another language and hardware system.
  - jacquesm 16y ago
    The laws of supply and demand will make sure that there will always be people available to maintain those systems. The price will go up until some 'modern' programmer is tempted enough to open a 3 decades old book on COBOL and JCL. Your understanding of business is flawed, businesses are advancing by marketing, not by shacking up with every new hot tech that comes along in favour of their old, trusted and reliable tech. The larger, older and more profitable a business is the more likely that they are going to be ultra-conservative about using new technology at the core of their business. Eventually we'll get rid of this stuff but I wouldn't bet on it happening in the next two decades, unless someone finds a way to emulate a mainframe on a cluster with similar reliability. And then we still need to get rid of the software.
rbranson 16y ago
Anyone know why legacy mainframe software couldn't be emulated/compiled to run on a cluster of Linux boxes? Licensing, patents, legal concerns, etc? Obviously this is not a trivial issue, but it seems as if the amount of data we're talking about is not immense. Banks exchange and process large amounts of information, but how does it really compare to what people are doing with Hadoop or what Google does with MapReduce? I would imagine Google processes orders of magnitude more information than banks.
- gaius 16y ago
  The simple answer is that you have to have a consistent view of the world. Let's say that 100 Linux boxes in a cluster == 1 mainframe. Let's also say you're a bank. Someone connects to node 1 and makes a withdrawal from a joint account, and someone simultaneously makes a withdrawal from the same account on node 100. How do you check they haven't gone over their overdraft unless you can serialize those transactions? And if you can, and make it scale, congratulations: you're now where IBM was in the 70s'. It's pointless to invoke the almighty Google; they simply don't deal with problems in this class.
  - skalpelis 16y ago
    I know that Google Checkout isn't a "real" financial institution but surely, I'd think those problems were of the same class - perhaps it's just that they don't have to worry about legacy problems (yet).
    - gaius 16y ago
      Google Checkout backs onto a payment processing gateway. Google isn't a bank!
  - rbranson 16y ago
    Banks are actually kind of a bad example for needing synchronized processing. Banks settle transactions pseudo-asynchronously in batches. While they adjust your "available balance" as well as they can, AFAIK, transactions are officially settled in the old school, nightly batch. Even then, there are consistent, synchronous databases that run on Linux clusters. Oracle RAC and Sybase ASE come to mind. Linux also supports hardware NUMA implementations, which allow single system image software. An emulation layer could run on top of NUMA hardware.
masterponomo 16y ago
As a 25-year professional z/os programmer working primarily in COBOL and CICS, I think the dearth of new COBOL programmers is not the big problem it is made out to be. Having learned C, Java, SQL, Common Lisp, and Scheme on my own, I have no doubt that programmers will jump to COBOL when the marketplace starts offering rewards (higher salaries) for doing so. The outsourcing trend is holding this back as companies continue to pursue the holy grail of cheap programmers, but all such efforts eventually run afoul of the need for local talent with a deep understanding of the application. A good programmer can get up to speed on COBOL very quickly. Getting up to speed on a large application? That'll take a few years. The problem with legacy apps on any platform is not the language (unless you're talking about some very obscure unsupported language). The problem in my experience is the tangled mess of new code piled on top of poorly designed old code. In such systems, a small change can have unintended side effects. The solution is exhaustive testing (expensive and time-consuming) or a Hail Mary installation (leading to "testing" in production and yet another reactive fix). COBOL didn't create this problem and changing to another language won't fix it. In my shop, we practice test-driven development and deliver high quality releases. Success on the receiving end of these releases varies along with the established coding/testing/integration practices at each customer site.
- thaumaturgy 16y ago
  True, except that a lot of programmers want to follow the "sexy" technology, and COBOL just ain't that.
  - pavel_lishin 16y ago
    It's amazing how sexy technology can get when someone's offering you a six or seven figure salary to figure it out.
    - thaumaturgy 16y ago
      Really? Because I keep seeing articles on HN about how employees can't be motivated by pay increases, they have to be motivated by things like appreciating their work, sense of accomplishment, etc. etc. Both of these things can't be true!
rythie 16y ago
Essentially people are locked into those mainframes. It doesn't make sense to pick them if you are starting from scratch. I wonder if in 20 years people will be locked into the cloud systems they are investing in now in the same way.
SwellJoe 16y ago
This article makes me want to buy some IBM stock. But, it's never performed very well...
- Kadin 16y ago
  Well, it's mostly factored into the price; IBM's mainframe division isn't that big a secret. But like most "blue chips", IBM is probably a reasonably solid income stock. They have an obvious income stream (software licensing) with a locked-in market, in addition to their consulting/services divisions. Whether or not it's too much to pay for the income (compared to similar companies with license-based revenue models, i.e. Microsoft) is the question for a potential investor. I'm not sure anyone would regard it as a hot speculative play...
zandorg 16y ago
IBM also makes a lot from their consulting (human mainframes).
gritzko 16y ago
Well, a friend of mine writes software for mainframes. Says, the platform has two advantages: customers are totally locked in and there are enormous possibilities for kickbacks (no market => no fair price => case-by-case pricing => guess what) Otherwise, the technology is totally inferior, compared to anything.
stralep 16y ago
Should I learn COBOL 2002, or some earlier version? Are mainframes COBOL standard compliant? Is there free standard document?
unohoo 16y ago
One of my friends who works on a Z mainframe told me that the last time their mainframe was 'rebooted' was about 4 years ago. Hows that for downtime ?
rbranson 16y ago
This only works if you exclude the entirety of commodity and stock exchange business, which runs almost completely on off-the-shelf hardware. I'd say this is a pretty big part of western civilization. Of course, the I/O requirements of these systems massively eclipse that of "puny" banks, logistics/distribution, manufacturing, and insurance companies.
herdrick 16y ago
There are estimates that 80% of the world's data are processed by mainframes. Pretty clueless estimates I'd have to think.
jeberle 16y ago
Mainframes are very good at their jobs. Where do you think virtual machines, NoSQL databases, SQL databases, etc., got their start -- about 40 years ago? http://en.wikipedia.org/wiki/VM_(operating_system) http://en.wikipedia.org/wiki/VM_(operating_system) http://en.wikipedia.org/wiki/VSAM http://en.wikipedia.org/wiki/VSAM http://en.wikipedia.org/wiki/IBM_System_R http://en.wikipedia.org/wiki/IBM_System_R Page at a time remote interfaces anyone?

154 points by a2tech 16y ago

"According to Maclean, comparing mainframe performance against, say, Oracle running on an x86 server platform may yield similar results in a low usage scenario. However, a mainframe will prove its value as that application set scales up in volume. The difference isn’t in the CPU, which (in non-IBM cases) is the same on both sides of the comparison. Rather, the difference is in the architecture of the operating environment." http://www.processor.com/editorial/article.asp?article=articles/P3130/32p30/32p30.asp&guid= http://www.processor.com/editorial/article.asp?article=artic...

dan_sim 16y ago

In fact, western civilization runs on the mainframe AND excel. As a consultant, I see a lot of both...

mkr-hn 16y ago
More broadly, western civilization runs on entrenched systems which no one has the will to replace. Sometimes it's easier to stick with what you know works than to try the newer thing, and that's probably the reasoning used by the people making the buying decisions.
- ramchip 16y ago
  Why would Excel need to be replaced? It's good software.
  - cadr 16y ago
    It isn't so much Excel as it is spreadsheets in general. The cycle I've seen is that when a group starts out, they use Excel because it is a rapid tool that they understand. But then they keep building on that until they have a very complicated mess on which they are dependent. Spreadsheets don't tend to have good tools for testing and can be very brittle, so they end up slowing things down and causing problems. There are some interesting case studies here: http://www.eusprig.org http://www.eusprig.org
  - gchpaco 16y ago
    An argument can be made for replacing brittle, difficult to follow twisty spreadsheet programs (which is a lot of what people do with Excel that they can't do with anything else) with more conventional programs; maintainability benefits could be significant, just to pick one low lying fruit. But there's no money in it.
  - mkr-hn 16y ago
    I was talking more about mainframes than Excel. I also posted that before the thread was full of comments that changed my view on mainframes. As for Excel, I've read about a lot of situations where it's used for things it's not a good fit for, especially situations where a simple database and frontend might be more appropriate.

jacquesm 16y ago

> The mainframe software market is twice as big as the Linux market That's one hell of a compliment for Linux then.

njharman 16y ago
I came here to mention that was the most stunning bit of the article. Not the fact. But that someone is using the size of the Linux market to demonstrate how large mainframe's share is. I'm old and have lived through the growth of Linux. Starting as nothing, through all the FUD, and naysayer pudits, and claims it was communist, and MS many monopolistic attempts to squash it, etc. Comments like that still make my jaw drop.
- hernan7 16y ago
  ... and we are talking about "market", that is about usage of Linux that involve exchange of money, no? So that's even more impressive.

yummyfajitas 16y ago

Obviously there is a business use case for mainframes, these can't all be legacy systems. But what is it? Can someone who has worked with such a system shed some light?

gaius 16y ago
1) If you need to do a lot of relatively simple things bloody quickly. There's nothing in the Unix world that can match the TPS of a mainframe. "Eventually consistent" just doesn't cut it for credit card auths. That is the real difference between mainframes and supercomputers. A supercomputer is about computation, a mainframe is about I/O. 2) Extreme reliability. There are mainframe clusters in production with a continual service availability for decades. Again, nothing in the Unix world can touch this.
- rbranson 16y ago
  1) I refuse to believe banks and insurance companies have I/O that can't be satiated by commodity hardware. InfiniBand QDR can transfer 40Gbit/sec with 1µsec latency. That's easily 200,000 synchronous round-trip messages per second PER link. If you can deal with higher latency, those can be aggregated and you can easily exchange tens of millions per second. Let's take this one step further: ECNs and automated trading systems. Their latency and I/O requirements make banks look like amateurs, yet they almost entirely run on off-the-shelf hardware and systems. Billions are at stake in these systems. 2) When was the last time Google or Amazon or NASDAQ or Arca was actually out of service because of hardware failure or maintenance?
  - gaius 16y ago
    You have to compare like with like. A tickstream is more like writing to an in-memory ring buffer than it is to a database. Or a tick is like a UDP packet compared to an X400 email. Even the ECNs run their backoffices on mainframes. I would be willing to bet that Amazon do their warehouse and logistics operations on a mainframe too.
    - 16y ago

mseebach 16y ago

So that's a $6 billion profit for keeping western civilisation open for business? I'm not sure I'm buying the premise that that is somehow unreasonable.

jacquesm 16y ago
In fact, at that price it's cheap.
ugh 16y ago
I don’t think that’s the point of the article.
Herring 16y ago
You shouldn't buy that premise, because that's not what the article claimed was unreasonable.

ssp 16y ago

Fake Steve on mainframes: http://www.fakesteve.net/2009/10/why-ibm-is-in-trouble-with-antitrust.html http://www.fakesteve.net/2009/10/why-ibm-is-in-trouble-with-... http://www.fakesteve.net/2009/10/case-against-ibm-continued.html http://www.fakesteve.net/2009/10/case-against-ibm-continued....

vdm 16y ago
Priceless.

GavinB 16y ago

It's hard to think of it as a monopoly when the same services can be performed by a rack of servers running other software. For any type of data processing that mainframes perform, I'm sure you can find examples of similar jobs running in server farms. You can't define mainframes as a separate market just because they're physically large.

jacquesm 16y ago
The whole point is that you can't. > You could perform the same services by a rack of servers running OTHER software. But with the software that is there today the cost of re-writing it would be prohibitive and that's why the mainframe market is still as large as it is. It's nothing to do with them being physically large. Converting a couple of billions of lines of COBOL to something more modern, re-test the whole thing and add a bunch of magic to get the same kind of reliability is not a task any sane CTO at a bank or insurance company is going to sign off on.
- sophacles 16y ago
  Not to mention, the system interface provided by mainframes has inherent failover capabilities. This means the cobol software is intentionally less robust in the "what happens if a part of the system fails" area, as that is something that rarely happens in a way that actually affects app level software.
  - wmf 16y ago
    I think people are assuming that if you ported your COBOL app to a cluster you'd use some kind of middleware that provides the same "inherent" reliability that the mainframe environment provides. The cost of such middleware is an open question.
gaius 16y ago
Well, this is kind of "the web is the whole of computing" mentality. You pick up the phone, you get a dial tone, not a fail whale. You put in a plug, you get electricity. When a bank's core systems go down, it makes the evening news. It's a whole 'nother world from OMG sharding RoR lol that web kids think is "scalability".

ronnier 16y ago

What does Eastern civilization run on?

maukdaddy 16y ago
Redframes.
- deleted 16y ago
  [deleted]
- chunkbot 16y ago
  This belongs on reddit.

jakevoytko 16y ago

There's no pressing reason for a company to toss its legacy mainframes. What VP would sign off on replacing core systems that run an international corporation? The downsides are infinite! I mean, are you insane? Just throw money at an "expensive" COBOL programmer and get out of my office! I grilled an employee at a Major Package Shipping Company a few years ago about their infrastructure, and it's pretty stereotypical: a few mainframes that were coded decades ago in COBOL and an expensive team of legacy programmers performing surgical tweaks. They're porting unimportant side systems to modern hardware + languages (ostensibly so the mainframe programmers can focus on the major systems), but there are no plans to replace the core. Ever. Replacement systems just aren't good enough to consider switching the heart of their company. And so it will continue until there's a compelling storyline for dropping mainframes

mey 16y ago
These corporations may not see it, because they do not understand it, but having such legacy systems a risk to their operations. The longer they wait to migrate, the more expensive it will be, and the harder it will be to attract talent to the project. There may come a point where they can no longer find anyone to support their hardware or software, and it'll force them to stagnate against their competition who may be able to provide better or different offerings because they are not tied to a system they can't modify. My understanding of business is that you should never stagnate, and always keep advancing. People that I've talked to who have worked with such systems indicated that they built giant shims around the systems in other languages to allow them to be adaptable. In theory this gives them a clear interface definition (it may be huge, thousands of method signatures, and possible direct schema access, but it can still be a clear interface) to boot strap a core system replacement in another language and hardware system.
- jacquesm 16y ago
  The laws of supply and demand will make sure that there will always be people available to maintain those systems. The price will go up until some 'modern' programmer is tempted enough to open a 3 decades old book on COBOL and JCL. Your understanding of business is flawed, businesses are advancing by marketing, not by shacking up with every new hot tech that comes along in favour of their old, trusted and reliable tech. The larger, older and more profitable a business is the more likely that they are going to be ultra-conservative about using new technology at the core of their business. Eventually we'll get rid of this stuff but I wouldn't bet on it happening in the next two decades, unless someone finds a way to emulate a mainframe on a cluster with similar reliability. And then we still need to get rid of the software.

rbranson 16y ago

Anyone know why legacy mainframe software couldn't be emulated/compiled to run on a cluster of Linux boxes? Licensing, patents, legal concerns, etc? Obviously this is not a trivial issue, but it seems as if the amount of data we're talking about is not immense. Banks exchange and process large amounts of information, but how does it really compare to what people are doing with Hadoop or what Google does with MapReduce? I would imagine Google processes orders of magnitude more information than banks.

gaius 16y ago
The simple answer is that you have to have a consistent view of the world. Let's say that 100 Linux boxes in a cluster == 1 mainframe. Let's also say you're a bank. Someone connects to node 1 and makes a withdrawal from a joint account, and someone simultaneously makes a withdrawal from the same account on node 100. How do you check they haven't gone over their overdraft unless you can serialize those transactions? And if you can, and make it scale, congratulations: you're now where IBM was in the 70s'. It's pointless to invoke the almighty Google; they simply don't deal with problems in this class.
- skalpelis 16y ago
  I know that Google Checkout isn't a "real" financial institution but surely, I'd think those problems were of the same class - perhaps it's just that they don't have to worry about legacy problems (yet).
  - gaius 16y ago
    Google Checkout backs onto a payment processing gateway. Google isn't a bank!
- rbranson 16y ago
  Banks are actually kind of a bad example for needing synchronized processing. Banks settle transactions pseudo-asynchronously in batches. While they adjust your "available balance" as well as they can, AFAIK, transactions are officially settled in the old school, nightly batch. Even then, there are consistent, synchronous databases that run on Linux clusters. Oracle RAC and Sybase ASE come to mind. Linux also supports hardware NUMA implementations, which allow single system image software. An emulation layer could run on top of NUMA hardware.

masterponomo 16y ago

As a 25-year professional z/os programmer working primarily in COBOL and CICS, I think the dearth of new COBOL programmers is not the big problem it is made out to be. Having learned C, Java, SQL, Common Lisp, and Scheme on my own, I have no doubt that programmers will jump to COBOL when the marketplace starts offering rewards (higher salaries) for doing so. The outsourcing trend is holding this back as companies continue to pursue the holy grail of cheap programmers, but all such efforts eventually run afoul of the need for local talent with a deep understanding of the application. A good programmer can get up to speed on COBOL very quickly. Getting up to speed on a large application? That'll take a few years. The problem with legacy apps on any platform is not the language (unless you're talking about some very obscure unsupported language). The problem in my experience is the tangled mess of new code piled on top of poorly designed old code. In such systems, a small change can have unintended side effects. The solution is exhaustive testing (expensive and time-consuming) or a Hail Mary installation (leading to "testing" in production and yet another reactive fix). COBOL didn't create this problem and changing to another language won't fix it. In my shop, we practice test-driven development and deliver high quality releases. Success on the receiving end of these releases varies along with the established coding/testing/integration practices at each customer site.

thaumaturgy 16y ago
True, except that a lot of programmers want to follow the "sexy" technology, and COBOL just ain't that.
- pavel_lishin 16y ago
  It's amazing how sexy technology can get when someone's offering you a six or seven figure salary to figure it out.
  - thaumaturgy 16y ago
    Really? Because I keep seeing articles on HN about how employees can't be motivated by pay increases, they have to be motivated by things like appreciating their work, sense of accomplishment, etc. etc. Both of these things can't be true!

rythie 16y ago

Essentially people are locked into those mainframes. It doesn't make sense to pick them if you are starting from scratch. I wonder if in 20 years people will be locked into the cloud systems they are investing in now in the same way.

SwellJoe 16y ago

This article makes me want to buy some IBM stock. But, it's never performed very well...

Kadin 16y ago
Well, it's mostly factored into the price; IBM's mainframe division isn't that big a secret. But like most "blue chips", IBM is probably a reasonably solid income stock. They have an obvious income stream (software licensing) with a locked-in market, in addition to their consulting/services divisions. Whether or not it's too much to pay for the income (compared to similar companies with license-based revenue models, i.e. Microsoft) is the question for a potential investor. I'm not sure anyone would regard it as a hot speculative play...

zandorg 16y ago

IBM also makes a lot from their consulting (human mainframes).

gritzko 16y ago

Well, a friend of mine writes software for mainframes. Says, the platform has two advantages: customers are totally locked in and there are enormous possibilities for kickbacks (no market => no fair price => case-by-case pricing => guess what) Otherwise, the technology is totally inferior, compared to anything.

stralep 16y ago

Should I learn COBOL 2002, or some earlier version? Are mainframes COBOL standard compliant? Is there free standard document?

unohoo 16y ago

One of my friends who works on a Z mainframe told me that the last time their mainframe was 'rebooted' was about 4 years ago. Hows that for downtime ?

rbranson 16y ago

This only works if you exclude the entirety of commodity and stock exchange business, which runs almost completely on off-the-shelf hardware. I'd say this is a pretty big part of western civilization. Of course, the I/O requirements of these systems massively eclipse that of "puny" banks, logistics/distribution, manufacturing, and insurance companies.

herdrick 16y ago

There are estimates that 80% of the world's data are processed by mainframes. Pretty clueless estimates I'd have to think.

jeberle 16y ago

Mainframes are very good at their jobs. Where do you think virtual machines, NoSQL databases, SQL databases, etc., got their start -- about 40 years ago? http://en.wikipedia.org/wiki/VM_(operating_system) http://en.wikipedia.org/wiki/VM_(operating_system) http://en.wikipedia.org/wiki/VSAM http://en.wikipedia.org/wiki/VSAM http://en.wikipedia.org/wiki/IBM_System_R http://en.wikipedia.org/wiki/IBM_System_R Page at a time remote interfaces anyone?