Don't hate COBOL until you've tried it

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

You'd be surprised. The business rules and exactitude of results can be documented in 1000s of pages.

No problem and glad to be of [di]service. I was familiar with the URL you posted, and probably should not have commented as a reply to you, but there you have it. :)

10 is EOF, 0 is successful read. Not that it actually matters, your point is perfectly valid. You can use sort off boolean operators thats toggled on based on the value in variables.

Outgoing web requests are usually done via either a program in some other language that you call from the COBOL application, or via DB2s built in functionality by running it as an embedded SQL section in your program. Why the heck web requests are handled by the relational database is.. Well I mean it feels odd, but by doing it that way they added the functionality to both zOS and IBM i at once. And old developers don't have to learn all to much new stuff to do it.

Also, while the COBOL program works with a static set of files with static filenames. Those names can point to any file by various overrides done in either JCL on the mainframe or CL on the IBM i/AS400. Regarding the file formats, you can read the file into different working-storage defined variables, so each row doesn't have to be identical field length/position. In short, COBOL is just one part of the solution. Various "scripting" languages play a large part in defining what files go in and out. And none of them are available outside of the actual mainframe/midrange environments. Most data is gathered from relational databases anyway nowdays, and embedded SQL, just like in PHP webpages of yesterdays web, is whats used in newly developed programs.

But all in all, yes it's a rather cumbersome language, for any sort of sane string handling you have to revert to embedded SQL. But most problems you have to write programs to solve can usually be broken down into smaller problems. Then just chain programs to handle it. The language itself is usually just a bit of a bother, but the age old programs written 20-30 years ago written by developers of varying degrees of sanity who had no requirements on them to document their work is what makes the job a pain.

> 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 expensive that no one wants to rewrite them in a modern language?

You would be utterly shocked.

I did some COBOL work for a bank.

Most of the new code they write is in C++.

However, COBOL was still a huge part of their stack, and they still had several heavy duty mainframes that it ran on, and maintaining that was part of my job.

For an example of how much COBOL was written back then, and how huge the technical debt to replace it would be:

* The interbank transfer system alone was ~750,000 lines of COBOL.

* It handled around 1.2million transactions every three seconds. That's not capacity, that's real world data.

* They had less than five minutes of downtime in the last twelve months, and that was considered poor.

It's a mammoth task to replace the system, and getting transactions from the old to the new without incurring a huge overhead is nigh impossible. And yes, dropped transactions can mean dropped customers, and big customers.

It's far cheaper to hire and train programmers in COBOL, than to rewrite everything. COBOL and Fortran have millions of lines of code in use, and such frequent use that replacing them may cost more than the lifetime of returns would give.

> 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 product for each of the 50 US states. And then, for every one of those different versions of those products, they had a separate suite of COBOL programs to manage them. And, all these COBOL programs basically did the same things, but all with slight variations due to the different rules of each state's insurance regulators. So they basically had hundreds, maybe even thousands, of separate COBOL programs to maintain, a mess of horribly repetitive code. Their problem with moving off COBOL was not that any of the code was particularly complex, just that there was so much of it, and trying to rewrite it into another language (or, maybe more sensibly, translate it into some sort of business rules engine or insurance policy automation product) would take major effort and run a big risk of getting something wrong in the translation. (He worked there more than 15 years ago, so things at this insurance company might be very different by now.)