COBOL still not dead yet, taking on the cloud

COBOL still not dead yet, taking on the cloud

Summary: Common wisdom says that COBOL should have died years ago, but the language that sits at the heart of financial systems is still around, and making moves into the cloud.


"It's almost impossible for most people, in our day-to-day lives, to avoid a COBOL application," says Stuart McGill, chief technology officer and general manager of Borland for Micro Focus. "COBOL applications tend to be the ones we can't really do without."

Approaching 30 years with the company, it's fair to say that McGill is familiar with the ins and outs of one of the oldest programming languages around — a language that still sits at the core of the financial world.

"Normally most transactions that we go through everyday would be supported by COBOL applications, still are, have been for 30-40 years, probably still will be for 10 to 20 at least," McGill says.

For decades, COBOL has been running on the heavy iron that occupies the computational core of many banking institutions — it's a sector that is traditionally conservative and waits for the technology hype cycles to pass before extracting the tangible gains on offer. With the advent and proven advantages of virtualisation, and the acceptance of cloud as a viable platform, COBOL is beginning to move from the mainframe, and heading into the cloud.

Conceptually, taking a language that can trace its heritage back into the 1950s onto a modern as-a-service platform may seem like an exercise in futility, but McGill says that it is a transfer that is not as mind-bending as it first sounds.

"Believe it or not, it's probably easier to move COBOL into the cloud, than it is to move a C/C++ application into the cloud. It's certainly easier to a COBOL application to the cloud, particularly from a mainframe environment than a client-server, and Microsoft-based client-server [environment]," he says.

COBOL's mainframe-focused design and experience, allows for applications to focus on what it does well — transactional processing and business logic.

"A lot of the concepts are pretty familiar," said McGill. "For example, most IBM applications use CICS, which is psuedo-conversational i.e. you almost have applications that are almost RESTful in a very limited way by their very nature, whereas RESTful state or psuedo-conversational state just doesn't exist in client-server applications, that means [to take such an application to the cloud] you have to re-architect an application and therefore almost start from scratch."

"Whereas from a COBOL perspective, you almost have some of the concepts you're actually looking for already built into the infrastructure that surrounds COBOL applications and has done for many, many years. The infrastructure layers in a mainframe application are built around languages just doing processing, data is optimised through various layers to cope with huge amounts of data very quickly either in serial mode, or in some degrees, parallel."

That's not to say that COBOL is a magic cure-all that the industry has maligned for half a century, there is one area where COBOL is terrible: User interfaces. McGill says that aspect of the language has actually helped its survivability, by needing to separate the UI from the core logic, as form factors have changed over the decades, it is the presentation and interface layers that have changed, not the core processing itself.

"They would have had to change the UI, yes, and the databases would have changed, but as far as the code was concerned, they haven't been forced to make any changes at all," McGill says.

"Largely speaking, you don't really want the business logic to change that much. Rules do change, but actually, most business, if they are certainly transaction orientated, their business is the system. The bit that is unique about them is wrapped up in those systems."

"It's both good and bad, all the foibles and things that you'd like get rid of are probably in the same systems, but all the things that make that company unique are also wrapped up in that."

As the number of actors on the system grew from tens of users in the mainframe days, into the thousands during the early days of the internet, and now into the millions of users nowadays demanding instant, realtime access from a plethora of devices, the core transactional systems are coming under increasing pressure.

"In the case of Bank of China, you've got 318 million account holders, all of them wanting to hit core systems day-in, day-out," McGill says.

"What that means is that even mainframe systems start to struggle with the sheer load that's been placed on them, so one of the reasons why pretty reasonable sized corporate entities want to move all of these really important systems in the cloud, i.e. COBOL in the cloud, is they have to just to cope with demand."

"We really do start to see now, the first wave of big, really important customers, really trying to understand how they are going to use cloud for core systems delivery, and that will spur on the next generation of client-based applications"

With the move of business into the cloud, the temptation is always there to replace legacy systems with the latest and greatest languages and frameworks on offer, McGill though, has seen it all before. COBOL, he says, could have been replaced in the early transition to distributed computing or in the early days of the PC — the hardest time he saw for the language was in the days of client-server computing. After that threat, everything seemed ok in comparison, as the industry moved onto intranet and internet-focused computing before arriving at today's landscape where mobile and cloud appear to be the signposts for the future.

As COBOL and its practitioners have soldered on, so has Father Time, and its changed the way that COBOL is developed.

"In terms of guys that really know the old mainframe systems, their getting old. But they are pretty unique in one way, that their careers are typically tied around one application — they weren't COBOL programmers, they weren't even mainframe COBOL programmers, they were home insurance or car insurance application developers," McGill says.

"The big problem for most businesses is not the age, apart from the fact that they are going to retire, it's the fact that these guys are so productive. They don't need any fantastic tooling to tell them what a single line of code change actually looks like, they probably know exactly where it needs to be, can get it to immediately, make the change, and they know where all the impacts are going to be — so they are highly productive people."

At the other end of the spectrum are the younger programmers and graduates who are coming from a world dominated by Java, JavaScript, HTML, PHP, Python, or Ruby. They know lots of languages.

"The key difference is now they haven't got application knowledge, but they have got domain knowledge." McGill says. "They know visual studio, or they know eclipse, and they've got other languages."

Due to the different ways in which modern programmers work, McGill says that Micro Focus has had to take the tooling to higher levels.

"They're used to plenty of tool-centric approaches to language rather than a language approach to the environment," he says.

"The key for COBOL has actually been to make it really consumable by programmers in the new environment, and as simple to learn as possible."

Looking to the future, McGill says that due to the risk-adverse nature of institutions invested in COBOL, the shift to cloud is only getting started.

"The customers are very conservative. We've been talking about COBOL in the cloud, believe it or not, probably for five years"

