in Popular

The Inevitable Return of COBOL

7 min read

It’s only a matter of time until the Common Business Oriented Language (COBOL) will regain its spotlight as one of the most in-demand skills of future generations of software engineers. We can just see it now: Programmers of the future will hop out of their driverless cars, walk into their offices and sit down to start coding in 1959’s COBOL.

It sounds crazy, considering COBOL is the furthest thing from most engineers’ minds today. It ranks fairly low in the Tiobe Index, a measurement of today’s most popular programming languages. Many newer, speedier languages give today’s coders little reason not to scoff at the antiquated COBOL. The most telling evidence of COBOL’s irrelevancy is that about 70% of universities said they don’t even include COBOL in their computer science curriculum anymore, according to a recent survey. It’s logical. Why waste curriculum space for a skill that employers don’t even look for these days? A quick search for “COBOL programmer” on any job site, for instance, yields a few hundred job postings while the more popular “Java programmer” yields thousands.

Based on these facts alone, COBOL appears to be nearly extinct. You might even wonder why we’re writing about COBOL at all? But looks can be deceiving. COBOL is a mysterious paradox. Born in another era, COBOL lives on as the quiet but important pillar on which the majority of businesses stand today. In a field that evolves at an unprecedented speed, younger generations may be overlooking a critical skill of the future.

Out of Sight, Out of Mind

Those of you who are familiar with legacy systems know the widely cited stat: *70-80% of all business transactions worldwide are written in COBOL today. But what’s not emphasized often enough is there’s a slowly increasing gap between the number of massive institutions relying on COBOL and its relevancy among programmers today.

COBOL knowledge skill gap (3)

While newer programmers aren’t as interested in learning COBOL, its role in millions upon millions of mission-critical transactions from healthcare to travel can’t be denied. COBOL is written for mainframes created 10 years before man walked on the moon. Those same mainframes still operate some of the biggest institutionalized computing today. If someone pulled the plug on COBOL, millions of businesses worldwide would suffer from malfunctioning machines. This old programming language is a bit of a taboo today, but it’s important to recognize just how big of an impact COBOL still has on our day-to-day.  Here’s a quick breakdown of the biggest systems that run on COBOL:

COBOL impact

Why Haven’t We Replaced COBOL?

If COBOL’s been such a foundational root of business apps for decades, why hasn’t something better come along? The short answer: If it ain’t broke, don’t fix it. The long answer requires us to take a step back in time. COBOL was created in 1959, the computing era when programming languages were tailored for specific purposes. For instance:

  • Fortran → Scientific problems
  • Lisp → Artificial intelligence
  • Cobol → Business applications

As banks, insurance companies and government institutions started joining the computer age, they’d create programming languages specific to their machines. You can imagine how costly and time-consuming this was. There needed to be a universal business language to carry out business operations faster.

grace

Grace Hopper, the mother of COBOL, helped champion the creation for this brand new programming language that aimed to function across all business systems, saving immense amount of time and money. Hopper was also the first to believe that programming languages should read just like English instead of computer jargon. Hence why COBOL’s syntax is so wordy. But it helped humanize the computing process for businesses during an era when computing was intensive and prevalent only in research facilities.

And so a new committee, consisting of industry, universities and US government folks, formed to develop the much-needed language to help standardize business programming. The Department of Defense even decreed that all businesses must run on COBOL in the 1960s. One article by notable software engineer Robert L. Glass explains that COBOL does the 4 essential business tasks better than most modern languages today:

  • The capability for heterogenous “record-structure” data
  • The capability for decimal arithmetic
  • The capability for convenient report generation
  • The capability for accessing and manipulating masses of data (typically made up of heterogenous data structure).

“COBOL is either good or adequate in all 4 (except for database access and GUI construction, they were designed into the language from the outset), whereas the COBOL replacement languages, like Visual Basic and Java are good at few if any of them,” Glass says. And as language designers started to take more of a universal, flexible approach:

“The unique capabilities of COBOL and the business reasons for them were lost in passage of time.”

This was true as of 1997. So, at least until the late nineties, there really hasn’t been a successor that could carry out the massive batch processes as sturdily as COBOL.

But the even bigger reason not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records. Creators of COBOL invested 2 trillion dollars for the universal language. Businesses worldwide run on over 220 billion lines of code today. It would be a herculean feat to replace every single business program with a brand new language without introducing detrimental bugs. Hence, the cost just hasn’t outweighed the benefits of replacing COBOL.

The Case for the COBOL Comeback

Although COBOL is currently out of sight and out of mind, businesses have to focus on restitching the antiquated fabric of their infrastructure…eventually. Consider the average age of the COBOL programmer today. One survey of IT managers from 352 companies finds:

Age of COBOL programmers

That survey was taken 9 years ago. In 2014, Micro Focus says that the average age of COBOL programmer is still about 55-years-old.

“Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,” says Dale Vecchio, research vice president of application development at Gartner Inc. “In 2004, the last time Gartner tried to count Cobol programmers, the consultancy estimated that there were about 2 million of them worldwide and that the number was declining at 5% annually.”

COBOL programmers are starting to retire; meanwhile, there’s no interest from young programmers to take on COBOL challenges. So, what will businesses do to keep maintaining their mission-critical programs? COBOL skills will be in demand to reverse-engineer pivotal mainframes. And as time goes on, the market will need to correct this skill gap by boosting the value of COBOL programming skills, drawing more engineers to learning the language.

Some COBOL-heavy organizations, like IBM and Micro Focus, have already developed programs to promote COBOL in younger generations. So far, IBM has developed curricula in association with more than 80 colleges and universities. Companies in Dallas are also doing something about it as well. Dr.Leon Kappelman, professor of Information Technology at the University of North Texas told the Wall Street Journal:

“Four years ago, local Fortune 500 employers encouraged the university to offer Cobol courses. Now, graduates who take Cobol electives earn starting salaries of $75,000 compared to starting salaries of $62,500 for those who did not.”

Plus, many forums and online discussions about the language illustrate that…guys…it’s really not that bad. It’s important to note that, unlike modern languages, COBOL is not designed to be versatile. Once you adjust your expectation, COBOL isn’t as ugly. Some programmers enjoy the puzzle aspect of maintaining COBOL-based mainframes, like figuring out the exact line of code to fix an existing script. Others find the stable environment allows them to focus on the business aspects of the program. It’s why the few universities that offer COBOL courses mask it under “Intro to Business Systems Programming

As taboo as COBOL might be in the ping pong rooms of modern startup-driven culture today, its influence and irreplaceability will result in a spotlight on the dinosaur language again. Businesses must figure out who will maintain their mainframes when COBOL programmers retire in the near future.

If you ran a COBOL-oriented business today, what would you do to address the looming skill shortage? Tell us in the comment section below!


