5 ms·

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong? COBOL seems to be a straightforward language by

I have seen the COBOL issue come up a number of times, and I just don't get it. Am I thinking about this wrong? COBOL seems to be a straightforward language by modern standards. Any programmer with experience with imperative languages should be able to pick it up. Learning the language itself cannot be a real barrier. The barrier seems to be the enormous amount of legacy code that has to be digested and understood. But wouldn't that barrier be pretty much the same regardless of the programming language. I mean, if it were 800 billion lines of Perl code, would that make the problem any easier? So isn't the real problem that we have 800 billion lines of legacy code that needs to be understood and maintained; it just happens to be written in COBOL?

JohnFen 4y ago
You're not thinking wrong. COBOL is, compared to modern languages, very straightforward. It's also very different, though, and so it can feel alien to programmers who only know the new stuff.
- rbanffy 4y ago
  No direct experience with either, but, from what I understand, a COBOL application written to run in CICS looks a lot like a serverless app, with the difference that the company owns the multi-million dollar server.
  - JohnFen 4y ago
    This is sorta true. CICS is a whole different topic all by itself, and is independent of COBOL. I've written CICS applications in COBOL, C, C++ and even Java.
altacc 4y ago
You raise a good point. I can read COBOL to get an idea of what it is doing and how it is structured takes a little getting used to, but so do most languages. However, in my company (insurance) we have 3 COBOL systems (thanks to mergers) and one is on a rapid track for decommissioning not because it is COBOL, but because it is COBOL written in an obscure framework that was never popular and also coded in a non-English language, requiring knowledge of that language to understand the business logic. We can outsource some mainframe maintenance but not that one. The other mainframes will be around for at least the next 10/15 years.
SoftTalker 4y ago
COBOL the language is pretty simple, you’re right. I learned it in a few weeks in my first job out of college in the early 1990s. Even today, you can grab Gnu COBOL and learn the language. What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know.
- poulsbohemian 4y ago
  >What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know. This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainframe systems to be that difficult to learn (it's all basically batching, queueing, scheduling...) but without access to a mainframe, it's kind of a non-starter to actually get hands-on with any of this stuff. IE: thanks to the multi-decade shift to open source, we've got generations that have that skill set because it was accessible.
  - SoftTalker 4y ago
    Yeah it was over 30 years ago. I’m sure with more experience it might have been easier conceptually. I didn’t have any trouble with COBOL but found the whole mainframe environment to be rigid, crusty, and difficult to understand and use compared to the Unix systems I had used in school.
    - geysersam 4y ago
      I don't understand the need for "mainframes" in industries such as banking. Isn't a mainframe just a beefy server? I get that 40 years ago it made sense for a bank processing thousands of transactions per day to have a big computer to do that. But today that could be done on a laptop with a Python script. Has the compute needs really grown proportional to the speedup of the hardware?
ipaddr 4y ago
Your experiences aren't as straightforward as moving from perl to php but sure anyone can pick it up but it is a journey. I remember finally getting jcl language clicking for me and feeling like I accomplished something.
markphip 4y ago
Some other good points have been raised about what makes it complex, I will add another. I never learned Cobol, but I learned programming in the 90's on the AS/400 where Cobol and RPG were the primary 2 languages. I obviously used RPG. They are both easy to learn and powerful for what they were meant for but they are also commonly used to create massively monolithic programs where massive transaction programs are all written in a single file or with a lot of "copybooks". It makes it a lot harder to reason in your head what is going on as well as the side effects. Things like unit tests are just non-existent so it is just difficult to make changes because of the potential consequences. Especially when these monoliths are handling such important data. We wrote our RPG in a very API driven fashion where we avoided monoliths. I think you pay a small performance penalty for this but it always made our code easier to maintain. Of course it also takes a very long time to compile these programs so the Edit/Compile/Debug cycle is not fun or productive.
agumonkey 4y ago
data definition syntax is quite strange at first but conceptually there's nothing special and yeah legacy code of really sauron like
zerd 4y ago
I only have minor experience with COBOL, but in my mind the issue is that those 800 million lines of code don't have a single unit test, because testing COBOL is really hard. Which makes it dangerous to do any refactoring. Specifically the snippets I've seen do some in-line SQL to get its data, some business logic and then updates. The logic is rarely in a procedure that takes parameters, because that doubles the number of lines of code you need. So the only way to test it is to bring up a database, insert some test data, assert and clean up the database again. Which is a lot harder since "insert some test data" gets complicated because of different constraints and triggers etc. Then running it regularly is harder than it should, there's no SQLite equivalent database so you typically need to run it on a mainframe etc. I've worked on replacing a piece of functionality from COBOL to Java, and I was working from the business requirements that was basically a large spreadsheet of conditions and results. E.g. if age > 67 and not retired but have more than 3 kids, etc then this value. The code I wrote was gnarly because of all the combinations of different conditions, nested ifs 3-4 layers etc. And then there was ambiguity if multiple conditions hit, which one took precedence. I asked if I could look at the equivalent COBOL and the actual logic was about 10 lines long (not including headers, comments etc). Wish I had seen that before I started coding. It was quite readable and well commented too. So the actual language isn't _bad_, but the lack of tooling around it is severely lacking.
- nickpeterson 4y ago
  I know hindsight is 20/20, but that feels like the perfect setup for a rules engine like Drools.
edw519 4y ago
So isn't the real problem that we have 800 billion lines of legacy code that needs to be understood and maintained; it just happens to be written in COBOL? No. 800 billion lines of COBOL = 1 million lines of BASIC A gross exaggeration, of course, but after 7 years of COBOL, I discovered BASIC and instantly became 10X of my former self. I would never go back. I get enough overhead from my bosses. I don't need it from the tech too.

JohnFen 4y ago

You're not thinking wrong. COBOL is, compared to modern languages, very straightforward. It's also very different, though, and so it can feel alien to programmers who only know the new stuff.

rbanffy 4y ago
No direct experience with either, but, from what I understand, a COBOL application written to run in CICS looks a lot like a serverless app, with the difference that the company owns the multi-million dollar server.
- JohnFen 4y ago
  This is sorta true. CICS is a whole different topic all by itself, and is independent of COBOL. I've written CICS applications in COBOL, C, C++ and even Java.

altacc 4y ago

You raise a good point. I can read COBOL to get an idea of what it is doing and how it is structured takes a little getting used to, but so do most languages. However, in my company (insurance) we have 3 COBOL systems (thanks to mergers) and one is on a rapid track for decommissioning not because it is COBOL, but because it is COBOL written in an obscure framework that was never popular and also coded in a non-English language, requiring knowledge of that language to understand the business logic. We can outsource some mainframe maintenance but not that one. The other mainframes will be around for at least the next 10/15 years.

SoftTalker 4y ago

COBOL the language is pretty simple, you’re right. I learned it in a few weeks in my first job out of college in the early 1990s. Even today, you can grab Gnu COBOL and learn the language. What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know.

poulsbohemian 4y ago
>What takes longer is understanding the whole architecture of mainframe software. JCL, CICS, etc. It’s quite foreign to anything you learned about programming for Unix. And there really aren’t any free or open-source resources to learn it, as far as I know. This could be what you mean, but isn't the problem here one of access? I know just enough about JCL, CICS, etc to be dangerous, and never found any of the mainframe systems to be that difficult to learn (it's all basically batching, queueing, scheduling...) but without access to a mainframe, it's kind of a non-starter to actually get hands-on with any of this stuff. IE: thanks to the multi-decade shift to open source, we've got generations that have that skill set because it was accessible.
- SoftTalker 4y ago
  Yeah it was over 30 years ago. I’m sure with more experience it might have been easier conceptually. I didn’t have any trouble with COBOL but found the whole mainframe environment to be rigid, crusty, and difficult to understand and use compared to the Unix systems I had used in school.
  - geysersam 4y ago
    I don't understand the need for "mainframes" in industries such as banking. Isn't a mainframe just a beefy server? I get that 40 years ago it made sense for a bank processing thousands of transactions per day to have a big computer to do that. But today that could be done on a laptop with a Python script. Has the compute needs really grown proportional to the speedup of the hardware?

