Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com)

COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

Comments

Why not?

[__aaclcg7560]

Java is getting long in the tooth. Time for it to become the new COBOL.

Re:Why not?

[Slicker]

Java is far more likely to go the way of the dodo bird than is COBOL. COBOL is well-optimized for business data processing. It's a fine language. What does Java have over it? COBOL is many multitudes easier to learn, code with, read, and modify. Programming languages started getting more complex, harder to learn, and use starting with C++. And OO design and programming has failed in each and every goal for which it was originally proposed. I understand that most modern programmers have learned OO from the start and have difficulty thinking of problems differently but contemporary COBOL supports OO, too... just not often used.

Re: Why not?

[Anonymous Coward]

Cobol is a horrible business language. Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.

Just because it can add and subtract doesn't make it great.

It just makes it basic.

Re:Why not?

[Ace17]

> Programming languages started getting more complex, harder to learn, and use starting with C++.
Just because a language is easy to learn doesn't make it easy to use.
If this were the case, we would all be programming in Brainfuck!
And it's a lot more easy to write a working program in Java than in C (hell, lots of Java programmers don't even know what a memory leak or a "link error" means)

> And OO design and programming has failed in each and every goal for which it was originally proposed.
Despite OO turning out not being the promised silver bullet (code reuse, natural design, ...), OO was a huge improvement and still is a huge success.
If you're not convinced: https://www.quora.com/Was-obje...

Re: Why not?

[slack_justyb]

Holy shit dude. I'm a vet C++ programmer and the last three years mobile developer for warehousing company. However about a year before my current job, I worked in an exclusive AS400 shop. RPGLE, COBOL, CL, you name, it was still using the stuff from back in the day.

The system was incredibly fragile and had insanely complicated builds with the labyrinth of binding directories, dependencies, the constant service program signature violations. Customers demanded new functionality and the system just had trouble keeping up. Old programmers would code crap like RPG still lacked arrays with abusing subfiles. They'd swear by using numeric indicators versus the new fancy types. Yeah, because IN73 being on tells me that I totally need to refresh the data on the screen. Eventually the company fired all of the RPG/COBOL programmers because they could never keep up with demand. They were short order replaced by an off the shelf solution and any new work was contacted out. I stayed on a few months more because I understood EDI and they needed someone to get that all setup on the new solution. Oh and it was Java based.

Point though, you sound exactly like those old guys. OO over complicates crap and you don't need all that fancy stuff, blah blah blah. I work and coded DDS, SQL, RPG, and COBOL with those people for five years and I knew their mentality was just setting them up for obsolescence.

The tech industry is brutal man and you've got to be a person keenly adept to rapidly adapt or you'll find yourself quickly no longer employed and lacking serious skills to find your next job. Two, besides myself, out of our group of nine found another job. Those two for jobs doing AS400 maintenance, took a pay cut for it, and RPGLE programmer with the State Government, smaller hit to the paycheck than the first guy. The rest of the group have nothing but their retirement savings to dip into. We all lost touch over the years but last I heard two or three more for jobs finally but had to eat the cost of moving elsewhere.

Seriously, the only thing that kept me above water was that I had skills in C++ and Java. And since then I've picked up containers with Linux and node.js plus Python and some big data (Hadoop and shit) just to what I assume is stay current.

That thinking of yours isn't a good kind in this industry. But I get it, when I worked with the AS400 folk, I had just turned 30 and so I was seen as the young whipper snapper etc. I had just left my last job of several years doing C++ and every gray beard (literally) there thought I was there to "think outside the box" and "shift paradigms" and really I was just there to mostly get a paycheck. Learning RPGLE and COBOL was fun but man those old guys they scoffed at any suggestion to get off a green screen or to make their monolith more modular. They would literally say, "stupid hipster just trying to make everything harder than it needs to be." And let me tell you, I didn't dress like a hipster.

Anyway, I know, way more memory lane than anyone asked for, but seriously, those guys' thinking ultimately led to their firing. I've worked in a few development teams but not a lot so can't say with a lot of experience, but my gut tells me that had they been just a wee more open to change and newer technologies, they might still be working at that place.

