5 ms·

Can confirm. The last two clients I worked with (both Fortune 500) used mainframes for business critical operations. The most recent one didn't actually have

Can confirm. The last two clients I worked with (both Fortune 500) used mainframes for business critical operations. The most recent one didn't actually have source for some components of their business ops software stack - they've just been working as-is for about 30 years and no one will touch them. I was told they did an assessment a year or two ago to price out what it would take to move the business completely off mainframe and onto an x86 stack. It was in the hundreds of millions of dollars to do so because so much other software has been built to interact with and rely on the mainframe over the years that switching off it would be a multi-year effort across every department in the company. So of course that ROI calculation was pretty damn easy and the mainframe isn't going anywhere.

benj111 7y ago
If you were dependent, to the tune of 100s of millions of $ on certain hardware, wouldn't it make sense to start the process anyway? You don't necessarily need to move the $new project off the legacy hardware, just write it in such a way that you can do easily later. I'm eliding many details here, but the principle stands.
- mdorazio 7y ago
  Not as long as IBM continues to make mainframes and components, which they do. If you were unable to source replacement hardware to keep it running indefinitely, then yes, but until then it's better to keep paying a couple million a year to keep your business running as-is than to spend hundreds of millions to effectively rebuild the entire infrastructure from the ground up in parallel to the running infrastructure. Remember that these are large, public businesses. Explaining to shareholders that profits are going to take a noticeable hit for years because of IT investment that isn't strictly necessary is effectively a non-starter.
  - benj111 7y ago
    "rebuild the entire infrastructure from the ground up in parallel" I wasn't thinking that. I was thinking more like when you add a new feature, fit it into an API that is portable. Or add a translation layer so the feature can be written how you would like system to be in the future, but it works on your hardware today.
    - wahern 7y ago
      Everybody attempts this. But the problem is that the ground keeps moving under your feet. Your portable interfaces become irrelevant as software systems evolve. XML gives way to JSON, etc. Eventually it costs just as much in time and effort to interoperate with your 10-20 year old "portable" interface as it would to interface with the mainframe directly, which was already established to have been too costly to bother. So now you have two problems, not just one.
      - benj111 7y ago
        Possibly. First I'd say that xml doesn't become 'wrong' when json came about. If that 1950s data format works for you, and you don't see advantages to moving, then fine stay with it. 2nd I'd say theres a half life of best practise. Over the 10 20 year tome frame, id expect some of what you were doing is going to become outdated yes, on the same way some of your knowledge over your career will become outdated, or the phone I your pocket will, you wouldn't use that as an argument against education, or buying that phone. Btw, if its as costly to deal with the interface as with the mainframe directly, that's a win. The interface can move off the mainframe to somewhere cheaper/better.
        wahern 7y ago
        > First I'd say that xml doesn't become 'wrong' when json came about. It doesn't become wrong, it just evolves into another dead-end. The 3270 is an interface, too, but the reason everybody suggests replacing it or augmenting it is precisely because the spartan tooling and mindshare makes it expensive. As XML recedes into history it is likewise becoming more expensive as an interface. I chose XML vs JSON because I figured it was a transition everybody was somewhat familiar with. And younger programmers have an almost visceral dislike of XML, which I thought might help get the point across--that an interface someone once thought (and probably still thinks) would help ease future interoperability becomes a reason or excuse for future programmers to avoid that integration. > Btw, if its as costly to deal with the interface as with the mainframe directly, that's a win. I think the problem is that you don't really know if it's as costly. The error bars on that sort of risk assessment are huge because our industry sucks at accurately predicting migration costs. And it sucks because complex software systems are intrinsically unique. Commercial solutions that claim to be able to capture and control all those dimensions of complexity tend to be sold by vendors with names like IBM and Oracle. Such vendors also pioneered interfaces like SQL, which is both a soaring achievement in terms of capturing complexity behind a beautiful interface while also falling epically short of what's needed to actually reduce long-term integration costs.
