[cdumler]

There are plenty of ways to port out of COBOL, none will work.

I once interviewed for a COBOL position. It was a typical large financial institution. It was a lead position that wanted a migration plan out and then would lead to a team for me. I have a lot of systems integration and information management knowledge. I have worked on planning multi-year projects and migrating out of large systems like this before. The interview went well, and afterwards they showed me around the place and what they were doing.

I sat down again in the office with the hiring director, and I enquired about how long he has been with the company and what he has been working on. Turns out he had been hired in five years ago and had already attempted this once before without success. I knew without a doubt why they didn't have success, and it had nothing to do with COBOL.

Financial companies are highly risk adverse. COBOL developers know this. COBOL developers know that if the shop isn't COBOL their job is at risk. So, COBOL developers will constantly introduce "what about this risk" issues, which then must be considered in committee; thus, the company is eternally paralyzed. The fact that the director couldn't make it anywhere in five years meant nothing was going to change.

As I recall, I checked in a few years later and they were still in the same place. I suspect it might have been a decent place if all I wanted in life was a paycheck. They were nice people.

[heisgone]

Indeed. Financial companies are in a difficult position. COBOL was invented for them 60 years ago. Then, they were the primary users of computers. Now, they are just one users among many and no language is going to be invented for them specifically. Instead, you have thousand of enterprise software companies that are trying to market them all sort of complex solutions and keep the gravy trains coming. Financial companies would need to take the matter in their own hands and invent their own modern language but their culture doesn't allow it. Financial companies have extremely long term needs but are unable to put together the kind of long term project that would allow a cohesive language to emerge. Instead, they buy into ridiculous short term thinking like Agile. If maintaining COBOL code from 30 years ago is costly, imagine what today's business software 30 years from now. I have seen critical information only a few years old being lost among insurance companies. Consequential bugs that lead to people losing money. It's scary to think that those systems are guardian of our finances.

[petejodo]

I'm curious what features this hypothetical modern language would have that would be particular suited for financial institutions. This thought has piqued my interest

[heisgone]

The language need a fairly limited set of functions to support actuary calculations. You don't want things to get out of hand, with side effects, complex libraries, and so forth. Things need to be robust. Language like PL/SQL and SAS were fine but the systems are a pain to deal with and require technical knowledge that actuaries don't always have. Python is no emerging in the field by default because it allow quick prototyping but I would have concerns of the long term stability and maintainability of anything built out of it.

[8eye]

maybe put a framework on top of COBOL call COBOL-x, there use that as your starting point.

kind of joking/not joking, marketing has gotta play a huge role in that transition.

[phendrenad2]

Ironically enough, the way to get rid of COBOL is more of it. Democratize it. Right now, you can "learn COBOL" but you'll never get access to a mainframe environment or the actual COBOL compiler or the obscure database used by hospitals and banks, because they're too expensive. So, make emulators so that non-COBOL programmers can play around in a COBOL world without going to work for a bank or hospital. The problem with COBOl is, it's all-or-nothing. You're either in the COBOL world or you are not. But if you add an onramp, Java/C++ programmers will maybe make COBOL versions of their libraries. There will be more people going to COBOL StackOverflow. There will be more cross-pollination between COVOl and non-COBOL devs. More people will form businesses trying to bride the gap between COBOl and Java. Right now, only COBOL devs are trying to get out of COBOL-land. And their vendors will sell them overpriced solution. The Java developers on the other shore can only watch with fascination, they can't help.

[goto11]

Are these COBOL programs running on obsolete hardware, or are the systems virtualized these days?

I suspect the way forward for COBOL is to modernize the development tools around it, rather then rewrite the code itself.

[rad_gruchalski]

Have a look at Micro Focus compiling COBOL to .net and java. They’ve been doing this for minimum 11 years now.

[rovr138]

Obsolete hardware? Mainframes are still a thing.

[qwerty456127]

Why? I could never understand why do simple financial formulae coded in COBOL need some colossal computers and still choke on laughable volumes of documents.

I believe my almost-decade-old smartphone has more than enough computing power and bandwidth to process all the unemployment applications even if all the Americans would file them on the same day.

[krylon]

If you can deal with the price tag, mainframes are very nice machines in a lot of ways (scalability, availabity, storage). And if you're a large-ish bank or other financial company, chances are the amount of data you need to process and the requirements on availability you need to meet mean you're going to need something mainframe-sized anyway.

Plus, IBM and assorted companies treat backward compatibility religiously, so a random update to the OS or the DBMS breaking your application is pretty much unheard of. That kind of reliability is worth a lot to some companies.

The price tag is rather harsh, though.

[wedowhatwedo]

Mainframes aren't just about computing power. In a mainframe, almost any component or subsystem can fail with no downtown to the applications at all. That is worth the money and complexity to some people.

You don't understand mainframe systems well if you think they "choke on laughable volumes of documents".

The mainframe isn't the bottleneck in systems like this. It's all the stuff around it that wasn't designed to the same specifications.

[bitwize]

Because those simple financial calculations need to be done reliably, for many, many clients at once, without falling over. You can requisition redundant cloud instances equivalent to tens or hundreds of real-world x86 computers, or you can do it on a mainframe. My guess is the cost works out about the same either way.

(Insert image here of IBM System z as Omni-Man, pointing to two fighter jets in the distance marked "AWS" and "Azure" and saying "Look what they need to mimic just a fraction of our power!")

[pankajdoharey]

Costs probably dont work out the same, if it were true why is IBM offering its cloud solution on x86 hardware and not mainframe?

[rovr138]

Why is their cloud on x86?, an easy argument is because mainframes don’t run x86 or ARM instruction set, https://en.wikipedia.org/wiki/Z/Architecture

How will people use it?

[pankajdoharey]

Its not about the complexity of the solution its the scale, mainframes batch processing was the go to solution before the advent of modern hardware. Mainframes were build for resilience but nowadays we have embraced fail early, fail fast to circumvent those scenarios.

[scott_s]

Rock-solid reliability for large-scale transaction-heavy workloads.

[rovr138]

Reading all these replies, my takeaway is that there’s a lack of understanding in the internal structure and architecture of a mainframe and how it works.

Not just code, but how things are built and connected.

[bidirectional]

> Financial companies are highly risk adverse.

The financial companies running COBOL are. Generally it's quite boring, staid retail banking or the like. If you're a developer who sits on a trading desk writing code which goes straight into production for a trader, things get much more risky.

[michaelcampbell]

I worked for a Wall St. trading firm in the early 90's, as a greenfield developer doing apps on Sun Sparcstations in cfront based C++ using Motif.

Two things shocked me at the time.

1. The company had a LOT of systems running in COBOL, for which they had lost the source code to the vagaries of time.

2. One of the big projects at the time was because of the lack of source, and the devaluation of the Italian Lira, they needed a "splitter"/"unsplitter" to take particularly big bond trades in Lira that overflowed the (eg) `PIC 9(9)` data clause for the total price, split them up into smaller trades, run them through the existing clearance system, and re-aggregate them into 1 trade after clearing.