"What you tend to see is as everyone is getting bored with the cloud, actually, the real stuff is just about to get on the platform — and it forms the bedrock of the next-generation of applications."

Topics: Cloud, Banking, Enterprise Software


Chris started his journalistic adventure in 2006 as the Editor of Builder AU after originally joining CBS as a programmer. After a Canadian sojourn, he returned in 2011 as the Editor of TechRepublic Australia, and is now the Australian Editor of ZDNet.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Why not take the chance to shed COBOL when going to the cloud?

    Umm - Why not take the chance to shed COBOL when going to the cloud? Why have a COBOL cloud at all?

    Time to move to SQL. It's not just a database - it's a query language as well.
    • Because SQL isn't suited to business manipulation.

      It IS suited to database manipulation... but even in the beginning, SQL has never been a complete language.

      There is some overlap, but lacking a number of features prevents it from handling the job It is very poor at validating data for one thing - hence all the injection vulnerabilities. And that leads to its failure at separating data from procedure. Papering over this failure is why it always gets embedded in yet another language. If anything SQL is even worse at UI than COBOL.

      And due to the fact this separation failure, it also sucks at communication. It can't mode data from the database to the application that needs it very well (VERY slow). Do something entirely IN the data base - it does acceptably well (not great though). But many business operations can't be done that way.
      • thoughts

        "It is very poor at validating data for one thing"

        Usually done by the UI (which is usually in a different language, even in the case of COBOL), and actually CASE expressions aren't hard to write.

        "hence all the injection vulnerabilities"

        Has nothing to do with data validation - and everything to do with terrible language design decisions by the SQL language authors, which don't establish clear boundaries between data received and the language itself.

        Yes, frankly, they should have designed the language better - although there are ways around it (ie, using "prepared statements" and "parametrized queries").

        "If anything SQL is even worse at UI than COBOL."

        Not that you should ever be using COBOL for any sort of UI in the age of web applications.

        Not sure what you mean by "mode data from the database." Can you clarify your usage of the word "mode?"
        • Sorry

          That was supposed to be "move".
        • Now using COBOL for a CGI language wouldn't be that bad.

          Tedious maybe, but doable.

          It already has built-in capabilities for tables, columns, and row data forms.

          And the new features of the language extend that a lot.
    • One reason would be...

      ...rewriting a large system from scratch is expensive and "often" (more or less) results in disaster. If it isn't broken, don't fix it. I was surprised to see the modern concepts that have been added to COBOL (a MicroFocus employee has posted a few articles on CodeProject about using COBOL with .NET, for instance).
      • I'm sure COBOL devs are expensive too.

        "...rewriting a large system from scratch is expensive"

        Although I imagine COBOL devs are expensive too. One of my professors said that being a COBOL dev is a pretty good job if you can get it, because companies are desperate for COBOL devs and so few people are willing to work with that language anymore.
        • COBOL actually is a hard language at all

          It's more like English than any other programming language. The hard part is that it's not really taught anymore, and that because of it's age it requires a different form of thinking than is taught in modern computer science courses. It focuses on business logic, and not complex algorithms. It has become a pretty modern language though. The last standard ratified was in 2002.
          Jason Joyner
          • edit

            "isn't a hard language at all"
            Jason Joyner
    • SQL? Maybe No SQL is a better option

      If you plan to move away from COBOL then go to where the puck is going to be, not where the puck is. Go No SQL, that is more in line with COBOL's variable record definitions.
  • long live cobol

  • COBOL will NEVER die!!!

    I've been working with COBOL since 1977. It has been a staple of my career. I have been thru the client-server, n-tier, "this is the newest replacement for COBOL" garbage for decades. It still does what it was designed to do: manipulate data and encapsulate the rules of the business.

    Yeah, go ahead and use a pretty GUI for the front-end. But leave the heavy lifting where it belongs....with COBOL.
    Jerry Roberson
  • A key strategy going forward!

    I feel that COBOL has been seriously underestimated by those who run to the latest thing, instead of assessing the quality and merits of so-called "legacy" offerings! These are the same people who would even try to assert that the desktop, and its prime feature, Windows, are "legacy". Phbbbt. Why even listen to such buffoons?!

    Be assured, when I am named the new CEO, the strategy I am already, even now, cultivating for COBOL will make waves. There is a whole ecosystem of COBOL out there, that just needs freshening up. I'm thinking we modernize it a bit, by adding a new font on those green screens, and a startup logo:

    # # #
    # # # # #
    # # #

    If the troops have extra time, we may even implement an internal Innovation Program, and hopefully bring a GUI to COBOL! I'm already thinking of names: COBdows, WinBOL? It's going to happen...under my leadership, Microsoft would remain the world's technology leader by getting there first! My main fear is that the folks at Goggle may already be working on it.

    Ok, enough for now. Probably should have checked with Legal first to see about disclosure issues, but I believe it critical to keep developers informed of what is coming! Keep your MSDN updated so you can get the Visual COBOL.Net bits when they hit the wire. Developers, developers, developers!

    Off to Herman's for lunch with the rep and a status check on what is taking so long on the CEO decision?! (Should be a no-brainer!)
    • Unlucky...

      You're aware that Micro Focus (mentioned above) have beaten you to all of those things right?

      Maybe PA to the CEO may be a better aim for now...
      Allan Benoit
  • Bad Flashback

    The mention of COBOL brings back bad memories from my Uni days.

    Like writing many pages of code on gridlined paper which was then converted by grumpy typists into punched cards. After about a week, you'd get your punched card pack to then submit for a "run" on the mainframe.

    Another few days passed the you'd find your program failed due to a missing comma or something.

    Repeat process. After about 4 weeks you' finally get a successful result.
    By this time, you have forgotten how you wrote the code.