ipaddr 4y ago

Your experiences aren't as straightforward as moving from perl to php but sure anyone can pick it up but it is a journey. I remember finally getting jcl language clicking for me and feeling like I accomplished something.

markphip 4y ago

Some other good points have been raised about what makes it complex, I will add another. I never learned Cobol, but I learned programming in the 90's on the AS/400 where Cobol and RPG were the primary 2 languages. I obviously used RPG. They are both easy to learn and powerful for what they were meant for but they are also commonly used to create massively monolithic programs where massive transaction programs are all written in a single file or with a lot of "copybooks". It makes it a lot harder to reason in your head what is going on as well as the side effects. Things like unit tests are just non-existent so it is just difficult to make changes because of the potential consequences. Especially when these monoliths are handling such important data. We wrote our RPG in a very API driven fashion where we avoided monoliths. I think you pay a small performance penalty for this but it always made our code easier to maintain. Of course it also takes a very long time to compile these programs so the Edit/Compile/Debug cycle is not fun or productive.

agumonkey 4y ago

data definition syntax is quite strange at first but conceptually there's nothing special and yeah legacy code of really sauron like

zerd 4y ago

I only have minor experience with COBOL, but in my mind the issue is that those 800 million lines of code don't have a single unit test, because testing COBOL is really hard. Which makes it dangerous to do any refactoring. Specifically the snippets I've seen do some in-line SQL to get its data, some business logic and then updates. The logic is rarely in a procedure that takes parameters, because that doubles the number of lines of code you need. So the only way to test it is to bring up a database, insert some test data, assert and clean up the database again. Which is a lot harder since "insert some test data" gets complicated because of different constraints and triggers etc. Then running it regularly is harder than it should, there's no SQLite equivalent database so you typically need to run it on a mainframe etc. I've worked on replacing a piece of functionality from COBOL to Java, and I was working from the business requirements that was basically a large spreadsheet of conditions and results. E.g. if age > 67 and not retired but have more than 3 kids, etc then this value. The code I wrote was gnarly because of all the combinations of different conditions, nested ifs 3-4 layers etc. And then there was ambiguity if multiple conditions hit, which one took precedence. I asked if I could look at the equivalent COBOL and the actual logic was about 10 lines long (not including headers, comments etc). Wish I had seen that before I started coding. It was quite readable and well commented too. So the actual language isn't _bad_, but the lack of tooling around it is severely lacking.

nickpeterson 4y ago
I know hindsight is 20/20, but that feels like the perfect setup for a rules engine like Drools.

edw519 4y ago

So isn't the real problem that we have 800 billion lines of legacy code that needs to be understood and maintained; it just happens to be written in COBOL? No. 800 billion lines of COBOL = 1 million lines of BASIC A gross exaggeration, of course, but after 7 years of COBOL, I discovered BASIC and instantly became 10X of my former self. I would never go back. I get enough overhead from my bosses. I don't need it from the tech too.