yes, rewrite them on a modern language!

Not by choice but rather out of desperation and necessity to continue to run the mission critical code, mostly in banking, finance, and it is also occasionally encountered in government services albeit its presence has greatly diminished in the last decade or so. Young developers have no interest in learning COBOL, and the old developers have alredy died several times, have been dug out of their graves several times and brought back to the frontlines, and there are no more of those to be had. So the mission critical code continues to run on the constantly upgraded mainframe hardware, sometimes having not been changed in a few decades.

Oddly enough, despite a few large scale attempts to come up with automated COBOL -> whatever language migration / translation tools, they seem to have been largely fruitless. I think it was IBM that hired a bunch of hardcore academics in mid-2000's (?) to design and implement a COBOL to Java translator in Standard ML, and they even managed to produce something working. Unfortunately, then history becomes murky and trails off, and the eventual fate of that creation is an enigma of sorts. And, then, earlier versions of Java (before Java 8 anyway) were a horror to behold and would probably require a Java < 8 into Java >= 8 translator, so…

Funny thing, I worked on a project with a mainframe division, that replaced a crusty old COBOL-based mainframe app with... an RPG mainframe app. In the 2010s. Ostensibly because we could leverage existing knowledge from other divisions under the same parent company, but really because of politics, as these things normally are.

Cobol was a modern language 50 years ago. Python will be an ancient language 50 years from now. What do we do? Keep rewriting everything every 50 years?

And those ancient Cobol codebases actually have a big advantage: they've been maintained for so long that all the major bugs have been virtually eliminated. Creating a new system from scratch means another 10 to 20 years of maintance until the new system reaches the stability of the old one.

This is no joke. Given that most of the Cobol running today is running on mainframes at banks and card networks and the like, "a new bug" may translate to a few hundred thousand dollars of losses.

There's no point in building a new house of cards every few decades.

Is there any proof for such a statement? Has anyone seen business applications written in COBOL running on any thing then maybe a few mainframes in a few US agencies/corporations that haven't been replaced simply because they aren't broken (yet!)?

I know there's tons of Fortran and some PL/I code that will never be translated in any other language anytime soon because it's just good the way it is, but COBOL? I'm starting to think that this whole "COBOL will still be around in 100 years" is an urban myth...

Its this. If someone is doing greenfield z/OS development, I would assume they are probably using a more modern language (IBM highlights Java and C/C++ support on z/OS), not COBOL. But there is tons of legacy code in COBOL – much of it that was never well-documented. Sure, there’s fewer available COBOL programmers, but in many cases the orgs with these systems have also lost most of the people that were serving as living documentation, which is not great when the system is operating in near-steady-state, but becomes a critical problem when it needs new changes. So, the COBOL programmers they tend to need are for code archeology, temporally-displaced mind-reading to understand the original intent of code and diff it with emergent requirements, and maintenance on legacy systems.

The only reason COBOL isn't dead is because it is legacy (or, rather, because there is mountains of -- often undocumented, untested, and with requirements and domain knowledge largely lost and buried in the code -- legacy code written in it.)

And that code didn't have security or best practices (including things like loosely-coupled components with well-defined purposes) kept in mind when it was first written, which makes updating it in a manner which respects security and best practices difficult, at best.

The new code being written in COBOL is largely extensions and updates to existing legacy systems.

No doubt there are some exceptions, but they are a small fraction of what is going on with COBOL, which is itself a shrinking niche in programming overall.

That's true, but it's a hockey stick / logarithmic thing. When I started coding, the BASIC and COBOL technologies were waning-- still bringing in paychecks, but it was clear that their peak was a few years in the past.

There are lots of people right here on these forums using technologies today that are in the exact same situation. Citing these examples by name usually erupts into a flame war, but for sake of illustration, a good example might be PHP.

You might not start a project in it, but goddamn I bet you could make a boatload of cash doing consulting work to keep ancient COBOL systems running. Even today that's pretty lucrative business if you have the skills and connections.

Exactly. My first job out of university in 1996 was with the Canadian government. One of my first tasks was to update a COBOL program that had originally been written in 1972. I left that job in 1997, but I doubt the program I updated has changed much in the 24 years since, so it's at least 48 years old at this point.

Uh… sure? What would you consider an acceptable minimum amount of time to be after which rewriting a large but fairly critical codebase to modern standards becomes acceptable?

> And those ancient Cobol codebases actually have a big advantage: they've been maintained for so long that all the major bugs have been virtually eliminated. Creating a new system from scratch means another 10 to 20 years of maintance until the new system reaches the stability of the old one.

That's not quite fair. Having a known good code base while porting means that you can just rewrite the existing algorithms in the new language and then run some automated tests to make sure you get the same output from the same input across both systems. Unless you're doing a black-box rewrite for some reason, you're not really throwing away all fo the maintenance done on the existing system.

You underestimate the amount of COBOL code that is still out there running our daily lives:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

Are they alive by gumby's definition of alive? Is anyone beginning new codebases in COBOL or PL/I, even on mainframes?

This is funny to me, because the where I'm working right now, they have teams building entirely new projects in COBOL. The reason is that it's a company with a very high average age and incredible secondary benefits for baby boomers (old contracts, young people get ripped off), so they have an army of COBOL developers while there's a shortage for pretty much every other type of dev.

For many big COBOL systems that’s long past; in many cases the programmers that were coming on board when that generation retired are near retirement.

That's really not my experience.

I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving.

We replaced COBOL code... With more COBOL.

> Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.

Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable.

---

Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.