6 ms·

What about not doing a rewrite? What about instead refactoring, documenting etc the old system.

kpil 10y ago
Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s
- tyingq 10y ago
  As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.
  - kpil 10y ago
    To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.
  - deleted 10y ago
    [deleted]
- devwastaken 10y ago
  There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.
- bpicolo 10y ago
  Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.
- SmellTheGlove 10y ago
  Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.
  - Arizhel 10y ago
    The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.
    - SmellTheGlove 10y ago
      Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good. We're not running our modeling engines and that stuff on it. We have HPC for that.
- chiph 10y ago
  Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.
pc86 10y ago
If you want to move off of COBOL + mainframe, that kind of necessitates a rewrite, doesn't it?
- binarymax 10y ago
  Emulate the mainframe and make a modern abstraction interface over the platform. We investigated this option for some IBM 360 COBOL code for a project I was running. We were a very small team and were market consumers (not implementers) of the original system which got open sourced in a panic. We eventually chose not too - but seriously considered it. If I were the owners (the Fed) I would have.
  - dpark 10y ago
    This doesn't help if part of your goal is to have a system not written in COBOL. Emulating the older hardware and OS gives you an even more complex system that's harder to hire people to work on.
    - binarymax 10y ago
      It helps for the first stage - getting the platform onto a more sustainable environment. Once the interface exists and has full coverage, parts of the backend can begin migration without a doomed-to-fail 'big bang' rewrite.
      - dpark 10y ago
        Does it really help? What does it cost to build a trustworthy emulator for an ancient system that you don't own the source for? What would it cost to just migrate your legacy applications to a newer mainframe that IBM supports?
        binarymax 10y ago
        I wasnt suggesting writing an emulator from scratch. I was suggesting emulating the mainframe. Here is what we, specifically, were looking at: https://en.wikipedia.org/wiki/Hercules_%28emulator%29 https://en.wikipedia.org/wiki/Hercules_%28emulator%29

kpil 10y ago

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s

tyingq 10y ago
As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.
- kpil 10y ago
  To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.
- deleted 10y ago
  [deleted]
devwastaken 10y ago
There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.
bpicolo 10y ago
Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.
SmellTheGlove 10y ago
Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.
- Arizhel 10y ago
  The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.
  - SmellTheGlove 10y ago
    Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good. We're not running our modeling engines and that stuff on it. We have HPC for that.
chiph 10y ago
Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.

pc86 10y ago

If you want to move off of COBOL + mainframe, that kind of necessitates a rewrite, doesn't it?

binarymax 10y ago
Emulate the mainframe and make a modern abstraction interface over the platform. We investigated this option for some IBM 360 COBOL code for a project I was running. We were a very small team and were market consumers (not implementers) of the original system which got open sourced in a panic. We eventually chose not too - but seriously considered it. If I were the owners (the Fed) I would have.
- dpark 10y ago
  This doesn't help if part of your goal is to have a system not written in COBOL. Emulating the older hardware and OS gives you an even more complex system that's harder to hire people to work on.
  - binarymax 10y ago
    It helps for the first stage - getting the platform onto a more sustainable environment. Once the interface exists and has full coverage, parts of the backend can begin migration without a doomed-to-fail 'big bang' rewrite.
    - dpark 10y ago
      Does it really help? What does it cost to build a trustworthy emulator for an ancient system that you don't own the source for? What would it cost to just migrate your legacy applications to a newer mainframe that IBM supports?
      - binarymax 10y ago
        I wasnt suggesting writing an emulator from scratch. I was suggesting emulating the mainframe. Here is what we, specifically, were looking at: https://en.wikipedia.org/wiki/Hercules_%28emulator%29 https://en.wikipedia.org/wiki/Hercules_%28emulator%29