- reaperducer 7y ago
  Choose one: - Spend $300,000,000 over 10 years moving to a new system, and hope that by the time you've done that it's not obsolete. - Spend $1,000,000 a year on a system that still works. You could run the system for 300 years for what it would cost to replace the system. In spite of the collective wisdom on HN, there aren't a lot of companies in the world with hundreds of millions of dollars sitting around doing nothing. Even ones that work on mainframes.
  - SomeOldThrow 7y ago
    What’s the meaning of those numbers? Where did they come from? How did you lose the source to a 300 million dollar software project? If anything, this is a sign that mainframe users have way too much profit for what should probably be commodity software.
  - benj111 7y ago
    I would characterise it as option 3 - Spend $1.5 million maintaining the current system, but as bits get updated keep in mind the system that you'd like to have in 10 15 years time. You're going to have to replace the system within 300 years anyway, you aren't saving that money, every feature you add that is reliant on the old system is literally technical debt, because eventually you'll have to rewrite it for the new system. I'm not even saying you need to have a new system in mind, just keep in mind that you will be moving to a new system, so code appropriately.
    - rbanffy 7y ago
      Since a mainframe can usually be updated to the newest model (and you often run more than one for redundancy, as some people may need more than 5 nines), in 300 years the company will have a z150 or so, with millions of quantum entangled cores made of folded spacetime mesh around a pair of rotating singularities running at a couple terahertz. And it will still be able to run all your programs that were written and tested since the late 20th century, by the kind of organic entity we used to call "human".
      - 7y ago
- berti 7y ago
  You seem to have made an assumption that the mainframe is “legacy hardware”, on a thread about the latest generation of mainframe hardware... As long as IBM keeps building mainframes the business case for anything else will remain unattractive. Unless you have some information to the contrary, it doesn’t make a lot of sense to invest (financially or technically) in switching.
  - benj111 7y ago
    It isn't about legacy, it's about being stuck on one suppliers hardware. That isn't a great place to be.
