6 ms·

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 t

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.
  - gaius 16y ago
    I am very experienced with RAC and its predecessor OPS. It really is nowhere near as performant or reliable or scalable or manageable as a mainframe. Which is not to say it's not "good enough" for many serious, real-world workloads, of course it is. But you're comparing a Toyota pickup to a JCB earthmover.
    - rbranson 16y ago
      I'll definitely yield to your experience. What exactly makes the mainframes so much more capable? How does it compare to something like an SGI Altix cluster with 2048-core / 16TB single system image capacity?
      - gaius 16y ago
        The mainframe is built from the ground up for transaction processing. Have a look around Wikipedia for terms like: CICS, IMS, TPF, Sysplex, WLM. Everything, the hardware, the kernel, the rest of the OS, the programming model, the languages - all for this. It has no pretence of being a general-purpose computing platform. The mainframe would suck for what you'd use the Altix for, e.g. weather forecasting. The Altix has a lot of processes that want to work on a common dataset, but it would grind to a halt if you tried to use its interconnect to serialize transactions.
        rbranson 16y ago
        Exactly what makes it so much more useful for transaction processing? I'm looking at these things you suggested, but how does CICS compare to something like BEA Tuxedo? Of course there are no benchmarks or talk of performance out in the open on the web because I'm sure their licensing agreements forbid that. Do mainframes have some kind of crazy low-latency or high bandwidth bus that something like the Altix is missing? It appears they use similar hardware architectures, at least from a high level: super high speed modular backplanes with blade servers that form a single system image. The NUMALink 5 is stated as having 15GB/s of bandwidth (7.5GB/s in each direction) with a ~1µsec latency.
- jtbigwoo 16y ago
  > It's pointless to invoke the almighty Google; they simply don't deal with problems in this class FWIW, I worked at a major bank (top 5 in the U.S.) and listened in on several discussions between their top tech guys. As mentioned in other comments, their number one worry was the supply of COBOL coders. They were terrified of Google and/or Paypal and what would happen if one of those companies got serious about competing in the banking arena. Most of the top architects _knew_ that it was possible to build a bank on a huge cluster of servers. They also knew that there was no way an existing bank could build the infrastructure and software while also maintaining their existing infrastructure.
  - rbranson 16y ago
    Apparently PayPal isn't in technologically fantastic shape either. Word on the street is that they still have their core offering written in C using a CGI interface.
    - jff 16y ago
      C? I guess that only puts them 30 years ahead of the banks, then...
    - Shorel 16y ago
      With good unit testing C is very robust and also much cheaper in hardware footprint.
      - rbranson 16y ago
        I wasn't as much bashing C as I was the use of CGI. Most of the time when C is paired with CGI it's a pretty good indication that the code is chock full of memory leaks.
        a-priori 16y ago
        If you are using CGI, then those memory leaks will be short lived, limited to one request.
LaPingvino 16y ago
There is actually mainframe emulation, it can certainly be done. However, IBM is doing everything to keep that unattractive and with a bad image.
- rbranson 16y ago
  I suppose what I'm talking about is a company with real biz clout (like HP) coming up with a solution to compete with IBM.
