COBOL- still standing the test of time

Posted on 30. Apr, 2012 by in News

The debate over COBOL’s continued relevance and indeed its future continues to persist in the developer community and IT world in general. But while every business has its language preferences, there is no denying that COBOL continues to play a vital role for enterprise business applications. COBOL still runs over 70% of the world’s business and more transactions are still processed daily by COBOL than there are Google searches made.

While many also debate the status of Java in relation to COBOL for business applications, COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations, so often the case when addressing the ever-present issue of IT debt. When many businesses are facing mounting IT debt, the average cost per line of code for COBOL was projected to be £0.80 whereas the cost to address Java quality issues per line of code was £3.47, according to a recent IT study.

The benefits of COBOL, however, are not found in its exclusivity, but also in its ability to comfortably co-exist with other programming languages- such as Java – that are typically used to build new front-ends for new platforms and devices.

COBOL can function efficiently for vital business applications as a reliable language while also liaising with languages such as Java and C#, typically used in the construction of new interfaces; these languages combine forces in helping businesses deliver the services to support new requirements such as BYOD and other mobile initiatives through renewed, composite enterprise applications. While some in the industry may doubt COBOL’s relevance for today’s business applications – mainly due to its considerable age as a programming language – the fact that it has been vetted and proven over several decades actually stands in its favour: much of the required “new” functionality already exists, written in COBOL. It is merely a question of how it is made available to the user.

Add to this the flexibility of the language to be adapted for future needs, and its ability to liaise with other front-end  technologies, and COBOL remains a lower-risk option for businesses because of its prevalence over the past half a century, and not in spite of it. It is a myth that IT organizations must choose between one language and another – they can in fact work with whichever language(s) make most sense according to their business requirements. And ageless COBOL continues to meet those needs.

Tags: , ,