Re:Why not?

[Z00L00K]

OO is good for cases where you have use for multiple instances of known items. That is applicable to many solutions but it comes with a cost too. That cost is added overhead caused by inheritance since not every object uses all stuff it inherits, only parts of it - especially when the model is built by many persons that need a very general solution to a problem.

Maintainability is also a problem when you get stuff that's obsoleted - it may be impossible to remove stuff from the parent objects because at least one inherited object still seems to use it. So code rot can be a problem in a system where people don't have full understanding of what was written a decade ago.

Re:Why not?

[DrXym]

COBOL is an arcane, baroque and verbose language which serves a very singular purpose in business - processing records. I fail to see how it's "easier to learn" unless all you ever wish to learn in computing is how to process records on mainframe computers.

If you learn computing because you want to write a game, or a website, or an application, or manage a database. i.e. if you learn for the reasons that 99.99% of people learn for then COBOL is unsuitable. Any general purpose language would be more suitable than COBOL for learning. If Java doesn't float your boat then there are the likes of C#, Python, Go, Dart, C++, Ruby etc.

It's hard to see how you think OO has "failed" given that virtually every piece of modern software uses it implicitly or explicitly.

Re: Why not?

[Anonymous Coward]

COHBOL? Common Horrible Businness Oriented Language?

You're wrong about integration. On the legacy platforms that we're going to be interested in there was and is excellent inmtegration. I used to work on Data General and know that Cobol supported a number of DGs proprietry databases including heirarchical and relational.

The context here is about maintaining old s/w verses replacing with new. Sure if you're prepared for ironing out all the issues with you're new s/w then go for it but the s/w here is reliable and still basically useful, it just needs maintenance.

I've seen organisations replace old but good s/w with new s/w tht did the same job but was 'modern' and had more issues, it needed more resources and ultimately did no better a job.

Re: Why not?

[michelcolman]

Duh, the first version of C++ was a precompiler that turned it into C. So yes, C is indeed quite obviously capable of supporting the OO paradigm. C++ is just syntactic sugar and optimization.

Re: Why not?

[bws111]

What gives you the very incorrect idea that the 'old' clode is single-threaded? IBM mainframes have supported multi-processing since 1965. Current models have up to 120 CPs in one image. And as for performance - there you are WAY out in left field. Many COBOL programs involve decimal operations, and in COBOL that translates to HARDWARE decimal operations. If you think you are going to get anywhere NEAR that performace with Python (snort), I'll have what you're smoking.

COBOL isn't hard to learn

[Anonymous Coward]

COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.

Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job. COBOL-coded systems are for back-end processing, not for customer-facing systems.

Re:COBOL isn't hard to learn

[MightyMartian]

Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.

Re:COBOL isn't hard to learn

[Kjella]

Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.

As long as you have a real fall-back so your career doesn't dead end. What can easily happen is that you do X then more of X because it's the only place you get a salary/career development until you've done X so long nobody will really hire you for anything else. I see this with for example some SAP consultants, essentially SAP customers want to hire you for your SAP experience and the rest of the world doesn't care that you have a general IT degree 5 or 10 years ago because your experience is all SAP-specific and they don't run SAP.

Now they're probably safe since that ERP is burrowed so deep into many companies they'll never get out, but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position. That is if they'll even hire you or if they'd rather have a recent college graduate. Or you might have to relocate to find one of those increasingly rare positions that actually value your COBOL experience, which of course only makes it harder at the next crossroads.

If you write cell phone apps as a hobby and can show them a portfolio or something, maybe you'll get away with it. No, you're not a dinosaur who only knows an outdated language and best practices from 50 years ago. Or some other way to be able to transition away from that COBOL career more smoothly. Some of my older colleagues noted that the parking inspector at work used to be COBOL programmer some 20 years ago, they updated their skillset and apparently he didn't.

Re:COBOL isn't hard to learn

[maglor_83]

