7 ms·

How popular is COBOL?

67 points by mikece 4y ago

4RealFreedom 4y ago
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.
- 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...
atum47 4y ago
I used to work in a bank with people that came from mainframes. They use to talk about Cobol and how it was a well paid job, cause of the lack of programmers. As a way of learning the language I end up writing a perceptron in it [1]. It was a fun exercise. 1 - https://github.com/victorqribeiro/perceptronCobol https://github.com/victorqribeiro/perceptronCobol
earino 4y ago
I have been deeply fascinated by COBOL ever since 1994. In 1994 I was looking at where to go to college, and the community college near the town I grew up had two "computer" associates programs. One was a program focused on personal computers, and one was a program focused on mainframes. The person I spoke to at the school told me, at the time, that as far as he could tell graduates of both programs got good jobs, but he never saw anyone cross from one to the other. Once the track was picked, the lives and careers diverged. He described the mainframe path as "for going deep into the guts of banks, insurance companies, government and big big companies." It was not a great pitch to give a 16 year old IMO. I ended up going to neither and went to a traditional CS undergrad at a 4 year state school, and things have been fine ever since. However, on a regular basis, I think about the other life I would have had, if instead I had gotten an associate's in mainframe programming. What would I have done? Where would I have worked? Who even are those folks. If today I found a COBOL bootcamp that reskilled developers for a career change into COBOL, i may even seriously consider it. An unexplored path that has always been in the back of my head, deep in the guts of the engines of industry.
- ecshafer 4y ago
  I worked at one of the big financial corps where we were built on top of IBM DB2 with plenty of Cobol and JCL. Almost every team had 1-3 Cobol or "Data" programmers as we said embedded in them. If you needed to get or store data, it involved writing Cobol store procedures, and calling them from Java. There was also a lot of mainframe code running batch jobs that did a lot of critical work. this was from 2016-2021 so its pretty recent. Cobol devs were on average a bit older (on average id say 10-15 older than the rest of the devs), mainly because there weren't many college grads going in, and like your advisor had said there was a split between cobol and non-cobol devs with very little overlap. The majority of the cobol devs seemed to fall into a few camps. There were people who graduated in the 80s or 90s and just kept doing the same thing. There was also a large amount of Eastern Europeans that had immigrated in the 90s / 2000s and were cobol devs. Then there were also a decent amount of Indian contracting companies (TCS and the like) which seem to also train people in Cobol even today to hire as contractors.
