7 ms·

Maybe it's the type of companies I've worked for but I have never seen cobol. Anyone know where it's used most?

by 4RealFreedom 4y ago

jcelerier 4y ago
In France I've some friends who got COBOL jobs almost right out of school, around 2014-2015
- LeonenTheDK 4y ago
  Same in Canada, around 2017-18. My college program actually had several mainframe development with COBOL courses which were very interesting.
bitwize 4y ago
Banks, insurance companies, big old companies that have to do transaction processing, have old applications that have been running since the 1960s/70s, and are dependent on those applications just working until the sun goes out.
- Gigachad 4y ago
  From what I can see even banks are starting to modernise things. I’m seeing banks advertise Rust positions recently as well as various other modern tech.
  - jimjimjim 4y ago
    hopefully that's the case. I have seen some that are too afraid to change it in case something breaks. They then wrap the core cobol system in many layers of java to provide a more friendly interface to external modules.
  - lmkg 4y ago
    Banks have tons of things going on, I wouldn't take one (or even a hundred) job postings as indicative of a firm-wide shift in strategy. They could be using Rust for their phone app or their real-time ML fraud-detection system, while he checks are still processed by a piece of software whose source code is COBOL whose only extant copy was written by typewriter in 1975.
    - onlyrealcuzzo 4y ago
      This isn't serious is it?! I find it hard to believe banks are running critical code they didn't at least back up somewhere. I also don't understand why it would be hard to back up the code.
      - walnutclosefarm 4y ago
        I can't tell you how common it was or is, but I can tell you that I worked with at least two banks in Europe in the early 2000s that were rewriting core transaction processing and routing systems that were originally written in COBOL, and for which they had lost the source code. They patched the systems when necessary by patching the object code in assembler. The systems were 30 odd years old at the time. Nobody seemed to be able to explain how the source code was lost, other than that it had something to do with corporate mergers and acquisitions. The fact that they were spending millions to rewrite them was an indication of unsatisfactory they found the situation to be.
        jamesfinlayson 4y ago
        > They patched the systems when necessary by patching the object code in assembler. If that sort of development can't force a rewrite then nothing will.
      - cratermoon 4y ago
        When it was last compiled from source, the source was punched cards. They were placed in a file somewhere and ended up either getting thrown out as part of a data retention move or shipped off to Iron Mountain to be lost among billions of other boxes.
      - Spooky23 4y ago
        Those systems are usually boring things that never get modified. Ledgers, etc. The tasks required to process checks are the same as they were in 1975. The inputs and outputs just changed. Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go. The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario. Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.
balderdash 4y ago
The phone company, irs, local utility, etc. any large business that was in operation 60+ years ago?
- justinator 4y ago
  For better or for worse, the IRS is probably the worst ambassador for COBOL.
  - skissane 4y ago
    Their COBOL stuff is positively modern when compared to the oldest part of the IRS stack, which is written in IBM 7074 assembly - that’s IBM’s pre-S/360 business mainframe line, from the early 1960s. It runs under an emulator on contemporary IBM mainframes. (I know IRS has been working on rewriting it all - the 7074 assembly, the 360/370 assembly, and the COBOL - in newer languages such as Java. I don’t know where they are up to with that, so I don’t know if they still have 7074 apps live today. But certainly they did as recently as 4-5 years ago.)
    - justinator 4y ago
      I believe you - it's more the perception of how backwards and dysfunctional the IRS seems to operate.
jimjimjim 4y ago
I've noticed it at older large companies. banks, oil companies that sort of thing.
adra 4y ago
Any company that knows better has done a modernization to get to get off it asap. The legacy nature of the products means that the few outlets that still support them or their mainframes are charging exorbitant rates. How much? I had a customer (non-gov) that paid a million$ a month to keep their product leased and up on their support agreement, that $12m a year without even talking about the costs of finding Cobol devs. Whos still using them? Any bureaucracy terrible enough to have not transitioned years (decades) ago.
- analog31 4y ago
  I wonder if second system effect looms large in the minds of those who are maintaining those COBOL programs. At least with a legacy program, you probably know that it can keep running for another year for a predictable cost. On the other hand, spinning up a scratch build of its replacement is potentially a black hole. I've witnessed second system effect.