Referring to banks, not delivery drivers. The delivery company would use vans because it's far more efficient (ie cheaper). The bank would train COBOL devs because it's also much much cheaper than replacing a working system.

Re:COBOL isn't hard to learn

[Strider-]

Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates.

Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language. That is not what the discipline is about. What they should be doing is producing graduates that grok and push the concepts that underlie computing in general. They should have a good grasp of algorithms, object oriented design, logic, and so forth. The language is incidental. A well educated grad should be able to pretty much pick up any language, and view it as simply another syntax, potentially with slightly different grammar. In practical terms, a good CS program is far closer to being an applied discrete mathematics degree, rather than a programming degree.

Re:COBOL isn't hard to learn

[Anonymous Coward]

I went to community college and we had an Associate's track in, basically, mainframe computing. AS/400, JCL, COBOL because we had several local firms that still maintained and ran mainframes (and last I checked, still do. I believe one tried to move to commodity hardware and rewriting the whole stack in Java, but I don't know if they finished that transition).

The problem with "just picking up COBOL" isn't necessarily the language, it's the whole system it's deployed on. There's no CLI that a Linux user would readily recognize (I found it easier to think of it like a BBS), the whole Jobs system is utterly alien to someone used to VAX/UNIX, etc etc. My local college also did a lot of that, but in the MIS department. The EE department started everyone out on VAX/VMS and Pascal, the CS department on C and qedit. :D They moved to Visual Studio not long after, though.

Re:COBOL isn't hard to learn

[Altrag]