- wvenable 4y ago
gbronner 4y ago
I had not worked with cobol until recently. If you have a solid background in C, it is not very hard to learn. It seems to show up at older companies, and is fairly good at moving and reformatting records where you want to address each field on a character by character basis. Unlike more modern languages, there's no encapsulation, polymorphism, local variables, etc., so you can write tangled code quite easily, though the code I've seen has been very well written. Everything is in capital letters, and the character set is often ebcdic. Most numbers are fixed decimals, which leads to some unusual math results. As a result, it can be maddeningly verbose -- I've seen 100+ lines of code that would just be a single printf statement in most other languages.
kibwen 4y ago
The amount of credence that this website appears to give to TIOBE (read: any at all) causes me to immediately dismiss their judgment. TIOBE is a nonsensical, wildly-fudged, deeply-flawed ranking made by people who have no idea what they're doing and seemingly no idea what industry they're in (which, if it's not self-evident from the way the ranking is designed, their methodology, and their presentation, should be obvious from the hilariously clueless summaries that accompany the rankings). By all means, believe whatever you like about Cobol's popularity. But if you think TIOBE has any weight, reconsider your sources.
- matkoniecz 4y ago
  Can you mention any specific problem with TIOBE or a better alternative?
  - kibwen 4y ago
    TIOBE's methodology is opaque, and even their own description of their methodology is completely nuts. Their historic trend lines suffer such massive random swings that it's obvious that they go in and manually fudge the numbers whenever it doesn't look "correct" (or are we to believe that C truly became half as popular between 2015-2016, and then gained it all back from 2016-2017? Remember that time that half of all C programmers were laid off, and then rehired eighteen months later? No? Remember that time that half of all C software stopped being used, and then started being used again eighteen months later? No? Then what in blazes is it supposed to have been measuring?). The prose summaries that they attempt to produce each month are technological gobbledygook, too poor to even publish in the sort of magazine that gives free subscriptions to middle managers. The "language of the year" ranking fails to even measure growth! Instead, it just measures the increase in ranking from the previous December, which means that a language whose popularity crashes through the floor for exactly one month out of the year due to their batshit methodology can be awarded "language of the year" for absolutely no reason, and this has happened! Rather than asking for a better alternative for gauging "popularity", stop looking to aggregators and instead look at actual numbers. For example, if you want to know which languages have the most job openings available, don't trust a measure of popularity, go to a job board and search by language.
tapland 4y ago
I haven't touched mainframes yet but been doing a bit of COBOL. Telcos, healthcare providers, insurance companies, anything that was early to get a billing system. Don't get into COBOL if you get annoyed at bad code :D
anyfoo 4y ago
I've dived relatively deeply into mainframes as a small, intermittent hobby the last few years (https://www.jaymoseley.com/hercules/ https://www.jaymoseley.com/hercules/). Read (and organized!) a lot of IBM documentation, played with JCL more than just on the surface, explored corners of the OS, and dabbled with some s/360 assembly and PL/I. At some point I inspected hex dumps of the disk ("DASD") images to prove a theory I had. What attracted me to it is just how different it is from the UNIX/PC world I'm coming from, it's endlessly interesting, it challenges what you assumed were ground truths. So is AS/400 (or IBM i as it is now called), which is also completely different but in some ways opposite to how the mainframe world is different. Those two rewired my understanding of OS reality like Haskell rewired my understanding of programming language reality. At this point I could probably dive into COBOL and pivot my job into maintaining mainframe stuff, and some part of me thinks it's fun, but I have a fun low level programming job, so I don't know if I'd ever really do that. Maybe to fill time during retirement?
- anyfoo 4y ago
  Okay, I uncharacteristically have to respond to my own post, because I happened to reread it in the "threads" tab and it jumped out to myself just how wrong it sounds, even though it was upvoted. I had edited it before hitting send, and apparently did not notice that I kind of damaged the meaning. So to be clear, what I meant to say was that for a small hobby I dived relatively deeply into it (i.e. I see others messing with it for fun not caring that much about e.g. JCL), and that I wet my feet enough that if I put the serious work in, I could see myself eventually becoming productive in the COBOL and mainframe world. Just because rereading it, it sounded like I said I became mainframe proficient to a commercial level by playing around with a many decades old MVS version on Hercules, which is hilarious.
hajile 4y ago
Frankly, I was shocked at how low COBOL salaries tend to be. I want extra money to code in a terrible language maintaining your bloating, ancient codebase. They believe that all of this should mean LESS salary. Meanwhile, old COBOL devs are retiring in droves and the businesses stuck on COBOL have countless billions riding on those systems. Why hasn't supply/demand kicked in yet?
- anonylizard 4y ago
  Because COBOL is not difficult to learn, in fact it was designed so that 'businesspeople' could easily learn it (Which didn't happen). COBOL is merely undesirable from a long term career perspective. The aggregate demand is also very small. Therefore India's big IT shops can simply train some fresh grads to learn COBOL. Those grads don't care about working on the latest tech, they just want a well paid and stable job. This puts a hard ceiling on the wages of COBOL programmers.
  - raverbashing 4y ago
    Yeah. One of the biggest "myths" around computing is that non-technical people will want to do any form of coding (and yes, I'm talking about BDD as well) The only development environment they know (barely) is Excel
  - zozbot234 4y ago
    COBOL may not be all that difficult to learn, but the proprietary systems and environments that a legacy COBOL program will be designed to interact with are a different story. These are often extremely obscure.
- MuffinFlavored 4y ago
  those same businesses are run by tech executives who haven’t written a line of code in 20 years it’s all about saying no to raises, controlling people to work with their butts in a chair in an office, 8am meetings, 10 different teams to do basic things, 5 people per project whose sole job is to say “no we can’t do that”, lots of 2am batch processing on call not sure if supply/demand works for 40k employee companies
stoppingin 4y ago
I've been working in environments that use mainframe systems for a long time. I've read COBOL code to get an idea of what's happening downstream, but never actually written a line of COBOL myself. I've always wanted to know: In a modern context, does COBOL have any advantages for applications like transaction processing? I understand that it's not ideal from a language point of view, but does it have any properties that make it a great fit for the job? Does COBOL on a mainframe have particular properties that make it good for concurrency, validation, etc?
- Frummy 4y ago
  It basically is extremely reliable and deterministic. Mainframes just work and stay up indefinitely. If you want to do a tax report or send out scheduled mails on 5 000 000 accounts, cobol is the right tool for that sort of job. Just shuffling data in let's call it a DAG of batch jobs with sql and restart checkpoints sprinkled in. It fails due to human error in the code or a relied upon system, because bugs in the language itself are nonexistent. Updates to the code is mostly due to regulation and compliance and keeping the business running. But mostly, it's just impossibly expensive to rewrite a humongous spaghetti of societally critical systems from cobol to something modern such as java or .NET.
  - fifilura 4y ago
    I am curious, and I don't have the insights into these systems. But you first mention DAGs. And then you say rewrite to java or .NET. When I think about DAGs today, i think about Airflow. And SQL. Would it be a better match to rewrite these systems in SQL and Airflow? SQL for the logic and Airflow for the batch processing. I know for many (particularly those who mention java and .NET) SQL is just a place where you fetch and store your data. But once you start building systems with it, you will soon realize it contains nothing more and - at the same time - nothing less than what you actually need for mangling your data in a terse way. I know there are many reasons to frown on SQL for this, and I am fine with any comments about it. I think it can be a start of a good discussion. Nothing is black or white.
    - 4y ago
scottmcdot 4y ago
Could Python be used to re-build a banking mainframe written in COBOL?
- gattilorenz 4y ago
  you could rebuild it in any turing-complete language, including Brainfuck. But why would you do that? I suspect there’s few good reasons for doing it (ease of finding new programmers) and many good reasons not to do it (speed, it’s code that has been battle-tested for ages). Anyway, from friends working in the banking sector, nowadays the mainframe code is exposing an API and users are accessing data via a web interface and not a terminal emulator anymore.
- tabtab 4y ago
  COBOL has a lot of built in business and CRUD idioms that would require fairly large Python libraries to reinvent. COBOL is a domain-specific-language and Python isn't.
oger 4y ago
Find the dot!
ungamedplayer 4y ago
I ported gnucobol to webasm to inflict pain on future generations of programmers. https://github.com/wmealing/cob-webber https://github.com/wmealing/cob-webber Ncurses with vt100 emulation kinda works. But it's timing is garbage and text input is funny.
dusted 4y ago
"How popular is COBOL?" proceeds with giant image of javascript
- distcs 4y ago
  It is what they call "hero image" these days. Who even comes up with these terms? I dislike it. An unrelated "hero image" of Javascript code plugged into a COBOL article (and the article is pretty good, to be fair) is why I don't like these trends. These trends contribute anything to the article but add distractions.
unixhero 4y ago
A friend of mine got a job programming RPG IV on mainframes in 2022 (!). The RPG language PREDATES Cobol! [0] https://en.wikipedia.org/wiki/IBM_RPG https://en.wikipedia.org/wiki/IBM_RPG
- tannhaeuser 4y ago
  I know "mainframe" is ambivalent but RPG was introduced and used with IBM's midrange line ie. I-Series aka AS/400; so not "mainframe" IMO, and the IBM proprietary non-COBOL language on "mainframes" aka z-Series running MVS would be PL/1.
  - unixhero 4y ago
    It says right there on the wikipedia enttry it was introduced in 1959, which was before AS/400.
kwhitefoot 4y ago
For me a more interesting question would "What is the geographical or national distribution of COBOL around the world.". It seems that most people's comments refer to COBOL used in the US.
BXLE_1-1-BitIs1 4y ago
I had a, which now seems quaint, habit of keeping compile listings (which have all sorts of neat information) for my applications. However I have a deep distaste for writing in COBOL. That said, my favorite resource for dealing with COBOL problems was AMBLIST which shows the compile date and other attributes of each object module,whether COBOL, FORTRAN, Assembler or PL/I. There's a number of mainframe source management tools. In VM, XEDIT would automatically generate change records for source files as they were modified. It made a lot of sense to develop under VM and deploy to MVS, z/OS just to have good source control without having to buy source management tools and enforce their use. I strongly suspect IBM does pretty much the same for their mainframe operating system and utility code. The dirty secret is that the code that runs logical partitions is a flavor of VM. COBOL and FORTRAN in the early days had minimal subroutine libraries. Direct calls to the supervisor were made in the compiled code along with building the parameters and handling the results. This does make it more straightforward to see what the object code is doing. PL/I had a comprehensive subroutine library. Later on the subroutine libraries for the various compiler languages were consolidated into Language Environment.
shashurup 4y ago
The second thing in my list after performing silly job interview is to send an unsolicited cobol implementation of a test task at some stage of a hiring process and later on an actual interview pretend that nothing special is happening.

67 points by mikece 4y ago

4RealFreedom 4y ago

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.
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...

atum47 4y ago

I used to work in a bank with people that came from mainframes. They use to talk about Cobol and how it was a well paid job, cause of the lack of programmers. As a way of learning the language I end up writing a perceptron in it [1]. It was a fun exercise. 1 - https://github.com/victorqribeiro/perceptronCobol https://github.com/victorqribeiro/perceptronCobol

earino 4y ago

I have been deeply fascinated by COBOL ever since 1994. In 1994 I was looking at where to go to college, and the community college near the town I grew up had two "computer" associates programs. One was a program focused on personal computers, and one was a program focused on mainframes. The person I spoke to at the school told me, at the time, that as far as he could tell graduates of both programs got good jobs, but he never saw anyone cross from one to the other. Once the track was picked, the lives and careers diverged. He described the mainframe path as "for going deep into the guts of banks, insurance companies, government and big big companies." It was not a great pitch to give a 16 year old IMO. I ended up going to neither and went to a traditional CS undergrad at a 4 year state school, and things have been fine ever since. However, on a regular basis, I think about the other life I would have had, if instead I had gotten an associate's in mainframe programming. What would I have done? Where would I have worked? Who even are those folks. If today I found a COBOL bootcamp that reskilled developers for a career change into COBOL, i may even seriously consider it. An unexplored path that has always been in the back of my head, deep in the guts of the engines of industry.

ecshafer 4y ago
I worked at one of the big financial corps where we were built on top of IBM DB2 with plenty of Cobol and JCL. Almost every team had 1-3 Cobol or "Data" programmers as we said embedded in them. If you needed to get or store data, it involved writing Cobol store procedures, and calling them from Java. There was also a lot of mainframe code running batch jobs that did a lot of critical work. this was from 2016-2021 so its pretty recent. Cobol devs were on average a bit older (on average id say 10-15 older than the rest of the devs), mainly because there weren't many college grads going in, and like your advisor had said there was a split between cobol and non-cobol devs with very little overlap. The majority of the cobol devs seemed to fall into a few camps. There were people who graduated in the 80s or 90s and just kept doing the same thing. There was also a large amount of Eastern Europeans that had immigrated in the 90s / 2000s and were cobol devs. Then there were also a decent amount of Indian contracting companies (TCS and the like) which seem to also train people in Cobol even today to hire as contractors.
wvenable 4y ago

gbronner 4y ago

I had not worked with cobol until recently. If you have a solid background in C, it is not very hard to learn. It seems to show up at older companies, and is fairly good at moving and reformatting records where you want to address each field on a character by character basis. Unlike more modern languages, there's no encapsulation, polymorphism, local variables, etc., so you can write tangled code quite easily, though the code I've seen has been very well written. Everything is in capital letters, and the character set is often ebcdic. Most numbers are fixed decimals, which leads to some unusual math results. As a result, it can be maddeningly verbose -- I've seen 100+ lines of code that would just be a single printf statement in most other languages.

kibwen 4y ago

The amount of credence that this website appears to give to TIOBE (read: any at all) causes me to immediately dismiss their judgment. TIOBE is a nonsensical, wildly-fudged, deeply-flawed ranking made by people who have no idea what they're doing and seemingly no idea what industry they're in (which, if it's not self-evident from the way the ranking is designed, their methodology, and their presentation, should be obvious from the hilariously clueless summaries that accompany the rankings). By all means, believe whatever you like about Cobol's popularity. But if you think TIOBE has any weight, reconsider your sources.

matkoniecz 4y ago
Can you mention any specific problem with TIOBE or a better alternative?
- kibwen 4y ago
  TIOBE's methodology is opaque, and even their own description of their methodology is completely nuts. Their historic trend lines suffer such massive random swings that it's obvious that they go in and manually fudge the numbers whenever it doesn't look "correct" (or are we to believe that C truly became half as popular between 2015-2016, and then gained it all back from 2016-2017? Remember that time that half of all C programmers were laid off, and then rehired eighteen months later? No? Remember that time that half of all C software stopped being used, and then started being used again eighteen months later? No? Then what in blazes is it supposed to have been measuring?). The prose summaries that they attempt to produce each month are technological gobbledygook, too poor to even publish in the sort of magazine that gives free subscriptions to middle managers. The "language of the year" ranking fails to even measure growth! Instead, it just measures the increase in ranking from the previous December, which means that a language whose popularity crashes through the floor for exactly one month out of the year due to their batshit methodology can be awarded "language of the year" for absolutely no reason, and this has happened! Rather than asking for a better alternative for gauging "popularity", stop looking to aggregators and instead look at actual numbers. For example, if you want to know which languages have the most job openings available, don't trust a measure of popularity, go to a job board and search by language.

tapland 4y ago

I haven't touched mainframes yet but been doing a bit of COBOL. Telcos, healthcare providers, insurance companies, anything that was early to get a billing system. Don't get into COBOL if you get annoyed at bad code :D

anyfoo 4y ago

I've dived relatively deeply into mainframes as a small, intermittent hobby the last few years (https://www.jaymoseley.com/hercules/ https://www.jaymoseley.com/hercules/). Read (and organized!) a lot of IBM documentation, played with JCL more than just on the surface, explored corners of the OS, and dabbled with some s/360 assembly and PL/I. At some point I inspected hex dumps of the disk ("DASD") images to prove a theory I had. What attracted me to it is just how different it is from the UNIX/PC world I'm coming from, it's endlessly interesting, it challenges what you assumed were ground truths. So is AS/400 (or IBM i as it is now called), which is also completely different but in some ways opposite to how the mainframe world is different. Those two rewired my understanding of OS reality like Haskell rewired my understanding of programming language reality. At this point I could probably dive into COBOL and pivot my job into maintaining mainframe stuff, and some part of me thinks it's fun, but I have a fun low level programming job, so I don't know if I'd ever really do that. Maybe to fill time during retirement?

anyfoo 4y ago
Okay, I uncharacteristically have to respond to my own post, because I happened to reread it in the "threads" tab and it jumped out to myself just how wrong it sounds, even though it was upvoted. I had edited it before hitting send, and apparently did not notice that I kind of damaged the meaning. So to be clear, what I meant to say was that for a small hobby I dived relatively deeply into it (i.e. I see others messing with it for fun not caring that much about e.g. JCL), and that I wet my feet enough that if I put the serious work in, I could see myself eventually becoming productive in the COBOL and mainframe world. Just because rereading it, it sounded like I said I became mainframe proficient to a commercial level by playing around with a many decades old MVS version on Hercules, which is hilarious.

hajile 4y ago

Frankly, I was shocked at how low COBOL salaries tend to be. I want extra money to code in a terrible language maintaining your bloating, ancient codebase. They believe that all of this should mean LESS salary. Meanwhile, old COBOL devs are retiring in droves and the businesses stuck on COBOL have countless billions riding on those systems. Why hasn't supply/demand kicked in yet?

anonylizard 4y ago
Because COBOL is not difficult to learn, in fact it was designed so that 'businesspeople' could easily learn it (Which didn't happen). COBOL is merely undesirable from a long term career perspective. The aggregate demand is also very small. Therefore India's big IT shops can simply train some fresh grads to learn COBOL. Those grads don't care about working on the latest tech, they just want a well paid and stable job. This puts a hard ceiling on the wages of COBOL programmers.
- raverbashing 4y ago
  Yeah. One of the biggest "myths" around computing is that non-technical people will want to do any form of coding (and yes, I'm talking about BDD as well) The only development environment they know (barely) is Excel
- zozbot234 4y ago
  COBOL may not be all that difficult to learn, but the proprietary systems and environments that a legacy COBOL program will be designed to interact with are a different story. These are often extremely obscure.
MuffinFlavored 4y ago
those same businesses are run by tech executives who haven’t written a line of code in 20 years it’s all about saying no to raises, controlling people to work with their butts in a chair in an office, 8am meetings, 10 different teams to do basic things, 5 people per project whose sole job is to say “no we can’t do that”, lots of 2am batch processing on call not sure if supply/demand works for 40k employee companies

stoppingin 4y ago

I've been working in environments that use mainframe systems for a long time. I've read COBOL code to get an idea of what's happening downstream, but never actually written a line of COBOL myself. I've always wanted to know: In a modern context, does COBOL have any advantages for applications like transaction processing? I understand that it's not ideal from a language point of view, but does it have any properties that make it a great fit for the job? Does COBOL on a mainframe have particular properties that make it good for concurrency, validation, etc?

Frummy 4y ago
It basically is extremely reliable and deterministic. Mainframes just work and stay up indefinitely. If you want to do a tax report or send out scheduled mails on 5 000 000 accounts, cobol is the right tool for that sort of job. Just shuffling data in let's call it a DAG of batch jobs with sql and restart checkpoints sprinkled in. It fails due to human error in the code or a relied upon system, because bugs in the language itself are nonexistent. Updates to the code is mostly due to regulation and compliance and keeping the business running. But mostly, it's just impossibly expensive to rewrite a humongous spaghetti of societally critical systems from cobol to something modern such as java or .NET.
- fifilura 4y ago
  I am curious, and I don't have the insights into these systems. But you first mention DAGs. And then you say rewrite to java or .NET. When I think about DAGs today, i think about Airflow. And SQL. Would it be a better match to rewrite these systems in SQL and Airflow? SQL for the logic and Airflow for the batch processing. I know for many (particularly those who mention java and .NET) SQL is just a place where you fetch and store your data. But once you start building systems with it, you will soon realize it contains nothing more and - at the same time - nothing less than what you actually need for mangling your data in a terse way. I know there are many reasons to frown on SQL for this, and I am fine with any comments about it. I think it can be a start of a good discussion. Nothing is black or white.
  - 4y ago

scottmcdot 4y ago

Could Python be used to re-build a banking mainframe written in COBOL?

gattilorenz 4y ago
you could rebuild it in any turing-complete language, including Brainfuck. But why would you do that? I suspect there’s few good reasons for doing it (ease of finding new programmers) and many good reasons not to do it (speed, it’s code that has been battle-tested for ages). Anyway, from friends working in the banking sector, nowadays the mainframe code is exposing an API and users are accessing data via a web interface and not a terminal emulator anymore.
tabtab 4y ago
COBOL has a lot of built in business and CRUD idioms that would require fairly large Python libraries to reinvent. COBOL is a domain-specific-language and Python isn't.

oger 4y ago

Find the dot!

ungamedplayer 4y ago

I ported gnucobol to webasm to inflict pain on future generations of programmers. https://github.com/wmealing/cob-webber https://github.com/wmealing/cob-webber Ncurses with vt100 emulation kinda works. But it's timing is garbage and text input is funny.

dusted 4y ago

"How popular is COBOL?" proceeds with giant image of javascript

distcs 4y ago
It is what they call "hero image" these days. Who even comes up with these terms? I dislike it. An unrelated "hero image" of Javascript code plugged into a COBOL article (and the article is pretty good, to be fair) is why I don't like these trends. These trends contribute anything to the article but add distractions.

unixhero 4y ago

A friend of mine got a job programming RPG IV on mainframes in 2022 (!). The RPG language PREDATES Cobol! [0] https://en.wikipedia.org/wiki/IBM_RPG https://en.wikipedia.org/wiki/IBM_RPG

tannhaeuser 4y ago
I know "mainframe" is ambivalent but RPG was introduced and used with IBM's midrange line ie. I-Series aka AS/400; so not "mainframe" IMO, and the IBM proprietary non-COBOL language on "mainframes" aka z-Series running MVS would be PL/1.
- unixhero 4y ago
  It says right there on the wikipedia enttry it was introduced in 1959, which was before AS/400.

kwhitefoot 4y ago

For me a more interesting question would "What is the geographical or national distribution of COBOL around the world.". It seems that most people's comments refer to COBOL used in the US.

BXLE_1-1-BitIs1 4y ago

I had a, which now seems quaint, habit of keeping compile listings (which have all sorts of neat information) for my applications. However I have a deep distaste for writing in COBOL. That said, my favorite resource for dealing with COBOL problems was AMBLIST which shows the compile date and other attributes of each object module,whether COBOL, FORTRAN, Assembler or PL/I. There's a number of mainframe source management tools. In VM, XEDIT would automatically generate change records for source files as they were modified. It made a lot of sense to develop under VM and deploy to MVS, z/OS just to have good source control without having to buy source management tools and enforce their use. I strongly suspect IBM does pretty much the same for their mainframe operating system and utility code. The dirty secret is that the code that runs logical partitions is a flavor of VM. COBOL and FORTRAN in the early days had minimal subroutine libraries. Direct calls to the supervisor were made in the compiled code along with building the parameters and handling the results. This does make it more straightforward to see what the object code is doing. PL/I had a comprehensive subroutine library. Later on the subroutine libraries for the various compiler languages were consolidated into Language Environment.

shashurup 4y ago

The second thing in my list after performing silly job interview is to send an unsolicited cobol implementation of a test task at some stage of a hiring process and later on an actual interview pretend that nothing special is happening.