derefr 7y ago
> so much other software has been built to interact with and rely on the mainframe over the years So just... have the new server expose itself over the TN3270/TN5250 protocols, such that these interoperating systems see what they expect to see? (You could even build the new system as a regular REST API or something at its core, and then build the TN3270/TN5250 exposure as a separate gateway service on top, such that it'd be easy to shut it off later if everything finally moves off it one day.)
- schnable 7y ago
  Just?
- tyingq 7y ago
  That's one of many possible integration points. LU6.2, SNA, batch file transfers, remote DB2 connections, MQ queues, etc.

benj111 7y ago

If you were dependent, to the tune of 100s of millions of $ on certain hardware, wouldn't it make sense to start the process anyway? You don't necessarily need to move the $new project off the legacy hardware, just write it in such a way that you can do easily later. I'm eliding many details here, but the principle stands.

mdorazio 7y ago
Not as long as IBM continues to make mainframes and components, which they do. If you were unable to source replacement hardware to keep it running indefinitely, then yes, but until then it's better to keep paying a couple million a year to keep your business running as-is than to spend hundreds of millions to effectively rebuild the entire infrastructure from the ground up in parallel to the running infrastructure. Remember that these are large, public businesses. Explaining to shareholders that profits are going to take a noticeable hit for years because of IT investment that isn't strictly necessary is effectively a non-starter.
- benj111 7y ago
  "rebuild the entire infrastructure from the ground up in parallel" I wasn't thinking that. I was thinking more like when you add a new feature, fit it into an API that is portable. Or add a translation layer so the feature can be written how you would like system to be in the future, but it works on your hardware today.
  - wahern 7y ago
    Everybody attempts this. But the problem is that the ground keeps moving under your feet. Your portable interfaces become irrelevant as software systems evolve. XML gives way to JSON, etc. Eventually it costs just as much in time and effort to interoperate with your 10-20 year old "portable" interface as it would to interface with the mainframe directly, which was already established to have been too costly to bother. So now you have two problems, not just one.
    - benj111 7y ago
      Possibly. First I'd say that xml doesn't become 'wrong' when json came about. If that 1950s data format works for you, and you don't see advantages to moving, then fine stay with it. 2nd I'd say theres a half life of best practise. Over the 10 20 year tome frame, id expect some of what you were doing is going to become outdated yes, on the same way some of your knowledge over your career will become outdated, or the phone I your pocket will, you wouldn't use that as an argument against education, or buying that phone. Btw, if its as costly to deal with the interface as with the mainframe directly, that's a win. The interface can move off the mainframe to somewhere cheaper/better.
      - wahern 7y ago
        > First I'd say that xml doesn't become 'wrong' when json came about. It doesn't become wrong, it just evolves into another dead-end. The 3270 is an interface, too, but the reason everybody suggests replacing it or augmenting it is precisely because the spartan tooling and mindshare makes it expensive. As XML recedes into history it is likewise becoming more expensive as an interface. I chose XML vs JSON because I figured it was a transition everybody was somewhat familiar with. And younger programmers have an almost visceral dislike of XML, which I thought might help get the point across--that an interface someone once thought (and probably still thinks) would help ease future interoperability becomes a reason or excuse for future programmers to avoid that integration. > Btw, if its as costly to deal with the interface as with the mainframe directly, that's a win. I think the problem is that you don't really know if it's as costly. The error bars on that sort of risk assessment are huge because our industry sucks at accurately predicting migration costs. And it sucks because complex software systems are intrinsically unique. Commercial solutions that claim to be able to capture and control all those dimensions of complexity tend to be sold by vendors with names like IBM and Oracle. Such vendors also pioneered interfaces like SQL, which is both a soaring achievement in terms of capturing complexity behind a beautiful interface while also falling epically short of what's needed to actually reduce long-term integration costs.
reaperducer 7y ago
Choose one: - Spend $300,000,000 over 10 years moving to a new system, and hope that by the time you've done that it's not obsolete. - Spend $1,000,000 a year on a system that still works. You could run the system for 300 years for what it would cost to replace the system. In spite of the collective wisdom on HN, there aren't a lot of companies in the world with hundreds of millions of dollars sitting around doing nothing. Even ones that work on mainframes.
- SomeOldThrow 7y ago
  What’s the meaning of those numbers? Where did they come from? How did you lose the source to a 300 million dollar software project? If anything, this is a sign that mainframe users have way too much profit for what should probably be commodity software.
- benj111 7y ago
  I would characterise it as option 3 - Spend $1.5 million maintaining the current system, but as bits get updated keep in mind the system that you'd like to have in 10 15 years time. You're going to have to replace the system within 300 years anyway, you aren't saving that money, every feature you add that is reliant on the old system is literally technical debt, because eventually you'll have to rewrite it for the new system. I'm not even saying you need to have a new system in mind, just keep in mind that you will be moving to a new system, so code appropriately.
  - rbanffy 7y ago
    Since a mainframe can usually be updated to the newest model (and you often run more than one for redundancy, as some people may need more than 5 nines), in 300 years the company will have a z150 or so, with millions of quantum entangled cores made of folded spacetime mesh around a pair of rotating singularities running at a couple terahertz. And it will still be able to run all your programs that were written and tested since the late 20th century, by the kind of organic entity we used to call "human".
    - 7y ago
berti 7y ago
You seem to have made an assumption that the mainframe is “legacy hardware”, on a thread about the latest generation of mainframe hardware... As long as IBM keeps building mainframes the business case for anything else will remain unattractive. Unless you have some information to the contrary, it doesn’t make a lot of sense to invest (financially or technically) in switching.
- benj111 7y ago
  It isn't about legacy, it's about being stuck on one suppliers hardware. That isn't a great place to be.

derefr 7y ago

> so much other software has been built to interact with and rely on the mainframe over the years So just... have the new server expose itself over the TN3270/TN5250 protocols, such that these interoperating systems see what they expect to see? (You could even build the new system as a regular REST API or something at its core, and then build the TN3270/TN5250 exposure as a separate gateway service on top, such that it'd be easy to shut it off later if everything finally moves off it one day.)

schnable 7y ago
Just?
tyingq 7y ago
That's one of many possible integration points. LU6.2, SNA, batch file transfers, remote DB2 connections, MQ queues, etc.