masterponomo 16y ago
Not sure about running on Linux, but there are COBOL and CICS systems that run on small servers. In fact there are a whole range of mainframe-like machines (e.g. AS/400) from IBM, to support different size businesses. The amount of data in some applications IS immense. If you are managing a multi-million-account credit card portfolio on a single mainframe, which nicely supports all your realtime apps (including a 100-request per second authorizations system) and your 6-hour batch cycle, there is no reason at all to port that to smaller machines. The mainframe is marvelously stable and nowadays the whole machine rarely gets hung up (I haven't seen or heard of this happening to my company or its customers since the early 90's). Sure, you could move those apps to a bunch of smaller boxes. Then you open yourself up to server failure, admin costs of maintaining multiple boxes, etc. Mainframes wrote the book on SaaS long before 'net cloud computing came along. IBM and others have operated computing as a utility for years and years. What manager who gets his IT done on rented computer time is going to suggest taking the apps in-house on a bunch of servers? None that I know of.
Hoff 16y ago
There can be substantial differences among what's technically feasible and what's economically feasible and what's politically feasible. An existing environment is usually a large pile of twisty dependencies on operating system calls, on database or file formats that aren't entirely portable, on language extensions that don't exist elsewhere, on objects built from source code that's been lost, on dependencies on products from vendors that no longer exist, and it's all often inextricably linked with front-ends that would have to be rewritten, data bridges that would have to be rewritten, and users that need to be retrained. In some cases, this effort can involve re-architecting substantial parts of a manufacturing facility that's involving six or ten buildings and that are each most of a kilometer long. And with many industrial-scale environments, change is not going to happen. You (might) see a new environment implemented when the entire production line is nuked and paved at the end of its useful lifetime, and replaced with a newly-deployed production line. In other cases, you'll probably see the existing system patched and re-used. For many of these cases, just ramping up a load test would be a substantial effort. Some hunks of the environment will have test cases and specs and documentation, and some hunks probably won't. For many of these installations, substantial downtime has SEC-level visibility, or can involve exposures to various legal entanglements, or can involve re-establishing politically- or legall-mandated external certifications, or can cost thousands or millions of dollars per unit time off-line, or requires the production line to be cleaned with a jack-hammer or entirely replaced, or other issues. If you can afford an incremental port or a big-bang port, well, what's that cost in comparison with the incremental costs of keeping the existing environment going? C-level folks just don't blindly sign the really big bills involved in keeping these environments going, and most competing vendors seeking to acquire least part of these mainframe-scale budgets.
vl 16y ago
Any large distributed system barely runs on the specific hardware/OS it was designed for and required constant monitoring and maintenance. Even OS upgrade (i.e. in theory it should stay compatible and "just work") in the large datacenter takes weeks of testing and fixing. Migrating from mainframe to linux is very very very expensive. On top of that to achieve same reliability there will be a need to re-architect some software pieces. BTW, Google needs with MapReduce are fundamentally different - it favors scalability and thoughput over correcteness vs banks that need distributed transaction consistency most of all.

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.
- gaius 16y ago
  I am very experienced with RAC and its predecessor OPS. It really is nowhere near as performant or reliable or scalable or manageable as a mainframe. Which is not to say it's not "good enough" for many serious, real-world workloads, of course it is. But you're comparing a Toyota pickup to a JCB earthmover.
  - rbranson 16y ago
    I'll definitely yield to your experience. What exactly makes the mainframes so much more capable? How does it compare to something like an SGI Altix cluster with 2048-core / 16TB single system image capacity?
    - gaius 16y ago
      The mainframe is built from the ground up for transaction processing. Have a look around Wikipedia for terms like: CICS, IMS, TPF, Sysplex, WLM. Everything, the hardware, the kernel, the rest of the OS, the programming model, the languages - all for this. It has no pretence of being a general-purpose computing platform. The mainframe would suck for what you'd use the Altix for, e.g. weather forecasting. The Altix has a lot of processes that want to work on a common dataset, but it would grind to a halt if you tried to use its interconnect to serialize transactions.
      - rbranson 16y ago
        Exactly what makes it so much more useful for transaction processing? I'm looking at these things you suggested, but how does CICS compare to something like BEA Tuxedo? Of course there are no benchmarks or talk of performance out in the open on the web because I'm sure their licensing agreements forbid that. Do mainframes have some kind of crazy low-latency or high bandwidth bus that something like the Altix is missing? It appears they use similar hardware architectures, at least from a high level: super high speed modular backplanes with blade servers that form a single system image. The NUMALink 5 is stated as having 15GB/s of bandwidth (7.5GB/s in each direction) with a ~1µsec latency.