I agree the article's claim is dumb, but not for the reason you suggest. Finding programmers is easy (at least if you're willing to pay a reasonable wage,) and teaching them COBOL is easy as well (any decent programmer should be able to pick up a new language within a week or two.. especially if they're hitting the ground running and have no choice but to learn it.)

The problem is the business logic. Banking isn't particularly simple at the best of times, and all of those ancient systems will have decades worth of hacks built on top of the base logic for whatever corner cases, hardware workarounds and other tweaks that have been needed over the years. A new programmer learning COBOL will have to be wary of those kind of hacks until they understand them. A programmer trying to port the system to another language/system on the other hand will have to understand those hacks all (nearly) at once in order to make sure they properly get replicated.

I don't really see any reason beyond simply "new is better!" to do this. By the time they manage to fully port and test the new system, they'll be wanting to rewrite it again in the next fad-language-of-the-day. I mean name one "top" language today that's been around for more than about 5 years and doesn't already have people crowing about how its past its expiry date and everyone should be rewriting all their code in some other language. There's the occasional specific domain where that happens (C++ for performance-centric applications like games, Fortran for sciency things, Matlab for mathy things and the such) but anything even close to general purpose? Few if any.

Re:COBOL isn't hard to learn

[vtcodger]

Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.

I don't think I'd have the patience to program in COBOL

But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".

Re:COBOL isn't hard to learn

[Tough Love]

All programming languages are tedious as fuck to use.

Cobol is more tedious than more fuck.

Re:COBOL isn't hard to learn

[outlaw]

COBOL is not your average Algol deriviative !

I'll grant the the 80-20% rule likely applies..

But things like Sequential vs Relative vs Indexed I/O, BCD (packed & zoned), multi-return option on PERFORM, etc...

I'd be more comfortable saying 'mediocre' instead of 'proficient'

Re:COBOL isn't hard to learn

[rickb928]

COBOL was ubiquitous in the financial industry before SAP's predecessor was someone's dream. COBOL will take 10 years to get rid of *if* all users begin concerted efforts to do so, these transaction processing systems are too important to just 'replace' without careful planning, development, and most importantly defend against feature creep and being engineered into failure.

SAP is a baby. COBOL is grand dad. And grand dad still gets out of bed, does his work, and does it well. There is indeed a market for fresh COBOL programmers, and a decade before they need to move on to a new platform.

In a world where we are cautioned that we will have multiple careers as the job markets change and adapt, it's ludicrous to pretend that programmers can't move on to new languages, new platforms, new challenges. What is being said is "it's cheaper to hire new grads than to hire retrained experienced workers". That is sharp practice. Not nice, but profitable. And not new.

Re:COBOL isn't hard to learn

[clintp]

COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.

All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.

I've worked in legacy software for a long time... and here's the thing.

Those COBOL systems aren't off-the-shelf modern framework-driven standard software packages. These packages were custom-built and tailored to the business needs of *that particular institution* over many years. You can't plonk down a credit card and buy a replacement; there's no github repository for that kind of code; you can't knock one out in a couple of weekends in a code camp.

That business' processes have co-evolved with that software for better or worse. Replacing it means rebuilding it around the existing business.

The programmers that work with this old cruft know the ins-and-outs of the system -- and if they're smart, they've learned the business, and the business owners *know* they know it. When the business decides to replace it, that's when the developer steps up and says "I'll do it, here's the plan." You go in as Jr. Programmer, you come out as Sr. Software Engineer.

In 30 years I've written (whole or in part) 2 payroll systems, 1 full-financial system (AP, AR, GL, etc..), 1 room scheduling systems, one freight routing system and one tax filing system. Each one (for its time) very modern, but based on older shittier systems that had to be learned and maintained before that.

Re:COBOL isn't hard to learn

[Anonymous Coward]

Even if students coming out of a course should grok code in general, that doesn't mean they have discipline-specific skills in COBOL necessary to allow them to deal with this kind of code. Some of that stuff is learned over decades.

It's entirely the bank's fault for not taking on young employees and teaching them these new skills, and putting them with the veteran programmers and guaranteeing their jobs for life, with good pay and conditions. They have no one else to blame.

Had they done this, it wouldn't be a problem. COBOL would just be the language that banks use - nothing else. Banks seem to feel it's the universities responsibility to churn out skills that they might want some day, but without paying either the universities or the graduates ( through employment ) for their services.

They still have time for this - all they need to do is pay enormous amounts to programmers willing to sit with and replace aging veterans. Good luck to them. I hope the banks choke on this.

When I studied, we were forced to learn COBOL for precisely this reason. No one was ever hired, or taken on, or otherwise employed out of it - It was just one of those "Industry want this, so we're teaching this" situations, but the truth is that industry only ever want experienced programmers, but they want them to gain that experience somewhere else.

When we see COBOL programmers paid 1 million per year, like high-flying executives, we'll know they finally realized their value. In the mean time, maybe a few more executives should be prosecuted when they have losses due to COBOL bugs and failures, for running systems they refused to maintain, with foreseeable outcomes.

Re:COBOL isn't hard to learn

[arglebargle_xiv]

Exactly, if there's a demand for it, it'll be fulfilled. The article reads like something written by some recent CS grad, lets throw out this horribly uncool, unhip code that nevertheless can handle three trillion dollars of transactions a day and has been going for forty years and replace it with something that some Indian subcontractors slapped together using Ruby and MongoDB.

In a past life I worked for a bank. They decided to replace their existing Cobol on IBM big iron with Java on... something that wasn't big iron. After several years work and tens of millions of dollars spent and even more than that lost due to problems with the new, modern replacement systems, they threw in the towel and made their modern system screen-scraped 3270s because that shit just works, and keeps on working. It's now all Windows-based at the front end, but everything in the backend is still Cobol on mainframes.

Re:COBOL isn't hard to learn

[harperska]

At my college the low level CS classes were taught using Scheme. The idea was to use a language that nobody would ever in their right mind use in the "real world" to teach basic concepts like recursion without the student getting bogged down by implementation details specific to a language. Higher level classes were taught in Java so that we would have experience with a 'real' language. Also, there are some concepts that are nicer to work with in a powerful modern language, rather than shoehorning them in to an obsolete language not designed to support them.

Re: COBOL isn't hard to learn

[Lorens]

Fretting that banks may have to pay to train software engineers to learn the tongue of their industry instead of getting to pay dirt cheap rates to retirees is very far from tugging at my heart strings.

There are banks and banks. I work at a hundred-year old bank where most of the COBOL programmers are between 30 and 45. The older ones have graduated to team lead, plain management, auditing, cost control, or other (presumably better-paying) posts. There are lots of people recruited out of school to work on COBOL (and Hadoop, and CICS, and Kafka, and OPC/TWS, and NodeJS, and if you only know one in two then you're not cross-platform).

This is good HR. There are people in HR whose job it is to plan out career paths and make sure on one hand that people don't get stuck with only outdated skills, and on the other hand that the bank doesn't get stuck with not enough people competent in a given skillset. If other banks don't have good HR, then I'm sorry for them but it's not my problem.

Yearly pay is not that great, but I have job security, I can go to the beach after work, and if you factor in that I have 56 weekdays off in a year it gets better... and bad pay is probably a consequence of having competent HR too.

Re:COBOL isn't hard to learn

[Z00L00K]

SAP is more likely to go the way of the dinosaurs than Cobol.

Which reminds me of this joke:

In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.

A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.

Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.

Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.

They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."

"Someone like me?"

"You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."

"What year is it now?"

"Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"

Re: COBOL isn't hard to learn

[TheRaven64]

That's the second post I've seen saying that COBOL has no unicode support, yet COBOL 2002 added unicode support and is widely supported (COBOL 2014, less so). If you're running on an IBM system, a bunch of the COBOL unicode operations are accelerated in hardware.

Re:COBOL isn't hard to learn

[TheRaven64]

Given that most of this code was originally targeting systems from the 1960's and 70's, I can't imagine there being an insurmountable number of lines of code

According to Wikipedia, Gartner estimated about 200 billion lines of COBOL code in 1997. To put that in perspective, that's more than the total amount of open source C code tracked by OpenHub.net. Can you imagine persuading someone to rewrite all of that C code in a newer language?

Re:COBOL isn't hard to learn

[goose-incarnated]

but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position.

You think that a systems migration won't need your legacy skills? You think that you won't pick up the skills for the new system during the migration?

Here's a more likely scenario: you do COBOL for 5 years and learn the entire problem domain that the COBOL system services. When the migration occurs with Java your knowledge will be indispensable, and you'll no doubt learn Java in the two years the migration takes to complete. At the end of the migration, you are still the expert in the problem and have new Java skills to apply your expertise.

It's exceptionally unlikely that the migration from COBOL will be so fast that you won't be able to learn the new implementation technology.

No.

[xxxJonBoyxxx]

>> Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

Er...that's pretty much been the story since the 1990's (if not earlier) on.

>> mostly maintained by retired programming veterans

Er...if they're "maintaining" then they aren't "retired". This whole article sounds companies that whine about not being able to find skilled welders, etc. Well, open your wallet and the talent will materialize - see "IT security" for an example.

Re:No.

[sgendler]

This goes out to all of those complaining about not being able to take more than 3 days off for decades at a time - why in heck are you still working for that employer? I've certainly never had difficulty taking vacations, and I've worked at fortune-5 companies and tiny startups and everything in between. If you are silly enough to stay in a job that is not meeting your requirements when there are so many options that would, you have only yourself to blame. If unfair vacation policies were costing such companies their talent pool, you can bet they'd find a way to accommodate you, just as they have found a way to accommodate those affordable indian employees you have all mentioned, who get 2-3 weeks at a stretch. Heck, these days, I tend to negotiate an exchange of salary for more 'european' quantities of PTO during the hiring process, and you can bet that if I've exchanged income for extra PTO, I'm damn well going to take it every year. If you are a valued employee, no employer is going to be able to limit your PTO. If you're not a valued employee, either become one, or find an employer who will recognize your value. Those are really your only options in a market economy unless you are going to form a union and force a contract on them - and good luck with that.

So, take the opportunity.

[msauve]

Anyone worried about getting outsourced, here's a opportunity - learn COBOL.

How about a 4th option ?

[psergiu]

How about a 4th option ?

Fscking pay to train people. If COBOL knowledge means means a good paycheck and job stability - lots of people will want to do that.

I mean hydroponics and grow lights are all the rage now but i hear of no plans of migrating all the existing old-style dirt-based and sun-lighted vegetable gardens to that. Why ? Because people are still learning how to dig the dirt out in the sun.

BUGS

[AK Marc]

COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.

Re:BUGS

[Anonymous Coward]

COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.

Said the person with very little knowledge of modern COBOL environments !

I'll grant that COBOL is not like PL/I, where 80% of the programmers know = 20% of the language.

However, COBOL has one of the richest I/O layers (ok, on par with PL/I) around.

Caveat Emptor - I intensely dislike the language (to damned verbose), but it and PL/I do pay fund my paycheck (just call me 'Dinosour Bob').
But the COBOL I learned was circa 1970s, when even COMPUTE was frowned upon (in school) ... And Databases where not yet relational !

Modern COBOL has OO patterns, JNI integration, XML/JSON tooling, ... All to deal with the option of:
    * Keep the business logic in COBOL
    * Provide the ability to work with newer toolchains (Java, XML, JSON, ...)
So there is interoperability betwixt the green-screen and non-green-screen luser.

It will probably never die

[El Cubano]

Having spent quite a bit of time over the last two years to re-implement in Java a system developed by the government in COBOL, I can tell you that COBOL will probably never die. For example, keeping precise, penny-perfect calculations of dollar amounts in Java is actually quite a pain. This is especially true when the calculations involve dozens of hundreds of steps. My solution in Java has been based around BigDecimal, which makes the code very difficult to read. Aside from that, I have spent the vast majority of the time writing very extensive tests and chasing down really small numeric discrepancies. Guess what, if you decide to replace a COBOL system that does any appreciable amount of math, you would get to do the same thing. Plus, you will never be sure that you found all the bugs.

The project actually considered the possibility of licensing a commercial Cobol runtime for PC-based platforms (e.g., Windows, Linux, etc.), but that was not feasible for several reasons.

COBOL is still remarkably good at quite a few things and leaves out lots of the bells and whistles that tend to become distractions in the hands of undisciplined programmers. My only complaint about COBOL (especially old COBOL) is that the control flow is a real pain. Aside from that, it is definitely a workhorse of a language. No need to go killing it off yet.

Three trillion a day, you say?

[dwywit]

Sounds like it might be worth training some new programmers.

You can re-write any or all of your legacy systems in modern languages (if you choose to undertake the cost and risk, of course), but one day they won't be modern any more, and there will be new modern languages, all with their advocates shouting about pieces of the sky falling.

Or you can leave these highly reliable core systems in place and suck up the cost of training new maintainers, and deal with the cost and problems of interfacing them with a "customer-centric" model. Of course, you may have to offer incentives to induce young programmers to use something that's not hip and modern, i.e. $$$

So customers can already do a lot of the work that used to employ bank tellers, billing/accounts staff, and travel agents. None of which changes the fact that "customer-centric" does not and never will have direct access to the core systems. Who cares if the back-end runs COBOL-sourced object code on a mainframe? Methinks people who advocate for C## and Java in core systems have no concept of core systems and their workflows.

So train the next generation of COBOL programmers

[srstites]

The article does not mention what I consider to be the most obvious solution to the problem of old COBOL programmers dying off. Businesses with a COBOL maintenance problem should train young people how to program in COBOL. The businesses will need such people even if they plan to convert their code base to a different language as such a conversion would take years to implement.. --------- Steve Stites

Hopper? No. She's the grandmother of COBOL

[quarrel]

Grace Hopper did not invent COBOL. Follow your own links - there is a whole list of who designed it, and none of them are Grace Hopper. She did lay lots of the foundations they worked upon of course.

To the question of should they replace it? About the same time as any other language should be replaced - it is a very silly question...

Re:Hopper? No. She's the grandmother of COBOL

[Tablizer]

Grace Hopper did not invent COBOL

COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.

The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)

Basically the COBOL committee grew sour with disagreement. As the deadline for the first specification approached, the committee fractured into a "git'er done" tribe, and a "do it right" tribe. The git-er-done tribe basically cloned Grace's language with some minor changes and additions because they knew they didn't have time to reinvent the wheel from scratch. Grace's language was road-tested.

As the deadline came up, the git-er-done group were the only tribe with something close to ready, and so that's the work the committee heads ultimately submitted. There were a lot of complaints about it, but the heads wanted to submit something rather than outright fail. (The story varies depending on who tells it.)

Later versions of COBOL borrowed ideas from other languages and report-writing tools, but the root still closely mirrored Grace's language. Therefore, it could be said that Grace Hopper's work had a large influence on COBOL.

(It's somewhat similar to the "worse is better" story between Unix/C and a Lisp-based OS: http://dreamsongs.com/WorseIsB... )

- - - - - - -

As far as what orgs should do about existing COBOL apps, it's not realistic to rewrite it all from scratch, at least not all at once. That would be a long and expensive endeavor. It's probably cheaper to pay the higher wages for COBOL experts, but also gradually convert sub-systems as time goes on.

However, whatever you pick as the replacement language could face the same problem. There's no guarantee that Java, C#, Python, etc. will be common in the future. Rewriting COBOL into Java could simply be trading one dead language for another.

I know shops that replaced COBOL "green screen" apps with Java Applets. Now Java Applets are "legacy" also. (And a pain to keep updating Java for.)

Predicting the future in IT is a dead-man's game. At least the COBOL zombie has shown staying power. If you pick a different zombie, you are gambling even more than staying with the COBOL zombie.

If it ain't broke, don't fix it. If it's half-broke, fix it gradually.

Or use in-house education

[isj]

2 years ago in one of the banking centers in Denmark 12 new IT-candidate were educated in ... COBOL, CICS, mainframes, etc. The older generation were anxious about how the younglings adapt, but it appears it turned out well. They were excited about the robustness and scalability of the mainframes, not so much about COBOL, but could see it didn't make business sense to rewrite old software. New software is being developed in more modern programming languages.

source (Danish only): https://www.version2.dk/artike...

Re:Or use in-house education

[vtcodger]

Why is that a surprise? If people could master COBOL 50 years ago, why would they not be able to master it today?

Re: What is needed..

[techno-vampire]

Cobal is a crazy nuanced language that is hardware specific.

Absolutely wrong. One of the language's biggest selling point when it was first created is the source code is completely hardware agnostic. To demonstrate this, the developers compiled the same program (from the same deck of punched cards) on three different brands of computer, ran the program with the same deck of input data and got the exact same results. The only change they had to make was one card in the Environment Section, and all that card did was specify the target machine.

Give them hefty salaries

[OneHundredAndTen]

Pay them well, and they will come. Isn't that the way it is supposed to work?

Re:YES!

[mark-t]

It would be a mistake to forget it ever happened, because then we would be likely to repeat it..

Re:What is needed..

[msauve]

What's obviously needed is a COBOL -> APL translator to convert all those programs into a newer language.

Should Banks Let COBOL Die?

[grep -v '.*' *]

Why yes, of course -- OBVIOUSLY.

Let's all jump on the current language of the week. It's of course preoptimized for Big Iron CPUs and IBM DB2 or Oracle databases. We'll write everything over again from scratch using the original business documentation (because who can read COBOL? -- that's the problem!) and this time Do It Exactly Right.

Those losers from decades ago just didn't know what they were doing at all. Stupideos.

And then: the month-after-next comes along.

RH issue is a programming issue now?

[Ducho_CWB]

Lets rewrite billions of lines of code and systems worldwide because we can not afford to hire COBOL devs (or make it attractive to other devs).
Oh, wait...

Let the invisible free hand of he market decide

[Pig Hogger]

Just pay COBOL programmers big enough salaries to attract younger talent Pay them, and they will come

Re:What is needed..

[CaseCrash]

I couple of years ago I worked at a place that has an automatic converter from COBOL to C#/VB.Net (followed by an insane amount of testing and fixes to the converter/custom fixes for their code) and we handled all kinds of businesses including banks (I got to spend three weeks in Belgium helping out on the ING project). So people are already doing this.

(FYI, the company is Asysco)

I work with a former COBOL programmer

[rickb928]

And he's a tedious pain in the A$$. Self-righteous, gloating over the shortcomings of the current crop of apps, reveling in the agony of the kids struggling to release even the most minimal upgrade without 3 fast followers and a deferred feature request until they get enough points banked to figure out something new. He loves their failures.

And our COBOL systems do hum along.

We spent $2 Billion over 7 years on a new core processing platform, written in something 'modern'. It was hell. And it is one of 7 core processes. We are now working on using 'Big Data' to replace another core platform, and I swear they feed it quarters to keep it running - yes, we abandoned Hadoop, but Cassandra isn't much better for my app, we never get the resources we need, and as they convert even these relatively simple apps, we go through a cycle of redesign/minimal deployment/discover massive problems/rewrite/deploy minimal features/add in necessary features/discover problems with all supporting systems/implement error handling and alerts/re-budget to accommodate the real cost/start a new feature cycle... Fortunately we measure most of these events in single-digit months instead of single-digit years. Good bye Websphere, we hardly loved ya.

COBOL need not be replaced for core, transaction-bases systems, but the pressure is enormous. For financial institutions, being able to count on reconciling cash flows reliably cannot be overvalued. Some stuff just has to work. It doesn't have to be 'modern', whatever the hell that means, it just has to work.

Re:Again?

[Dawn Keyhotie]

When COBOL programmers start retiring, they will train their H1B replacements. What, did you think the banks would hire American programmers? LOL.

Just pay enough.

[dpbsmith]

I remember this coming came up during the Y2K flap. COBOL programmers are dying out because companies have decided, for whatever reason, that they aren't willing to pay them much. A quick Google search--I don't know how reliable--shows me:
COBOL Sr. Software Engineer / Developer / Programmer $88,049
Java Sr. Software Engineer / Developer / Programmer $103,239
But that understates the difference because the various job titles shown for COBOL positions are predominantly lower-sounding and lower-paid positions.
As several have said, COBOL isn't hard to learn--I don't know it but I crammed it once for a test. Like all languages it takes a while to get good at it, but it's not specially difficult, nor is it specially bad.

The best strategy would be to render unto COBOL what is COBOL's--keep good legacy systems in COBOL--and pay enough to give people a reason to learn the language.

Re:Hopper who?

[91degrees]

Oh, good lord. do you realise you are the epitome of what you are mocking here?

Language

[ledow]

Why does the language matter?

I have to learn all kinds of new, esoteric and niche languages all the time as part of my job.

Surely what you want is to hire a business or banking programmer and make sure they are then made competent in COBOL (gosh, maybe you could utilise your ageing COBOL workforce to teach him?), no different to bringing in a guy trained on a competitor's system and training him on YOUR system.

It worries me that a bank would be hiring a programmer who *can't* do several languages, especially languages that have been around for decades rather than languages utilising entirely different paradigms, or that can't pick up new ones as they appear.

If you hire some - I don't know, whatever the language of the moment is, say Java or something - programmer to replace all this system, you'll have a system tied into Java. Which will, as Java is starting to show, start to get replaced itself by the time that guy has gone and you've only got rookies running the place on the old-guy's code.

Massive expense, to be back to square one, after decades of dodgy code that was trying to stabilise.

Advertise for programmers, teach them COBOL as the "in-house" language. Then, so long as your business systems have the tools for them to create and execute those programs, you're sorted for a long time yet. You don't even need to care that every other bank in the world has moved to Java or whatever if you do it right and have standardised interfaces or conversion tools.

I think this is not related to "we can't find people who could program in COBOL" as much as "we already have a bunch of cheap outsourced programmers who only know Java and they can't learn anything else".

The time taken to familiarise yourself with such a critical codebase to the point of confidence in pushing your production code should VASTLY outweigh the time required to actually learn something like COBOL from scratch, in this kind of industry.