10 Responses to “COBOL- still standing the test of time”

  1. Ken

    01. May, 2012

    Some may read news articles and news stories about the CRASH report and conclude that COBOL is good while Java is bad. This is an oversimplification of the commentary and analysis, but it summarizes the gist of some of the commentary and analysis. However, a reading of the Summary and some independent analysis might lead one to a very different conclusion.

    One can find many quotes online, often without any source documentation, that COBOL usage in the business world accounts for 80% of the world’s computing business—private sector, public sector, and higher education. The Gartner Group is frequently cited as a source for this number, but Gartner Group data and research is not freely available to the public to confirm this number.

    One can browse a lot of Gartner Group research online and free of charge. Summaries of research can be viewed, and keyword searches sometimes reveal perhaps poignant observations.

    The COBOL wiki page cites the 80% number, and the date of the pronouncement is claimed to be from 1997—more than 14 years ago. Many COBOL programmers working in the industry between 1997 and 2012 will attest to the disappearance of many COBOL jobs through outsourcing, the conversion to other programming languages, the conversion to software packages, and perhaps other reasons. Assuming the 80% number was correct in 1997, one should probably view the 80% number with a great deal of skepticism in 2012 and beyond.

    In the CRASH report, COBOL applications account for just 11%—50 out of 745—of the applications submitted and assessed by Cast Software. It seems reasonable to conclude that either COBOL is not used as widely as it once was, or COBOL was not represented proportionate to its market share, or both. If COBOL was not proportionately represented in the CRASH report study, there is likely any number of reasons why.

    The CRASH report indicates no difference in quality between in-house development and out-sourced development. This conflicts with the experience of many senior COBOL programmers.

    The average price of coding violations was assessed at $3.61 per Line Of Code (LOC) with COBOL being the cheapest at $1.26 per LOC and Java the most expensive at $5.42 per LOC—see Figure 22 of the CRASH report. However, because COBOL is a verbose language this number is very deceiving. The CRASH report states the average software component contains 20 to 50 LOC while the average COBOL component contains over 600 LOC. Lines Of Errors (LOE) are not reported, but if LOE is proportional to LOC, then COBOL errors could actually cost between three and seven times more than Java errors.

    The CRASH report summary is not the full report, and thus it is difficult to make concrete observations. However, given the extremely tiny subset of software applications analyzed—just 745 from the U.S. or perhaps the globe—it is difficult to treat the report details as absolute.

    Reply to this comment
    • Micro Focus

      01. May, 2012

      Thanks for your reply. It is great to hear from readers who have found our blogs of interest enough to want to comment. All ideas are very welcome.

      It is worth reinforcing the main thread of the blog, here, which is less questionable perhaps, which is the necessity for IT organizations to find ways for their core application logic and business systems to find ways to integrate, co-exist and continue to add customer value. COBOL has been integrating with all technologies around it for decades now, so the prevalence of Java, for example, as a language of choice for new application front-ends, is merely another support point that COBOL has quickly and seamlessly embraced. Similarly so for C# and so much else. COBOL enables organizations to get on with the business of serving its customers better, rather than worrying about technical challenges or architectural policy. Micro Focus’ investment in the portability and “future-proofing” of the language and ecosystem (about which we have blogged recently) only serves to reinforce our belief that smart IT is all about collaboration. So our assertion is that language choice isn’t about what’s good or bad, but about what makes most business sense.

      Regarding your comments, we would certainly echo the view that industry “reports” such as the CRASH report and even studies undertaken by larger organizations such as Garter, are always by their very definition, going to be selective to some extent. Additionally, information contained in Wiki sites, journalist reports, and perhaps most self-evidently information from vendors themselves, are going to rely on a viewpoint that isn’t necessarily as balanced as might be possible from a truly independent commentator. It was merely the intention of the blog to cite reference points that were available at the time to act in support of a point being made. It was our hope that some of the information cited would support the arguments being made rather than detract from them. You raise a great point that that it is important to draw one’s own conclusions about how much relevance to attach to individual references.

      Back to the blog. We’re happy to hear more stories about composite COBOL and Java/C#/etc applications and how they have made a business difference and welcome any more comments. Thanks again for taking the time to comment.

      Reply to this comment
    • Pete Dashwood

      12. May, 2012

      Hi Ken,

      I s’pose I better make it clear that I don’t know you and there was no chance of us colluding on our posts :-)

      To be fair to Micro Focus, they deserve credit for posting comments (even dissenting ones) on what is actually a corporate blog and keeping an open and fair discussion.

      Although I don’t personally put any credence in the Gartner figures, I don’t think it really matters whether there is a HUGE COBOL legacy or there isn’t. That legacy base is being eroded every year as people vote to move on.

      The concern I have is that all possible value gets leveraged out of that legacy BEFORE COBOL is discarded. Micro Focus provide an excellent implementation of a fully Object Oriented COBOL compiler for .Net (Visual COBOL) and this is definitely a step in the right direction when it comes to “objectifying” legacy COBOL.

      The future is in LAYERS and OBJECTS.

      At least in my opinion, Procedural code, whether it is in COBOL, Fortran, RPG, or PL/1 is NOT the best tool for implementing that.

      Reply to this comment
  2. Pete Dashwood

    03. May, 2012

    Hi Derek,

    I visited and read the post as you requested in comments on my DZONE article.

    I enjoyed your article here but I would have to take issue with a number of statements. I’d enjoy debating some of this with you over a pint , in a friendly way. However as I am in NZ, that is unlikely to happen… :-)

    I have made a few quick comments below, but I think you’d see my position better if you read the piece I wrote recently on the relevance of COBOL and the implications of moving on from it. Here’s the URL: http://primacomputing.co.nz/cobol21/COBOLRelevance.aspx

    I migrated away from COBOL to C# and .Net about 4 years ago and since then I have helped a good number of other people do so too. I really do understand the issues in this and I have no axe to grind about compilers or flavours of COBOL.

    OK, quick comments on the above…

    Some of the claims are unsubstantiated and unsubstantiable. I don’t personally believe there are more transactions processed in COBOL than hits on the Internet daily. There MIGHT have been for a brief period around 10 years ago, but most of this kind of hyperbole is based on a Gartner report which came out around that time (and has since been disclaimed by Gartner themselves, as impossible to verify), where they claimed billions of lines of code etc.

    However, I don’t wish to argue the relevance of COBOL on those grounds anyway. The inescapable fact is that the paradigm has changed and COBOL is no longer the best tool for the job when it comes to development for distributed systems.

    COBOL still remains excellent for batch processing (which is based on the centralised single processor architecture which saw us through most of the last century), but modern systems are designed and distributed in ways that allow load levelling, parallel processing, support for multiple cores, all of which make batch processing redundant or at the very least, largely unnecessary..

    There is, of course, a HUGE legacy of Business Rules bound up in COBOL and the refactoring of this functionality is of major concern for organisations moving on from COBOL.

    (My personal concern with this is that some companies are being told all they have to do is recompile for .Net and their worries are over. It is nowhere near that simple; the legacy needs to be refactored into objects that can run in an OO world (like .Net or Mono), as OBJECTS and in LAYERS, rather than a single monolithic block of code that does everything..) Fortunately, a good deal of this can be done by tools, which removes the tedium and the errors in doing it by hand.

    As for having stood the test of time, there is nothing wrong with COBOL as a language, but times change. It isn’t just fashion, there are very sound reasons as to why you might move off COBOL.

    You said it costs less to maintain per line than Java does but if every line of Java is equivalent to 5 lines of COBOL, that doesn’t mean much…

    For myself I have found approximately a 4:1 ration between lines of C# and COBOL. 4000 lines of COBOL can usually be done in around a 1000 lines of C#. While I’m not suggesting this is a scientific fact, it is based on empirical evidence from a COBOL base of around 500,000 lines.

    Java is free. C# is free; you download it for nothing, tuition in it is free, (There are channel 9 videos on MSDN to help people get started.). Support and code samples are free. (I have never failed to find what I was looking for using Google, in seconds – compare this with wading through a Help file). The equivalent of all these things in COBOL costs thousands of dollars.

    I don’t think you can “justify” COBOL on a cost basis…

    The subject of what we do about COBOL is very dear to my heart and I have a lot more to say about it than I can possibly cover here (or even on DZONE). However, I’ll be publishing more stuff in the near future and stepping back from the technical level to a more management oriented examination of the issues.

    Cheers,

    Pete.

    Reply to this comment
    • Micro Focus

      10. May, 2012

      The previously-posted blog features a number of references and citations that are true to the best of our knowledge. Some are quoted from secondary sources but in the absence of industry-wide empirical evidence, Micro Focus is using references that are if not cast-iron facts they are at least generally viewed as credible sources. One could easily debate the veracity of all but the most primary evidence as dubious in some measure, but to strip the blog bare of any reference points would, it was felt, detract from its value. This true for the Gartner reference and also citing the study undertaken by CAST. Micro Focus has no reason to believe that the facts as reported are in error.

      Micro Focus is posting the blog in good faith and on the basis that the reference material is true, but it accepts that some readers may find some details difficult to agree with. Such is the nature, to a great extent, of blogging.

      As for COBOL’s remaining relevance as the ‘best tool for the job’ for development for distributed systems, it is important to note here that the accepted wisdom for many organizations –including hundreds of our customers – is to use a mixture of components within enterprise applications. Typically development of front-end components and UI uses a variety of tooling but is typically often exploiting later technology such as .NET / C# or Eclipse / Java, which is highly capable and feature rich. To use a COBOL based alternative is not recommended even by Micro Focus, though if COBOL skills and COBOL-based UI’s already exist in abundance, there would be little reason to change perhaps. This depends on the customer’s own architecture, skills pool, and other considerations. But for sure the future of front-end development needn’t be COBOL based at all.

      It more on the back end where COBOL comes into its own. The response mentioned batch processing power, and that’s certainly true. Micro Focus COBOL has a proud heritage, based on the robust nature of the language, of handling massive data processing tasks, and ably handling complex arithmetic tasks, as one would expect of a business-oriented language. Furthermore, COBOL back-ends are capable of supporting a variety of front-end applications, acting as the service to a range of clients if you will. This allows traditional client server set-up, web portals and even now mobile devices to access the same service, running in COBOL to provide the same functionality to a variety of consumers through a variety of channels. Recent public demonstrations of this technology at the Micro Focus Developers’ Conference in Dallas, April 2012, showcased some of this new capability.

      Finally, a point about the driving force for technology choice. The decision regarding technology usage is a means to an end and the end is a stated objective provided by the business. Therefore the broader context of COBOL’s continuing value is a business one. COBOL was designed for the business and continues, in many, many cases to serve those businesses well. Does is need to co-exist with other tools that do particular things better? Absolutely. Does this mean that it is no longer relevant? Absolutely not. Provided business requirements such as fast time-to-market, good ROI, embracing new platforms and environment to reach new markets with existing business functions, unifying development processes and a variety of other challenges remain on the CIO’s to-do list, COBOL has a significant part to play in the success of an organization.

      Reply to this comment
      • Pete Dashwood

        12. May, 2012

        I think this is a fair statement of a viewpoint. Kudos to Micro Focus for posting comments.

        I couldn’t agree more that the Business (should) drive(s) the IT department; my comment would be that Business has changed significantly since COBOL was invented. :-)

        Reply to this comment
  3. Az

    17. May, 2012

    I work on a big Oil & Gas company which still heavily rely on COBOL running on mission-critical Solaris 10 systems for its monthly production reports. Sure the front-end has been redesigned in Java, but I don’t believe it would be feasible to migrate the whole back-end. It’s a lot of complex batch code that’s running well for years. I’d expect Mico Focus to keep its support on the Solaris platform and finding ways to take better advantage of SPARC high thread counts.

    Reply to this comment
    • Pete Dashwood

      22. May, 2012

      I think there are still MANY sites that rely on COBOL for reporting and Batcch Processing. (Applications where a centralised processor is fine…)

      However, my personal belief is that Batch Processing is a technology of the past and new systems will probably not incorporate it.

      I know this sounds like heresy and the reasons I arrived at such a conclusion are too many to go into here. All I’ll say for now is that a modern Corporate data resource should reflect the real world in Real Time and we have the technology now to realise this. When systems are designed this way, Batch Propcessing is largely obviated. (Transactions are consolidated and summarised as they occur, background threads run to provide ad hoc consolidations for ANY time period, not just weekly, monthly etc. ) Reporting can use Data Warehousing and BI tools that are specifically designed for that; there is no need to be counting filler bytes in COBOL printlines…)

      I have no problem with the site you work on, Az. SPARC is very powerful processing and what they are running is working for them.

      But I’d be surprised if they continue to develop new systems in exactly the same way they developed the old ones…

      Pete

      Reply to this comment
      • cnrao

        04. Jul, 2012

        Having worked on COBOL systems in the eary eighties , transaction processing systems and VAX VMS based cluster systems we would spend a lot of time in ensuring that the hardware was used effectively.
        Cost and business risks are always relevant and its far more easy to provide production support for COBOL based systems.
        Like biological systems , the evolutionay efficiency of cost and efficiency in rolling out bug fixes will ensure that COBOL will continue to be relevant for enterprise business systems many more years.

        Reply to this comment
  4. xboy

    12. Sep, 2012

    I used Micro Focus Cobol in the mid 90′s. At the time I was in the EDI development group, and was responsible for developing the 214 Shipment status screens in CICS on a IBM/VSE. I found some floppy diskettes that had the product on it and a guy who worked there said he tried to use it, but mainly for DATASET download and manipulation. I loaded it on my PC, and honestly, 3 months later had a fully working CICS application on my PC down to the TSQ’s. It was great, and I could debug anything. I uploaded it to the mainframe, and I am not kidding, it worked flawlessly! Since then, I have wished for that software at several companies but haven’t been able to get it. The Micro Focus Cobol has been thru several company evolutions, so I don’t even know if it is the same product. –Thanks

    Reply to this comment

Leave a Reply