jtbigwoo 16y ago
> It's pointless to invoke the almighty Google; they simply don't deal with problems in this class FWIW, I worked at a major bank (top 5 in the U.S.) and listened in on several discussions between their top tech guys. As mentioned in other comments, their number one worry was the supply of COBOL coders. They were terrified of Google and/or Paypal and what would happen if one of those companies got serious about competing in the banking arena. Most of the top architects _knew_ that it was possible to build a bank on a huge cluster of servers. They also knew that there was no way an existing bank could build the infrastructure and software while also maintaining their existing infrastructure.
- rbranson 16y ago
  Apparently PayPal isn't in technologically fantastic shape either. Word on the street is that they still have their core offering written in C using a CGI interface.
  - jff 16y ago
    C? I guess that only puts them 30 years ahead of the banks, then...
  - Shorel 16y ago
    With good unit testing C is very robust and also much cheaper in hardware footprint.
    - rbranson 16y ago
      I wasn't as much bashing C as I was the use of CGI. Most of the time when C is paired with CGI it's a pretty good indication that the code is chock full of memory leaks.
      - a-priori 16y ago
        If you are using CGI, then those memory leaks will be short lived, limited to one request.

LaPingvino 16y ago

There is actually mainframe emulation, it can certainly be done. However, IBM is doing everything to keep that unattractive and with a bad image.

rbranson 16y ago
I suppose what I'm talking about is a company with real biz clout (like HP) coming up with a solution to compete with IBM.

masterponomo 16y ago

Not sure about running on Linux, but there are COBOL and CICS systems that run on small servers. In fact there are a whole range of mainframe-like machines (e.g. AS/400) from IBM, to support different size businesses. The amount of data in some applications IS immense. If you are managing a multi-million-account credit card portfolio on a single mainframe, which nicely supports all your realtime apps (including a 100-request per second authorizations system) and your 6-hour batch cycle, there is no reason at all to port that to smaller machines. The mainframe is marvelously stable and nowadays the whole machine rarely gets hung up (I haven't seen or heard of this happening to my company or its customers since the early 90's). Sure, you could move those apps to a bunch of smaller boxes. Then you open yourself up to server failure, admin costs of maintaining multiple boxes, etc. Mainframes wrote the book on SaaS long before 'net cloud computing came along. IBM and others have operated computing as a utility for years and years. What manager who gets his IT done on rented computer time is going to suggest taking the apps in-house on a bunch of servers? None that I know of.

Hoff 16y ago

There can be substantial differences among what's technically feasible and what's economically feasible and what's politically feasible. An existing environment is usually a large pile of twisty dependencies on operating system calls, on database or file formats that aren't entirely portable, on language extensions that don't exist elsewhere, on objects built from source code that's been lost, on dependencies on products from vendors that no longer exist, and it's all often inextricably linked with front-ends that would have to be rewritten, data bridges that would have to be rewritten, and users that need to be retrained. In some cases, this effort can involve re-architecting substantial parts of a manufacturing facility that's involving six or ten buildings and that are each most of a kilometer long. And with many industrial-scale environments, change is not going to happen. You (might) see a new environment implemented when the entire production line is nuked and paved at the end of its useful lifetime, and replaced with a newly-deployed production line. In other cases, you'll probably see the existing system patched and re-used. For many of these cases, just ramping up a load test would be a substantial effort. Some hunks of the environment will have test cases and specs and documentation, and some hunks probably won't. For many of these installations, substantial downtime has SEC-level visibility, or can involve exposures to various legal entanglements, or can involve re-establishing politically- or legall-mandated external certifications, or can cost thousands or millions of dollars per unit time off-line, or requires the production line to be cleaned with a jack-hammer or entirely replaced, or other issues. If you can afford an incremental port or a big-bang port, well, what's that cost in comparison with the incremental costs of keeping the existing environment going? C-level folks just don't blindly sign the really big bills involved in keeping these environments going, and most competing vendors seeking to acquire least part of these mainframe-scale budgets.

vl 16y ago

Any large distributed system barely runs on the specific hardware/OS it was designed for and required constant monitoring and maintenance. Even OS upgrade (i.e. in theory it should stay compatible and "just work") in the large datacenter takes weeks of testing and fixing. Migrating from mainframe to linux is very very very expensive. On top of that to achieve same reliability there will be a need to re-architect some software pieces. BTW, Google needs with MapReduce are fundamentally different - it favors scalability and thoughput over correcteness vs banks that need distributed transaction consistency most of all.