Are people still using it? I thought COBOL is extinct like dinosaurs
Don't hate COBOL until you've tried it
31–40 of 139 posts
Re: Don't hate COBOL until you've tried it
#32I'm curious about something. Why this:
if shipping-method 'FX'
move normal-ship-date-yyyymmdd to expected-shipping-date
else
move nextday-ship-date-yyyymmdd to expected-shipping-date.
if shipping-method = 'FX'
move nextday-ship-date-yyyymmdd to expected-shipping-date
else
move normal-ship-date-yyyymmdd to expected-shipping-date.
Re: Don't hate COBOL until you've tried it
#33One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on An ex-colleague used to work for a major US insurance company, and this is what he told me: They had a bunch of products, and due to the state-by-state nature of US insurance regulation, they had a slightly different version of each p…
That's interesting. It's a form of adverse selection. The least maintainable and readable languages end up sticking around the longest whereas the clear, concise and readable languages are likely to be replaced regularly with the shiny new thing...
Re: Don't hate COBOL until you've tried it
#34I have regualr talks with people who were using COBOL a while ago. There are things were cobol is good : 1/ COBOL run in closed environments. This allows these to be rock solid. (no such thing as a dependency nightmare). You don’t have such a thing as different version of Java on your testing and production environment. 2/ COBOL forces you to mix concerns : DB access, file I/O, business logic. This is sometimes usefu…
I don’t think COBOL does force you to mix concerns. You could create sub modules / services which you call from a main program to do things like file writing or database reading.
Java doesn’t also say you have to separate concerns. You could easily write a single method which mixes business logic and IO (file and DB)
When writing a batch program you need a balance between understanding it, making it efficient and reliable and promoting re-use (e.g. if many batch programs want the same behaviour break it into a reusable module). COBOL still has dependencies too, so each program is rarely written in isolation and you have to co-ordinate with other teams to ensure their module versions are in sync with yours.
The thing that has always let COBOL down for me is the lack of automated testing.
Re: Don't hate COBOL until you've tried it
#35One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on An ex-colleague used to work for a major US insurance company, and this is what he told me: They had a bunch of products, and due to the state-by-state nature of US insurance regulation, they had a slightly different version of each p…
This. Suppose you want to rewrite. Your task is to create a new, cleanly written program in a new language that produces the same output as the old, slightly messy COBOL.
It must work identically for all appropriate inputs. There is no documemtation of the code and insufficient documentation of what combinations of inputs must be supported. No one understands the business logic fully. And there are 500,000 lines of copy-paste-modified code to convert. Any screw-up will likely cost more than your annual salary. How do you sell the risk-vs-reward of the rewrite project?
COBOL will outlive us all.
Re: Don't hate COBOL until you've tried it
#36I'm curious about something. Why this: if shipping-method 'FX' move normal-ship-date-yyyymmdd to expected-shipping-date else move nextday-ship-date-yyyymmdd to expected-shipping-date. And not the following? if shipping-method = 'FX' move nextday-ship-date-yyyymmdd to expected-shipping-date else move normal-ship-date-yyyymmdd to expected-shipping-date. The latter seems clearer to me, and the line below (regarding the…
Probably taste: normal case first, special case last, regardless of what the respective comparison clauses look like.
Re: Don't hate COBOL until you've tried it
#37Earlier quoted context omitted.
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on An ex-colleague used to work for a major US insurance company, and this is what he told me: They had a bunch of products, and due to the state-by-state nature of US insurance regulation, they had a slightly different version of each p…
This. Suppose you want to rewrite. Your task is to create a new, cleanly written program in a new language that produces the same output as the old, slightly messy COBOL. It must work identically for all appropriate inputs. There is no documemtation of the code and insufficient documentation of what combinations of inputs must be supported. No one understands the business logic fully. And there are 500,000 lines of c…
Where I work I heard the IT dept literally had to pull developers from retirement to make a change to the payment systems. Sadly pulling people from retirement is an option that the company will not have forever. At one point there will be no other choice but a complete rewrite.
Re: Don't hate COBOL until you've tried it
#38> 5 billion lines of new COBOL code are written every year.
Are you sure about that? Sounds like rather a lot.
Re: Don't hate COBOL until you've tried it
#39One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
Because the knowledge required to fix, update or port these programs is almost completely owned by the programmers that developed them, who are in the process of retiring or are unwilling to share knowledge for (justified) fear of losing their job.
Regarding "how complex can these programs be", these programs run core operations for banks and insurance companies, so you can probably imagine the amount of hidden business logic and technical hacks that have stacked up over decades of operation and changes. This will not surface in requirements gathering meetings without A LOT of blood, sweat and tears. The alternative would be to reenginer the company's processes before the building the software to support them, but that would mean a lot of change and that tends to be harder than most software engineering endeavours.
Not only are these programs complex (projects to re-implement them from scratch in J2EE would certainly be measured in years), but they are mission critical and the organization cannot afford to live without them or something 100% equivalent.
There was a lengthy discussion about this on HN some time ago: https://news.ycombinator.com/item?id=12096250
Re: Don't hate COBOL until you've tried it
#40Earlier quoted context omitted.
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on An ex-colleague used to work for a major US insurance company, and this is what he told me: They had a bunch of products, and due to the state-by-state nature of US insurance regulation, they had a slightly different version of each p…
This. Suppose you want to rewrite. Your task is to create a new, cleanly written program in a new language that produces the same output as the old, slightly messy COBOL. It must work identically for all appropriate inputs. There is no documemtation of the code and insufficient documentation of what combinations of inputs must be supported. No one understands the business logic fully. And there are 500,000 lines of c…
I work on cobol migrations (or anything mainframe more correctly) to x86. I've never seen a rewrite of a real application that actually worked. Some have tried but ended up throwing the towel.
We've taken a different approach, by being binary compatible. Basically we rewrote a CICS/IMS/etc, as well as some z/OS layers.
Depending on the clients, some want to stay in cobol, but others want to modernize, but in a controlled and progressive way.
A complete rewrite is out of the question, but you can try to do it in steps.