- skissane 4y ago
  Many places where COBOL survives, it survives because of at least one (sometimes more than one) mega-failure in which management spends tens of millions on replacing it with a new system written in Java/.NET/whatever, only for that replacement to turn into such a complete disaster that it ends up completely abandoned and the whole development cost written-off
  - Kamq 4y ago
    This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.
    - skissane 4y ago
      Sometimes implementations fail for essentially the opposite reason – the new system is too generic and insufficiently close to the original program. One place I worked (a university), they tried to replace their mainframe COBOL system (Fujitsu FACOM GS8400 mainframe [0] [1], along with Software AG's ADABAS database and some use of their Natural 4GL as well) with PeopleSoft Campus. However, PeopleSoft Campus was designed for the US market, and many of its features were rather irrelevant in Australia; conversely, key features needed to cope with Australia's rather different regulatory environment were lacking, forcing the project to reimplement large parts of the original COBOL system as add-on code. PeopleSoft sales (this was in the mid-to-late 1990s, so before Oracle bought them) had painted (whether by intention or ignorance) a fundamentally misleading picture of how suitable the product was for the Australian market. Eventually the whole project was written off as an expensive multi-million dollar failure, and the mainframe COBOL system got a reprieve on its execution. I was still in high school when it happened, but when I worked there several years later, the "PeopleSoft disaster" was a frequently repeated part of local institutional lore. Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market. [0] https://www.fujitsu.com/au/about/corporate/history/products/computer/mainframe/gs8600.html https://www.fujitsu.com/au/about/corporate/history/products/... [1] http://museum.ipsj.or.jp/en/computer/main/0088.html http://museum.ipsj.or.jp/en/computer/main/0088.html
jamesfinlayson 4y ago
I've never worked at a company that uses it (though I've worked somewhere with lots of very important Fortran) though I know someone who worked at a place with COBOL. But as others have said, banks and other large companies that started using computers a long time ago would have critical services written in COBOL.
Smoosh 4y ago
I maintain COBOL systems for a large department of the Australian Government. The new code and UI are in midrange Java, but older parts and especially batch processing including generating correspondence is done on the mainframe.
tannhaeuser 4y ago
Obligatory: the T-800 is running on COBOL [1]. [1]: https://old.reddit.com/r/programming/comments/cd1g2/the_terminator_was_written_in_cobol/ https://old.reddit.com/r/programming/comments/cd1g2/the_term...

Maybe it's the type of companies I've worked for but I have never seen cobol. Anyone know where it's used most?

jcelerier 4y ago

In France I've some friends who got COBOL jobs almost right out of school, around 2014-2015

LeonenTheDK 4y ago
Same in Canada, around 2017-18. My college program actually had several mainframe development with COBOL courses which were very interesting.

bitwize 4y ago

Banks, insurance companies, big old companies that have to do transaction processing, have old applications that have been running since the 1960s/70s, and are dependent on those applications just working until the sun goes out.

Gigachad 4y ago
From what I can see even banks are starting to modernise things. I’m seeing banks advertise Rust positions recently as well as various other modern tech.
- jimjimjim 4y ago
  hopefully that's the case. I have seen some that are too afraid to change it in case something breaks. They then wrap the core cobol system in many layers of java to provide a more friendly interface to external modules.
- lmkg 4y ago
  Banks have tons of things going on, I wouldn't take one (or even a hundred) job postings as indicative of a firm-wide shift in strategy. They could be using Rust for their phone app or their real-time ML fraud-detection system, while he checks are still processed by a piece of software whose source code is COBOL whose only extant copy was written by typewriter in 1975.
  - onlyrealcuzzo 4y ago
    This isn't serious is it?! I find it hard to believe banks are running critical code they didn't at least back up somewhere. I also don't understand why it would be hard to back up the code.
    - walnutclosefarm 4y ago
      I can't tell you how common it was or is, but I can tell you that I worked with at least two banks in Europe in the early 2000s that were rewriting core transaction processing and routing systems that were originally written in COBOL, and for which they had lost the source code. They patched the systems when necessary by patching the object code in assembler. The systems were 30 odd years old at the time. Nobody seemed to be able to explain how the source code was lost, other than that it had something to do with corporate mergers and acquisitions. The fact that they were spending millions to rewrite them was an indication of unsatisfactory they found the situation to be.
      - jamesfinlayson 4y ago
        > They patched the systems when necessary by patching the object code in assembler. If that sort of development can't force a rewrite then nothing will.
    - cratermoon 4y ago
      When it was last compiled from source, the source was punched cards. They were placed in a file somewhere and ended up either getting thrown out as part of a data retention move or shipped off to Iron Mountain to be lost among billions of other boxes.
    - Spooky23 4y ago
      Those systems are usually boring things that never get modified. Ledgers, etc. The tasks required to process checks are the same as they were in 1975. The inputs and outputs just changed. Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go. The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario. Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.