To get occasional notifications when we write blog posts, please sign up for our email list.

 

 

* The 70-80% stat on total COBOL business transactions is an estimate based on Gartner and Micro Focus sources. 

Share your thoughts

Comment

114 Comments

  1. I’d rather take $12,500 less per year to NOT have to program in COBOL. I’m a Perl programmer and I took the COBOL class at my college twice but I just couldn’t finish it because COBOL is such a pain. 10 lines of Perl equals roughly 100 lines of COBOL.

    • If it’s $12 500 for a newbie today… what it’s going to be for an experienced guy in ten years? I need to invest in a good COBOL book, I think.

      • Would be my attitude. I am not worried about the future of COBOL and when the jobs end, I worry about my future and if I die before my retirement money runs out.
        Work is not necessarily fun, that is why they pay you. They currently pay more for some trailing-edge programming knowledge because somebody with 30 years ahead of them in programming does need to look at how viable the knowledge is. COBOL pretty much stays COBOL. However how long will Perl last and how long will your current employer stay up with the times.

        Any language, new or old, can go stale, and you can rot on the vine. I work in C# today, did my last, and best COBOL project in 2012. But you need to keep up constantly with SQL and C# versions or you will be even more lost than being a COBOL expert.

    • @mfrager
      ‘I’d rather take $12,500 less per year to NOT have to program in COBOL’

      And I’d say there would be plenty who’d pay you $12,500 per year to NOT program in COBOL.

  2. COBOL is well optimized for reading a (possibly large) record, fiddling with small parts of it, and putting it back out (all without changing the representation into an “internal” format). This makes it very efficient for certain kinds of data processing tasks.

    • Because of my COBOL background, I have surprised younger programmers by manipulation of strings of data. I have written systems that start off reading a SQL table, then writing to flat files on the local CTemp areas to filter and parse data for exporting to vendors that do printing. Doing that is sometimes easier, and usually much faster that running complex SQL statements to select out the data you need. And it takes the load off the database server.
      Something learned from a background in COBOL. Also, there is no better language to work with money as your data.

      • COBOL was said to be dying in 1970 and in 2015 – 45 years later it’s still here. UNIX and other operating systems can’t handle the capacity of mainframes in data heavy applications. The one thing that COBOL & mainframes do well is volume processing. Processing trillions of transactions a day requires throughput and UNIX/LINUX just doesn’t cut it.

        • This: “The one thing that COBOL & mainframes do well is volume processing. Processing trillions of transactions a day requires throughput and UNIX/LINUX just doesn’t cut it.”

  3. I became a programmer through a COBOL training program at a company in Michigan, work as a python programmer in Silicon Valley now, and trust me, the language is horrible. Once you adjust your expectations, the language still has no data structures other than tables, no scoping, no libraries, and it doesn’t lend itself to OO design. Sure it can be fun tracking down weird bugs that we don’t get with modern languages because we know how to manage memory and scoping and can write OO code, but that doesn’t mean it’s a good language to write things anymore. Systems use COBOL because the business requirements for the program are not understood well enough for any one person to be able to write new specs; rewrites are too massive of an undertaking especially in such high stakes areas. The existing code isn’t going away, but writing new systems in it is ill-advised.

    Another problem is that the language itself can be learned in probably a week, that’s not where the skills vacuum exists. All the tools that go along with it take a bit longer, but the biggest challenge is that because the language is so rudimentary, many ‘helper’ programs have to be built in house. This is a pre-unix, pre-open source paradigm. You need to be trained in the specific system’s idiosyncracies and ‘libraries’, and there are a ton of them. This is secondary to the language itself. Getting a developer up to speed is always a challenge, but with COBOL it’s much bigger because the code bases are so much more sprawling and complex, and you can do nearly nothing without specific knowledge. You can’t teach that in college because there isn’t a 1 size fits all approach.

    • Wow, absolutely nailed it on the head in my opinion. I started my programming career working on COBOL programs for a couple years. I eventually knew I had to get out of that and back into others if my career was going to stand a chance.

      Yes, the mainframe is very fast, but I have seen Java applications be just as fast or faster especially with all of the third party software out there. Those COBOL programs are huge and have easily 25+ years of business logic baked in. Not many people are willing to regather all of the requirements necessary out of fear for missing the smallest detail.

  4. I’ve programmed tens of thousands of lines of Cobol and perhaps a hundred thousands of lines of C. My Cobol use is some decades ago, but some things don’t go away.

    The design of Cobol is broken, for those who know modern programming concepts. No, it cannot be ported to Java. We can fix the worst features of Cobol with a few simple adjustments to control structures, call and perform, enhanced class conditions, and a very modest addition to the notion of data types. The new language compiler must hardly be different from the existing Cobol compilers.

    And translation to the modified language could be programmed reliably, if the new language were conservatively and carefully designed. We have the time and the talent. No, a new Cobol should not have pointers, garbage collection, inheritance, pattern matching, multi-threading, or other hyper-modern stuff.

    The main advantages would be to reduce new bugs and to attract more programmers with a more modern orientation.

    The addition of totally new features, such as a hash-map (Isam anyone?), would be simpler to implement as there would be no conflict with existing code, and these new features could be totally ignored. The language translator could fix most identifier name conflicts.

      • Very true. However, GC is still too modern for Cobol. Let me say it another way:
        Adding GC to Cobol would make it a different language. This would make it harder to migrate to.

        As a side note: I learned at University in the 1960’s that Lisp was obsolete and would never be used again. Boy was that wrong.

    • I guess Multi-threading is managed by cics, that by the way is an awesome transaction processor…I guess is cuestion of using the right tool

  5. It would be interesting to see this point developed:

    4. The capability for accessing and manipulating masses of data (typically made up of heterogenous data structure).

  6. I taught myself C64 basic, trained on COBOL, got a job in PICK another legacy OS/database/language slightly younger than COBOL but better. And now I’m a Microsoft Stack DevOps – C#, SQL, Azure. COBOL is ugly, horrible and aweful and PICK less so. You’d have to pay me double my Microsoft Stack salary to work on PICK and tripple to work on COBOL – WHY? Because the longer you stick at a legacy IT software platform the more you become unemployable so you need to pay me that risk. I’m already at risk with my current role through a cheaper work force overseas or via immigration.

    I would actively discourage graduates from learning COBOL – it is soo far removed from current technology – it’s obsolete for a reason. These monoliths need to get with the program and change with the times like everyone else and they could have started 9 years ago.

    • Agreed. A good example of replacing the legacy applications is the Alabama CARES project. It’s a 3 to 5 year project that is being converted from COBOL to ASP.NET. Eventually, all organizations will need to do a similar project to get off the mainframe.

  7. If you adjust your expectations, then C is user-friendly. Adjusting your expectations can change everything bad to something good. So this doesn’t count.

  8. Really interesting piece about the continued viability of the language. And it raises a good question about skills – and whether the future generation of app developers will have the skill or appetite to maintain these must-not-fail COBOL systems. This is an enterprise resource planning question as much as it is a question of taste for any developer. The laws of supply and demand will dictate that any gaps will be filled, especially if the roles become well paid. The smart CIO is going to have to build a resource plan for COBOL as well as any other technology in play to get in front of this. In the middle of this is newer COBOL technology and arrangements with academia to put COBOL back on the syllabus. Interestingly this is already being done successfully in a number of institutions in support of a number of household name organizations. The so called ‘skills gap’ is just an IT management planning task, just as skills for any other important technical function must be planned for.

  9. I was stuck trying to fix a COBOL program when I was a junior programmer back in the mid ’80’s it was horrible then and everyone made the same excuses this article makes. “It’s To Expensive To Replace All That Code”…The only damn reason there is so much code is that the language demands you write a hundred lines of code for something that should take 5 lines of SQL or even PERL. The problem is that even trying to maintain this mountain of bad code is a loosing proposition, the tools are antiquated, the compilers are horrid, even the OS’s they are running on are starting to end of life. What is going to happen then? Who is maintaining the environments and tools, let alone the programs themselves? Heck the programs I was trying to fix were running on a UNIVAC – does UNIVAC even still exist?

    • Problem is not the code, but it is the business rules. Companies laid off the old coders also lost the knowledge of everything the program was doing within the company. Maybe you change something to create an easier to read report so you did not need to run the job anymore, only to find that another program read in the same data that accumulates all year and sends the 1099’s out. So you spend all January trying to recreate the lost data!
      But seriously, some code was real scary stuff. I always liked to tackle it because I was more a maintenance programmer than a new developer. I specialized in reading code written by others. But the worst was the early COBOL code that was migrated from assembler by an assembler programmer. It was COBOL that looked like assembler language.

  10. Things are going to be interesting. In one hand, code that is not maintained rot, in the other hand you will always have people willing to learn a ancient language if you pay enough. In one scenario mantaining COBOL will be feasible, but it will just be unpractical, not because COBOL programmers will be expensive, but because you will have to always mantain a army of them ready and have them “patrol” the code. Is just like mantaining my old car, at some point is just cheaper to buy a new car.

  11. You make a compelling case, Ritika; but in terms of jobs, the numbers don’t seem to support your conclusions. I just counted the number of job openings near Seattle posted on Indeed for several languages. C#: 2877. C++: 3029. Java: 4096. Cobol? 25.

    • It is the jobs to employees ratio. 25 COBOL with 11 people in the area with the skills.

      I work in C#, but in that area your skill set also narrows. I work with non-web programs that do long running database and sometimes print output. Those C# skills do not translate to the web app skill set since you need to know JQuery, or they want you to know cloud development, etc, you can really split the skills out to a very fine level.
      The next split comes with the business model. If you worked in government they do not think you can work in the business world. If you are in insurance, they do not think you can cut it in banking. And medical is in its own world, it splits between billing/insurance, and medical imaging/patient records.

      In some respects the COBOL might be an easier fit because of the fewer flavors. And you might need to search old school cities with high frequency back end programming like federal government or large state agencies in large states, or banking in NYC or Dallas, or energy in Houston or Oklahoma. Or even the old Hartford area in insurance, years ago they had lay-offs in all these sectors as front ends went web or off-shore. Today those same people they kept on are looking for a lake house and no alarm clock.

  12. There’s a scary thought: the resurgence of COBOL. One wonders if, once it becomes a skill that’s truly in demand, a whole bunch of young programmers will become specialized in it, and then start writing their own things in it, and then develop an object-oriented version of it (perhaps this has already happened) and an entire new generation of nastiness will be born… “add desperation to ignorance giving COBOL,” as it were…

    “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.” — E.W. Dijkstra (from this paper: http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html in which he also states “…with respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist”).

    Right – back to work: I have some COBOL programs to write…

    • Meh, E. W. Dijkstra is overrated.

      How many customers has he served?

      OK, now how about COBOL? How many has COBOL served?

      More than Dijkstra methinks.

      Nice try, Dijkstra you old… guy

  13. You can tell it is actually NOT THAT VALUED by the C-Suite because the CIO would just say: “Open source license it, put it up on Sourceforge or github, etc. and let everyone cooperate on a port project.” They keep saying there are tons of banks, etc. which would benefit. It can’t be a security concern because the code is too idiosyncratic to hack.

  14. This article is good, but could be better. Please run spellcheck and proof read … “business programing” and “most all modern languages” aren’t proper English. Also, even if Glass’s claims were true, which is dubious, they ignore the numerous ways in which modern languages are far superior to COBOL. As you say, it’s those 220 billion lines of code that are the reason COBOL is here to stay. You say that “it’s really not that bad”, but your link really doesn’t support that. Also it is false that the DoD mandated COBOL for all businesses — something that it could not have done. The DoD did mandate *ADA* for *contracted software*, but that’s a far cry from “all businesses”. Also, Grace Hopper’s influence on COBOL was mostly through FLOW-MATIC, her own business language for the UNIVAC. An important fact about COBOL: there were short- mid, and long-range committees. COBOL is the product of the short-term committee and the other two committees were disbanded. “its influence and irreplaceability will result in a spotlight on the dinosaur language again” — no broader a spotlight than this and a couple of other similar articles.

  15. When I started in the 1970s, large companies would pull people from the business units and train them in-house on Cobol. Or business people would be sent to offsite consultants who did the training. Very few business programmers were developed by the universities. University graduates generally could not tolerate the Cobol work environment.

    • Of course these pampered collegians could not tolerate it, it meant doing actual work. COBOL is a man’s language.

      • That’s funny.

        Back in the day, a friend in the biz always said assembler was the masculine language and COBOL was the feminine language

        To this day, I can’t say he was wrong..

        • I’ve always liked talking to females. 😉

          I’ve been gainfully employed for 31 years as a COBOL CICS DB2 developer and never lacking for work, mostly in the Transportation sector. Making a big business hum operationally and securely is being down in the trenches. When you are the CORE systems, the Business depends upon you. Sometimes you feel like Mr Scott controlling the Warp Engines. The Captain will seek you for what you can do for the Enterprise. Saved many implementations because some vendor project could handle something, but some quick COBOL coding would compensate and save the day.

          I’ve witnessed a lot of languages come and go, but COBOL has remained King throughout my career. I’ve come to appreciate the consistency and beauty of COBOL. The naysayers can continue predicting the demise for another 20 years and will be equally wrong again. They overlooked that COBOL has matured and grown itself over the years. There’s a lot to be said for stability and reliability.

      • @Shilly
        I very much agree with the sentiment of your comments.
        And the ‘ work ‘ aspect of COBOL means you’ve really got to master the logical thinking aspect of your brain.
        Thinking is not such an encouraged thing now and therfore COBOL has red hot enemies.
        The big rewards are for people who are expert at parroting and not questioning.

  16. Hard to believe that soon all of the Cobol programmers will be retired or dead. If you thought that Y2K was bad, wait until Y2.1K!

  17. I’m 26 and I’ve been a Cobol programmer for little more than a year. Here in Brazil, Cobol programmers are the highest paid programmers in the market. Banks, and particularly Insurance, which is the area I work at, make billions of dollars of profit every year and, at least to this date, this trend continues despite the general Brazilian crisis.

    There is no shortage of people who know Cobol: a person with a little programming background would get the language in a day. Tools that are usually necessary for the work, such as JCL and some IBM utilities, can also be learned in a short period of the time. The real shortage is of people experienced with the codebases and the business rules they implement. Cobol codebases are usually gigantic messes of spaghetti code, magic numbers and ad hoc additions. You would get scared at what programs and systems that process millions of dollars of your money daily look like when you open the hood.

    Equally as important, there’s an absolute shortage of tools: things that other people take for granted, such as automated testing tools, are either non existant or not used. As a result, people get (rightly) afraid of making small changes in the code and, when those changes are made, we often have to learn an entire set of other poorly designed processes to test it.

    People who can quickly navigate this mess, who know what the magic numbers stand for and such, are very highly paid. I’ve seen those usually older gentlemen solve problems that involved huge amounts of money over phone calls. Despite efforts on the bank’s part to train a new generation, some systems are almost effectively orphaned due to no one being able to understand them.

    Just as a final observation: Cobol sucks. It’s not bad at what it does (processing sequential files) but, in general, it sucks. It’s a powerless, unexpressive language. It’s definitely not a language to be taught at Universitites. Students need to learn and solidify Computer Science fundamentals and have an appreciation for ideas and design clearly expressed in code. If and when they want a job, then they apply to a Cobol position.

    • Oh now, Marcus.

      COBOL doesn’t suck.

      It’s not great but it doesn’t suck.

      You know what sucks? Octal bit flag programming in 256 bytes of ROM on an old NCR cash register to set up sales tax tables.

      Compared to that, COBOL rocks!

    • @Marcus Souza

      ‘ a person with a little programming background would get the language in a day ’

      ‘ It’s not bad at what it does (processing sequential files) ’

      Please think about what you are saying.

  18. Perhaps the conclusion should be the opposite. Instead of training young people to program in this dinosaur language these old, crusty, ultra conservative corporations should finally upgrade their systems to something that’s less than half a century old. Maybe the lack of qualified programmers able to maintain them will finally force them to do so.

    There’s nothing good about COBOL. The only reason it’s still around is because it’s used by industries that are entrenched & completely impervious to change. Once COBOL based systems become impossible or prohibitively expensive to maintain there will be no choice, but to rewrite them in something that doesn’t suck to program in.

    • COBOL is a problem at my university. There is a system written in COBOL that handles critical information, including the list of courses offered each semester, students’ schedules, and grades. The developers who maintain that system have many other responsibilities, so they can’t spare the effort to rewrite the code. That’s resulted in a looming threat: that one day, the system will break down. There have already been several close calls and it’s costing more and more to keep it alive.

  19. cross compilers!!! they are already in the market for churning code out from pre-built programes .. since COBOL is a structured language , it will be easy to built a compiler to convert it into a modern language like C++ or Java. You don’t need all the programmers in the world to do that.

    • Cross compiled programs are really really hard to maintain. I have worked with some. the code is almost unreadable.

    • @Denny Jose
      ‘ You don’t need all the programmers in the world to do that ‘.

      So how many programmers do you need?

  20. There are also a few independent educators that teach COBOL and also bring COBOL programmers up to date with XML capabilities that the compilers now offer.

  21. I would post a comment, but this screen is white-background with black letting. My age prevents me from interacting with such a color-laden screen.

    • I Use 5 Browsers – All Of Them Have Color Tweaks Or Extensions That Allow That Tweaking.

      My Favorite Tweaking Is Black Font On Soft Grey Background ( Links Use Other Colors ).

      Ask For Help – No Need For You To Avoid Commenting, Whatsoever.

      IBM AS400 And COBOL FOREVER !

  22. Back in 2000 I did raise the suggestion that if we could get Cobo to run in a real time interpretive mode, like REXX, then Cobol everywhere was a real possibility. Unfortunately the powers that be at that time were a bunch of recently out of college fastpaths who poo pooed the idea. What a shame , that would have been a real money spinner and kept Cobol on College curricula. OO languages may be faster to code but the runtime pathlength is horrendous and maintenance a nightmare.

    • I think that would not have made Cobol en vogue. Cobol is a very simple procedural language and allows simple flow of statements. Many of the sophisticated programming techniques are not possible in it with addition to being extremely descriptive in nature. Lack of any common libraries and 1000s of home grown solutions have turned it into a learning nightmare.

  23. COBOL must die. But slowly and painfully.

    Maybe, just maybe, we could have a runtime or a VM that manages COBOL code, and communicates with the underlying hardware (a copycat from Java/Erlang);
    Heck, this VM could be a BEAM or just Java.
    It could be a small runtime for COBOL code.
    That is step one.

    Step two is replace all of the world’s COBOL hardware from machine-compiled COBOL to VM compiled-bytecode COBOL.
    Performance? Nah. Not a problem. The VM can make JIT and smart optimizations on compiled bytecode. It would get smarter with time. This is a long time project.

    Step three is develop a new language. A modern language. A high level language. For generations to come. Or bindings from different languages to this VM.
    That spins up a whole new world. Suddenly, everyone wants to write some finnancial app.

    It’s a problem, but we must pave the way to modern programming languages and environments.

    • bruno do u know any cobol programmers with modern language expertices like C++, C#, etc. I have 30 yr old software running on Cobol/Linux and would like to modernize as 4 programmers are ready to retire

  24. Feels like the “teacher shortage” problem that has never shown up. The biggest problem I have is not with COBOL but generally the platforms is run on. For example,. if it is on a mainframe running Z/OS then you are stuck with an inferior database as well as a platform that is difficult to interface with(limited web service support, etc.). The biggest reason is correct that there is so much that runs on it and it is expensive to rewrite, but other than that I see no advantages. Code is not self documenting, test driven development doesn’t really exist, and much of the code is not reusable. I get that COBOL can be coded in a “smarter” way but often not as many COBOL programmers are not programmers but people who moved from analyst to programmer as it was path up. Now there isn’t even good design at the COBOL level as solid application design skills are not developed. It is no wonder legacy systems are so expensive to maintain.

    • Define “…if…mainframe running Z/OS then you are stuck with an inferior database…”. What database? Much of what you have written makes no sense; COBOL is self documenting (provided the coder took advantage of a descriptive variable name), test driven development does exist (provided that the environments are set up – not a COBOL issue), and code can be reusable (provided the coder understands “how” to write reusable paragraphs and/or linked CALL subprograms).

      This all sounds like you a repeating what someone else told you. But I will agree with one statement – “COBOL can be coded in a “smarter” way but often not as many COBOL programmers are not programmers but people who moved from analyst to programmer as it was path up.”; but the statement was started with “I get that”. Starting a statement with “I get that” implies you have knowledge of or book knowledge of a concept but no practical experience.

      Your comment added nothing to this discussion.

  25. I just to be a COBOL developer on unix clone in 87-90 then in Digital Vax in ~91-92.

    Then moved to other platforms and from time get some extra bucks doing consultancy on COBOL until ~2000.

    Since then I read a lot of blog positings and magazine articles saying that COBOL will return and will bring 1000s of jobs.

    Guess what?

    I’m still waiting for those 1000s of COBOL jobs.

  26. The problem is government compliance. It is no coincidence that the most heavily regulated industries of Finance and Health Care are also the two industries entrenched in old technology. There are plenty of smart IT and Business leaders at these behemoth companies who understand the benefit of a massive migration to a world of SAP and Oracle. However, the compliance risk stemming from any migration bugs would absolutely kill any one of these companies. Back to the matter of compliance, the reason that you don’t see smaller companies disrupting the entire scene is that they can’t afford all the legal/finance/admin/regulatory overhead to deliver all the mandatory government reports. This is what big government looks like. We used to laugh at those old ugly Soviet Union cars? Well now you can start laughing at those old ugly COBOL mainframes.

    • There are no old ugly COBOL mainframes left. We now have beautiful shiny new COBOL mainframes that are cheaper to run and easier to maintain than the massive estate of mid range servers that would be required to process the same volumes of data………

    • @Robert Casper

      … and once an organization corners the market with their own proprietary software, then what?

      Do they perhaps raise their prices?

  27. We are in 2049 and scientists wake up a man who had been frozen many years ago and had a terminal illness.
    – Oh, did you find a cure for my disease? asks the man.
    – No – they answer – we desperately need a Cobol programmer…

  28. They’ve been telling me that COBOL was dying since I took my first job and it was in COBOL… over 20 years ago. Well I’m still working in COBOL, it’s not dead yet and I’ve found enough work to keep me going. Seems like when the country is in a recession the old tired ‘dead’ languages come out to play (and jobs are plenty). When the country is doing well… the new ‘toys’ come out and tell us old language people that COBOL is dying. I’ll believe it when I see it in front of me.

    • I am 23yr old, just started in cobol, is it good to continue or I should move on to some other tech like informatica or big data?
      I am little bit concerned about my future. plz help!!!!!!!!!

      • Do You Know Anything Related To The IBM AS400 Hardware Family ? – The Most Used Language Is RPG, But There Are Companies Still Using COBOL.

        The Site ALL400S Has A List Of Companies That Use The Platform All Over The World.

        Good Luck.

      • @vjais
        I think you should walk away from a computing career.
        No …. RUN!
        The pace of change is too much for most.
        You might have ‘ flavor of the month ’ skills now, but you will have to be relentlessly keeping up with new skills.
        Try any other profession except computing.
        Other professions are evolving at a rate which most people can cope with.
        As you get older, you will have other priorities which are of much higher importance than acquiring skills on the latest combobulator.
        http://www.definition-of.com/Combobulator
        Think – people.

  29. What you have to do is kill the business that is using COBOL by disrupting it. For example, say you find a better way of networking ATM’s and you come in and disrupt the entire industry. And of course, you also happen to be writing in more modern frameworks, like Java/Spring or dot Net, so the COBOL is destroyed. In other words, the old line business runs its COBOL until a disrupter puts it out of business.

  30. This is a good article. As I read through the comments, though, there are several misconceptions still. First, COBOL does not equal mainframe Second, those commenting on Z/OS don’t really understand the capabilities of the platform. Inferior database? DB2? You can choose to run Oracle and others on the platform. Web server? It has one. Web interface to a COBOL based system – you interact with them every day and you don’t even know it. COBOL has not been static. It has grown and evolved over the years of it’s life and is as capable as any other general purpose language. It has OO features. It runs in virtually any platform. Many commented on a JVM COBOL. There are several variants of this available. I work on COBOL based systems that run on Unix, (Linux and others) as well as Windows and Mainframes of all different flavors. COBOL is just one of many different choices in programming languages and is not less capable because of the age of it’s specification or the platforms on which it can run. COBOL’s biggest handicap is the fact that the systems have worked and worked well. Many just run with NO maintenance. And then years down the road when something is needed it can be difficult to find someone to work on it. Staffing is going to become important in the coming years, but like any other shortage, the gap will be filled by willing and able devellpers of all stripes.

  31. COBOL is obsolete because the procedural paradigm simply doesn’t work well in a networked environment, where objects and layers make much more sense. It has nothing to do with the language itself, which served us very well when there was ONE central processor and no event-driven programming required. COBOL is still an excellent language for batch processing (where the procedural, rather than object-oriented, paradigm is perfectly adequate) and that is why mainframe sites cling to it.

    Object orientation WAS added to COBOL in the 1990s, but it was largely rejected by the COBOL community. By the time it became apparent that the World had voted with its feet and OO was replacing procedural code as being ideal for networked systems, the OO COBOL boat had sailed. The FACT is that modern languages which were designed for OO, do it “better” (read…”More quickly and easily”) than COBOL, which had OO added as an afterthought. Despite millions being spent annually by COBOL vendors to hype it up, any modern CIO who bet the farm on COBOL would not be employed for very long.

    It is interesting to see the same old figures for COBOL code being trotted out again. These figures came originally from a Gartner report which has since been disclaimed by Gartner, who admit that it is impossible to verify with any reasonable degree of accuracy. There IS a large codebase of COBOL still extant, but it is diminishing every year as more and more companies embrace more modern technology.

    This is a typical article designed to persuade us there is still a case for COBOL, when there actually isn’t. COBOL is to modern programming what Latin and Sanskrit are to literature: useful to have some knowledge of, but pretty irrelevant when it comes to making a living as a writer.

    (Try doing a search on “Cretaceous COBOL Jurassic Java” for more of my thoughts on this.)

    • So you are saying that object-oriented code is not procedural? Have you taken apart a Java program? Guess what, sparky, it is procedural. Do you think polymorphism is new and unique? Again, in my day, we called these called procedures where the values could be changed. Yet another non-contributing opinion.

    • @PeteDashwood

      If you didn’t learn about invalid arguments in business school, then there is a book called ‘ Thinking Straight ’ by a bloke called Beardsley – you should try reading it some time.

      Here are a few examples of the invalid arguments that you have used – assertion, analogy, appeal to authority, ad hominem, non sequitur & slippery slope.

      Take all of them out of your comments – and there’s nothing left.

  32. “There’s a shortage of COBOL programmers! Learn COBOL, you’ll make big bucks! Supply and demand!” If this idea catches on, there will be a glut of COBOL programmers and they’ll be working for peanuts just to get a job. Remember the ‘shortage’ of people who knew Medical Coding? And the following glut?

  33. Is this discussion still going I have a question for /imapangolin AND/OR PeteDashwoodmplease.

    If not I would love to speak to anyone!!! I requested them because they seemed to be on opposite sides; polar opposites, and that I liked. Especially with their experience.

    Thanks so much for your time everyone!

  34. Everything you have said is true, I am a thirty year COBOL veteran and I have not been able to land even an interview in a year’s time.

    COBOL is still in high demand, and in use all over the land, and the same can be said for Indian programmers who have displaced Americans in these jobs.

    • That has happened to me several times in several places. This has been building since the 1990’s. “Off-shore” talent taking away jobs from us over 30 year COBOL veterans because they will work longer hours for less money. OH – did I mention that they are willing to learn COBOL? Maybe that is the crux of the problem. Learn it here to keep it here. Bring back COBOL in our “S.T.E.M” learning institutes.

  35. I was a COBOL programmer for many years, before becoming a system admin in windows, and a security admin.
    I was always a ‘techie’, and when I learned COBOL I did take the books home and read them on my own. I also made sure that I understood CISC, DB, and BAL. This gave a great insight into what you can accomplish with COBOL.
    For me, understanding the technology and what you can do with the technology allowed me to excel in the programming part of my career. COBOL is as complex or as simple as you choose to make it. If you code just to ‘get by’, your code is not going to be very flexable.
    COBOL is tool to some, to me it’s akin to learning an instrument, i.e. a guitar. You just strum and get by, or you can go much more in depth.
    Sadly the only issues I ever saw in my programming days, was management not caring about the ‘quality’ of work, but rather ‘just get it done’. If you build something cheep, your quality is going to be ‘cheep’.

    • I think you’ve got an undefined variable name towards the end of your code.
      Try
      01 ww-cheap PIC X(05).
      88 cheap value ‘cheep’.

  36. COBOL, in the MVS environment, was used extensively, when I worked in the insurance industry in the 1980’s. Although, one person, on this blog, indicated that COBOL didn’t shine with event driven processing, the programmers where I worked were able to adapt it to do so, as part of large system implementations. COBOL, was used extensively in both the online (TP), environments and the batch environments, so a common core, among programmers, using COBOL, was important. Systems programmers, and application programmers alike, coded in COBOL, or 370 assembly language for that matter. As a side note, the editors back in the day (TSO/ISPF), still blow away any editor, or graphics based IDE today, and coding COBOL was a joy, for both handling transnational and event driven programming tasks, to batch systems, or resource management, including networking applications. Those who think COBOL, was purely an application programming language, forget that resource management, (for example) is just another systems level application, and many of the advanced concepts used widely today, were implemented at least once, in a COBOL, MVS environment. The old nothing new under the sun adage.

  37. COBOL, in the MVS environment, was used extensively, when I worked in the insurance industry in the 1980’s. Although, one person, on this blog, indicated that COBOL didn’t shine with event driven processing, the programmers where I worked were able to adapt it to do so, as part of large system implementations. COBOL, was used extensively in both the online (TP), environments and the batch environments, so a common core, among programmers, using COBOL, was important. Systems programmers, and application programmers alike, coded in COBOL, or 370 assembly language for that matter. As a side note, the editors back in the day (TSO/ISPF), still blow away any editor, or graphics based IDE today, and coding COBOL was a joy, for both handling transactional and event driven programming tasks, to batch systems, or resource management, including networking applications. Those who think COBOL, was purely an application programming language, forget that resource management, (for example) is just another systems level application, and many of the advanced concepts used widely today, were implemented at least once, in a COBOL, MVS environment. The old nothing new under the sun adage.

  38. Today’s mainframes and today’s COBOL are faster then just about any other language even hand crafted Assembler. When the author talks about a language developed 10 years before man walked on the moon etc it is really just a display of ignorance.

  39. I work as a Systems analyst on mainframe systems, and have developed on them for 15 years. I also design on JAVA, .NET, Terasata, and Cloud. In reading the comments there has been some good discussion generated and, in my opinion some pure tripe. YES there is OO COBOL. There is also a newer version of COBOL, 6.1 just recently released. I agree with the statements that the language is an art form or thought process of combining code with JCL or other script. COBOL is also highly effective in DB2 stored procedures and CICS web services. In fact the capabilities that many othe languages are renaming or discovering today were discovered and used in mainframe development years ago. I notice many languages try to repackage the same concepts and pretend they are the latest thing (SOA amyone), I also note that IBM also has begun showing these “dinasour” mainframes not as mainframe but now as large scale web server through their service capacity.
    As for the off-shore discussions. I work with many companies around the world and do find many programmers in India and Mexico. However, it is rare, that you find a good one that is beyond a 1st or 2nd year skill level. Every language has its strengths and weaknesses. The real key is to combine this strengths into a well designed product useful to the end user. I see way too often developers creating nasty WMD code because that was the only skill set they knew and, god forbid, they look outside of their realm or consider that antique language. As for COBOL developers, admittedly, many of us were taught, and still code as if it were still 1975 and refuse to use the more robust capabilities of Enterprise COBOL (GO TO and EXIT anyone?). Abilitity to focus on the business problem rather than worrying which version of Spring, Maven, Cucumber, or other tools is an advantage. Are you developing to solve real problems or for the sake of the technology? We develop to make life and processes easier. As developers we have to get past our platform ‘bigotry’ and see the bigger picture. If COBOL is not your thing and JAVA is then so be it. By the way, UNIX/LINUX is only 1 year younger than Mainframe. Didn’t see anyone mark that as a dinosaur. Just sayin’.

    • Pretty good stuff there Bill, but let me throw in a few more random thoughts.

      What do people mean when they talk about Cobol or any other language being fast or slow?

      Execution speed depends on the executable code generated by the compiler and is not readily apparent to the programmer. Well written Cobol with an optimising compiler is pretty slick.

      Speed of writing a program depends in part on the ability of the programmer to use facilities to include pre-written code, such as record layouts, or even Procedure Division code.

      Then there is the ability to reuse separately compiled modules.

      It is over 20 years since I have written Cobol and I taught myself from the previously mentioned books, published by Mike Murach and Associates, in a few days and was highly proficient. Cobol was easy. I could start writing Cobol again tomorrow.

      One of the arguments I have heard for its longevity in the commercial world is that it is so ‘English like’ that non-programmer auditors can easily read it, something not possible in other languages.

      That said, I also have some experience with OO languages and acknowledge the benefits of OO.

    • Right on, Bill. I will submit that the presentation layer of data should keep up with the various display technologies (pads, smart phones, and so on). My only complaint is that these devices mask a deeper issue – performance. Many people blame the network but I’ve also found that the backend DBMS can also be an issue. Can the DBMS be tunable or is it a Microsoft WINTEL thing? (like SQL-Server). Can the DBMS scale to over 100K users with 10K concurrently? (hitting enter or the whatever button at the same time).

      This is why I would not count out COBOL and mainframes just yet. They work well with what they are designed to do – deliver data VERY FAST. (oh, gawd, I hear the Oracle people now…)

      Even the worst COBOL program on a mainframe given x amount of data from a RDBMS than a JAVA routine running on windows against SQL-Server. That is why you will not see any banks or financial systems get off the mainframe. Go ask Schwab what they run, or JPMC, or Delta airlines (DB2 backended to mainframe running dynamic SQL), TSYS (largest card card clearinghouse in the East US).

      Note to people getting into this industry – Don’t get fooled by the pretty packaging of things that are easy, follow the opportunities.

  40. Excelente artículo lleno de razón. Después de programar en COBOL durante años, nos dijeron que iba a desaparecer. No me lo creí y perseveré. Ahora soy formadora en el entorno ZOS (también en PLI) para distintas consultoras y como máximo, en grupos de 15 alumnos cada vez. Poco, para la demanda que sigue existiendo aquí en España, donde somos unos pocos profesores que viajamos por el país allá donde nos necesitan. Siempre me ha gustado programar en COBOL aunque implique mucho código y le estoy muy agradecida, pues es y ha sido mi medio de vida. Comprendo que tarde o temprano volverán a incluir esta materia en la universidad porque hay un problema crítico en no muchos años vista pero nadie parece darse cuenta.

  41. i think here you not talking something about cobol and mainframes, that the asembler its diferent, and that its an extra security issue, no easy do overflows etc.

  42. I think it is very smart. It is in plain english. Easy to reed, and I suppose it is fast. I also thought it was dead. I wrote some programs 40 years ago on a course. Well there is a lot of hate of Assembler, Fortran, Lisp,Cobol, Pascal and even C. They are still used. So what should you use for business and administration? Pyton?Perl?C#? Mathlab i stead of Fortran? The old languages are there for speed and efficiency. What is the point of creating new resource hungry, slow and complicated languages when we use more and more small gadgets. I write this on an Android and not a gaming machine that costs 4000 dollars. It has limitations.

  43. I have been a cobol programmer for 43 years. Nothing beats a Db2 data base and cobol to fix some bad sql that broke the data base, screwing up all the data. PC programmers are lost when this happens. With Cobol 4 you can have JAVA and XML mixed in. Do you know what broke the health care web site? Version’s Cloud. It was replaced with a DB2 data base. Now it zooms along. Nothing is more hack proof than a DB2 main frame data base. All you Tech Service guys have to do is remember to remove the “GUEST” user id. Remember that!!!!!!!! I have had a great career and have made lots of money knowing COBOL. After I retire, I still want to code in Cobol. By the way, get your self a good Cobol batch debugger! Nothing teaches you Cobol faster or finds a bug faster. A debugger also shows you what the program is doing and you can watch every line execute and see what is in the fields. RSA and other PC tools have great debuggers, but, you should demand a batch debugging tool if you are maintaining Cobol code. Even through I have worked in the JAVA world, I like COBOL best.

    • Hi Dr COBOL, I am also a COBOL programmer of 34 years. It is harder and harder to find COBOL contracts now because of offshoring of work. Do you have any suggestions of how to get COBOL work now, also work that pays. Since offshoring of the work there are fewer onshore COBOL DB2 contracts and if there are they pay junior rates.

  44. This article as many others talk about needing COBOL programmers to replace the programmers that are retiring. But it is not mentioned that a lot of the COBOL programming jobs have been sent offshore to India. So north America has another country supporting its financial systems and also these people have access to the clients personal and financial information.

  45. I’ve tried various other languages but I keep coming back to COBOL. Why:
    1) It’s self documenting and self-documentation never goes out of date.
    2) It’s a lot faster/efficient than any other language I’ve used.
    3) It could be programmed using voice recognition.
    So, I think COBOL will make a come-back, once the current management have retired (the ones who never could code, so blamed the language) but driverless cars? No chance!

    • Hey, try C#, and not a “Hello World” example, you have to dig a bit deeper to start seeing the benefits.

      You can quickly write a HTTP Restful service with open standards security, permissions, data storage, validation, caching, logging, monitoring and notifications, that will scale across servers and can be recommissioned dynamically at runtime depending on the quantity of requests. Impressive? Well maybe not until you realise you can do that all with about 20 lines of code in about 10 minutes (per exposed method – if you know what you are doing). That’s without using any third party tools or taking into account gains made from DRY principles across endpoints.

      Progress doesn’t always bring benefits, but sometimes it does, and if you don’t think a couple of generations worth of technology advancement has brought anything to the development arena then it is time to retire because there is no hope lol.

      On the speed note, C# is not significantly slower than native after JIT compilation for a lot of things. It has been carefully optimised over the years and has come a long way. Not as quick as assembly, but that is more due to being able to trim out unnecessary operations than a differential in speed between operations.

  46. This article was enjoyable but at various points misleading. Without having an axe to grind, let me add some points of clarity for consideration. The present benchmarks for performance have the COBOL language (executing on the IBM mainframe) 400 times faster than the JAVA language (executing on any server platform). For more perspective, the non-objectified C++ language has been benchmarked at 600 times faster than JAVA.

    I routinely code in both languages although in appropriately different settings–not on the same job site. I lead a double life in IT. I will tell you that COBOL can be utilized to develop about 70% of what can be developed in C++. It even has a long-standing GUI brand known as “CICS COBOL”(historically referred to as “command-level COBOL). This CICS brand was multi-threaded years ago well prior to the advent of modern languages and platforms with which we now accomplish such. And, “objects”? We knew those in the mainframe environment as simply sub-routine programs, statically or dynamically linked.

    Though I favor C++ the most, I have found COBOL to be highly amenable to modern demands and constructs. Without any gnashing of teeth I have been able to code COBOL with modern techniques which favorably impact the applications that live on the mainframe platform. The pieces like a medium sized Lego set have been there since the ANSI version 2 begining in the nineties.

    And the IBM mainframes of newer vintage–the Z12 and Z13–now compete with Cray Supercomputers. It is true. To this day the IBM core processors are 5.4 GHz rated for continuous duty. Intel (who I like a lot) is still a piker when it comes to this caliber of CPU performance. The Z13 box just realeased last year is designed to virtualize 8000 servers simultaneously running any mix of server OS that a site fancies. Folks laughed two or so years ago when IBM exited the physical server market. Sillies asked, “Servers are booming, what the heck is IBM is thinking?!”

  47. Hi,
    I am a COBOL programmer with more than 25 years experience and looking for COBOL dev. service/work from home. Does anybody know where to look for to offer my services (platform, freelance etc.)? Thanks a lot for any hint…!

  48. I’m a 55+ programmer “weaned” on COBOL, and I’d be more than happy to supplement my retirement with a bit of contract programming work – bring it on!

  49. I’m not old but ancient. Have programmed/designed/managed software since 1963 at all levels up to CIO. Always hated COBOL, never sure why PL/1 didn’t replace it in the 1970s but programmer resistance to learning something new was definitely part of it. The point about the heavy reliance of mission critical large OLTP systems on CICS or IMS-DC is valid. One reason is that so many of the projects to replace these systems failed disastrously and expensively. The 1990s saw many such projects as an alternative to remediating Y2K problems but many failed and were abandoned. Stories of abandoned projects continue in the media, although I expect that others are not publicised. Now out of the industry, I would be interested to hear of more recent statistics for such complete replacements, not just surrounding old code with web interfaces. Now as a hobbyist I find programming in C# or Swift more interesting but probably less productive than my old professional environment but it should be recognised that there is a large difference between what works for a small team writing code for a mobile phone and for teams of hundreds collaborating on a high transaction volume TP system with many thousands of simultaneous users. Good luck guys, I’m still a dependent user of many of them!

    • ‘ Always hated COBOL ‘. That’s a bit emotional for a programmer.
      If you had been taught by trainers who genuinely understood COBOL particularly in relation to the human aspect of it, such as structured programming, egoless programming, table processing, minimum coupling, maximum cohesion, working-storage prefix’s, section & paragraph prefixes, global modules, subprograms, the KISS concept, hierarchy structure, peer walk-thru’s, & use of genuinely meaningful procedure & data names that people who have to maintain your code can understand, then maybe things would have been different for you.

  50. If the number of codelines is relevant to “being a terrific language” then why didn’t we keep using RPG? Takes a bit of a learning, but I can code in 2 lines where in Java you need 10!

  51. I think it would be good for the owners of the businesses to get their children and grandchildren to learn the language.

  52. The continuation of COBOL is just reflective of the deep conservative views of some people working in technology. Modern programming languages have adapted to provide productivity for modern applications, COBOLs biggest problem is that it takes forever to program anything complex in it. Which leaves you often struggling with antiquated middleware licensed at horrendous cost by IBM.

    Besides COBOL implies mainframe, and that is both costly, inflexible, difficult to apply concepts like geo-resilience and it tends to be commissioned in massive steps rather than being flexed dynamically, it also always needs a lot of looking after. It is all a ridiculous setup that has no justification in the modern world.

    IBM live in a delusion and their marketing spin despite being laughable is suckering ignorant managers. Yes you can buy a Z13 that can do 2.5 billion transactions a day, but I can do that on two middle range dell servers these days (if I program for performance and small transactions) at 100th of the cost. Not only that I can get the software delivered on them at 100th of the cost and time due to the productivity and availability of resources for the modern languages it supports.

    IT is full of know nothing idiots who refuse to learn anything new. It presents an existential problem to businesses as it can’t be maintained (due to it never being designed for applications of modern complexities). It will be the story of the 2020s, multi-nationals failing as they either can’t compete or can’t even function because they are hobbled to 70 year old technology. Does that sounds an unreasonable prediction if you think about it?

    • Could not agree with you mate.

      ‘ The continuation of COBOL is just reflective of the deep conservative views of some people …’.
      I think the reason is ‘ economics ’.

      ‘ Besides COBOL implies mainframe ….’.
      Microsoft brought out a COBOL compiler for PC’s in 1984. Similarly, Microfocus. And COBOL has got better & better via evolution.

      ‘IT is full of know nothing idiots …’
      Yet, IT has produced productivity gains measured in orders of magnitude.

      ‘ It will be the story of the 2020s, multi-nationals failing as they either can’t compete or can’t even function because they are hobbled to 70 year old technology ’.
      Yes I know – those Babbage machines must be wearing out already if they haven’t been keeping them oiled.

  53. it is a very hopeful article for me. Too bad I have to wait to become so much in demand. I am looking for a job now.

  54. ‘ … walk into their offices and sit down to start coding in 1959’s COBOL ‘
    You forgot to say that COBOL has evolved since the 1959 version.

  55. I totally agree with Kevin O’brien when he says
    “…. structured programming, egoless programming, table processing, minimum coupling, maximum cohesion, working-storage prefix’s, section & paragraph prefixes, global modules, subprograms, the KISS concept, hierarchy structure, peer walk-thru’s, & use of genuinely meaningful procedure & data names…”
    I would add “extreme refactoring”.
    I think the main Cobol problem are the Cobol programmers not applying those rules.
    About transaction performance, i have to say that some time ago i make an attempt to convert my Cobol software based on indexed files to Postgres database.
    There was no game: Cobol software was 10 times faster , so i dropped the project and now i am bounded with Cobol waiting for somenting having the same efficiency.
    “You forgot to say that COBOL has evolved since the 1959 version”.
    And (maybe) also forget that the writing of Cobol software TODAY has nothing to do with 1959 coding or at least should have not.
    ‘ Besides COBOL implies mainframe ….’
    Absolutely i don’t agree, there are many and many graphical Windows software packages written in Cobol that are indistinguishable from something written with VB, because…yes, it is possible to write event-driven programs in Cobol.

    “You can quickly write a HTTP Restful service with open standards security, permissions, data storage, validation, caching, logging, monitoring and notifications, that will scale across servers and can be recommissioned dynamically at runtime depending on the quantity of requests. Impressive? Well maybe not until you realise you can do that all with about 20 lines of code in about 10 minutes (per exposed method – if you know what you are doing). That’s without using any third party tools or taking into account gains made from DRY principles across endpoints”.
    Yes, but if i have to do something like this, i don’t use Cobol.
    If i have to go to mall to buy cigarettes i don’t take an airplane, but the bicycle even if is a 150 year old transport, so if i have to manage something Cobol does better than other tool, i use Cobol.