balderdash 4y ago

The phone company, irs, local utility, etc. any large business that was in operation 60+ years ago?

justinator 4y ago
For better or for worse, the IRS is probably the worst ambassador for COBOL.
- skissane 4y ago
  Their COBOL stuff is positively modern when compared to the oldest part of the IRS stack, which is written in IBM 7074 assembly - that’s IBM’s pre-S/360 business mainframe line, from the early 1960s. It runs under an emulator on contemporary IBM mainframes. (I know IRS has been working on rewriting it all - the 7074 assembly, the 360/370 assembly, and the COBOL - in newer languages such as Java. I don’t know where they are up to with that, so I don’t know if they still have 7074 apps live today. But certainly they did as recently as 4-5 years ago.)
  - justinator 4y ago
    I believe you - it's more the perception of how backwards and dysfunctional the IRS seems to operate.

jimjimjim 4y ago

I've noticed it at older large companies. banks, oil companies that sort of thing.

adra 4y ago

Any company that knows better has done a modernization to get to get off it asap. The legacy nature of the products means that the few outlets that still support them or their mainframes are charging exorbitant rates. How much? I had a customer (non-gov) that paid a million$ a month to keep their product leased and up on their support agreement, that $12m a year without even talking about the costs of finding Cobol devs. Whos still using them? Any bureaucracy terrible enough to have not transitioned years (decades) ago.

analog31 4y ago
I wonder if second system effect looms large in the minds of those who are maintaining those COBOL programs. At least with a legacy program, you probably know that it can keep running for another year for a predictable cost. On the other hand, spinning up a scratch build of its replacement is potentially a black hole. I've witnessed second system effect.
skissane 4y ago
Many places where COBOL survives, it survives because of at least one (sometimes more than one) mega-failure in which management spends tens of millions on replacing it with a new system written in Java/.NET/whatever, only for that replacement to turn into such a complete disaster that it ends up completely abandoned and the whole development cost written-off
- Kamq 4y ago
  This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.
  - skissane 4y ago
    Sometimes implementations fail for essentially the opposite reason – the new system is too generic and insufficiently close to the original program. One place I worked (a university), they tried to replace their mainframe COBOL system (Fujitsu FACOM GS8400 mainframe [0] [1], along with Software AG's ADABAS database and some use of their Natural 4GL as well) with PeopleSoft Campus. However, PeopleSoft Campus was designed for the US market, and many of its features were rather irrelevant in Australia; conversely, key features needed to cope with Australia's rather different regulatory environment were lacking, forcing the project to reimplement large parts of the original COBOL system as add-on code. PeopleSoft sales (this was in the mid-to-late 1990s, so before Oracle bought them) had painted (whether by intention or ignorance) a fundamentally misleading picture of how suitable the product was for the Australian market. Eventually the whole project was written off as an expensive multi-million dollar failure, and the mainframe COBOL system got a reprieve on its execution. I was still in high school when it happened, but when I worked there several years later, the "PeopleSoft disaster" was a frequently repeated part of local institutional lore. Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market. [0] https://www.fujitsu.com/au/about/corporate/history/products/computer/mainframe/gs8600.html https://www.fujitsu.com/au/about/corporate/history/products/... [1] http://museum.ipsj.or.jp/en/computer/main/0088.html http://museum.ipsj.or.jp/en/computer/main/0088.html

jamesfinlayson 4y ago

I've never worked at a company that uses it (though I've worked somewhere with lots of very important Fortran) though I know someone who worked at a place with COBOL. But as others have said, banks and other large companies that started using computers a long time ago would have critical services written in COBOL.

Smoosh 4y ago

I maintain COBOL systems for a large department of the Australian Government. The new code and UI are in midrange Java, but older parts and especially batch processing including generating correspondence is done on the mainframe.

tannhaeuser 4y ago

Obligatory: the T-800 is running on COBOL [1]. [1]: https://old.reddit.com/r/programming/comments/cd1g2/the_terminator_was_written_in_cobol/ https://old.reddit.com/r/programming/comments/cd1g2/the_term...