Misconceptions about COBOL
Throughout history, the IT media, as you would expect, devote most of their copy space to articles about up and coming new technologies or major issues faced by the IT industry because we all love to read about new technology and impending disastrous. Remember the coverage of the forecasted Y2K catastrophe, which in retrospect went with barely a whimper rather than a big bang?
Similarly many publications have, at regular intervals over the years, enjoyed breaking the news that because a new language or development paradigm was gaining popularity, they could confidently predict that this would be the death of the COBOL language. This happened with the introduction of ADA, 4GLs, Case Tools, Client-Server tooling like PowerBuilder, Object Oriented Languages like Smalltalk and most recently Java.
The growing popularity of packaged applications was also touted as signalling the death of COBOL and the Y2K issue was itself also projected as the final nail in COBOL’s coffin because most organizations would simply get rid of COBOL and implement Y2K compliant packages rather than spend the time remediating their COBOL applications.
However the reports and predictions of the death of COBOL appear to be wildly exaggerated.
COBOL is still going strong and is still used much more than many people realize or perhaps want to admit.
As COBOL remains underpinning applications running the majority of the world’s economy, why isn’t there much more positive press coverage to counteract the articles spreading fear, uncertainty and doubt?
To answer this question, ask yourself how much IT media content is devoted to good news stories about established technology that simply does its job day after day and continues to work as expected?
Reporting each week that COBOL or CICS ‘Continue to work as expected!’ would hardly be considered news worthy or cause us to rush to renew our magazine subscriptions!
Fortunately experienced IT executives and professionals can filter out the media "noise" but they can find it difficult to combat the growing negative perceptions about COBOL derived from the continuous negative press and the negative "myths" that surround COBOL.
Such IT leaders often have to educate peers, business leaders and executives that these negative comments are in-fact myths before they can have a rational conversation and avoid making unwise decisions that might very likely have adverse effects on their business.
Fortunately Micro Focus’s customers have been able to do this and these IT executives’ reputations have been enhanced as the advantages of re-using and extending their COBOL assets have delivered significant business benefits without investing in high cost, high risk alternatives.
Debunking the Negative Myths about COBOL
There are numerous negative myths or misconceptions about COBOL that Micro Focus encounters on a daily basis – here are just a few of the most common ones.
1. Shutting down existing hardware means you have to replace all COBOL systems
As the negative press around COBOL is often related to systems running on mainframe or mid range platforms, there is a perception that COBOL is still only available on these platforms.
Due too this perception, if an organization is planning a move to Windows, UNIX or Linux, a frequent initial reaction is that they will have to abandon their working COBOL systems.
NOT TRUE:Micro Focus COBOL has been available on microcomputer systems since 1976 and today is available on all popular Windows, UNIX and Linux systems from all hardware providers.
Working COBOL based systems can therefore be moved to any of these environments with relative ease compared to alternative re-write or replacement strategies.
2. COBOL applications are difficult to maintain or change without introducing errors
As COBOL systems are typically ‘business critical’, they have evolved and have been extended over many years to meet the changing demands of the business. These applications have therefore grown over the years to adapt to new business processes, legislation and customer demands and are often the organizations largest and most complex applications.
Such applications are more difficult to maintain than small applications performing simple tasks so the perception that COBOL applications are difficult to maintain has arisen.
NOT TRUE:The difficulty is due to the size and complexity of the applications and NOT due to COBOL being inherently difficult. In fact, if these applications had been written in a non purpose built language they would be orders of magnitude harder and more costly to maintain.
So in fact the opposite is the case, COBOL applications are easier to maintain than applications written in any other language, but no other languages have endured for as long as COBOL and so such applications seldom reach the size or complexity of COBOL applications.
By exploiting the self documenting nature of COBOL combined with modern COBOL analysis and development environments it is far less risky to apply changes to large, complex COBOL systems than it is to apply changes to any application of similar complexity written in any other language.
3. Applications written in COBOL can not be enhanced fast enough to meet current needs
This perception has arisen because the majority of organizations and COBOL programmers are still utilizing traditional mainframe based COBOL development and testing technology, in environments where the developers are dependent on a relatively small amount of mainframe MIPS allocated for development and test as opposed to production.
These mainframe based COBOL developers can not edit source, compile programs, unit test and debug issues in the rapid way that C or Java programmers can. C or Java programmers are typically using Integrated Development Environments (IDEs) on dedicated desk top machines with instantaneous response times. The IDE each programmer uses have been specifically designed and tailored to enhance the programmer productivity when updating and enhancing C or Java applications.
The result is that mainframe based COBOL developers cannot deliver high quality enhancements to the applications as quickly as they would like and as the applications are written in COBOL the perception has arisen that its something inherently wrong the COBOL language or COBOL applications that is the cause of the issue.
NOT TRUE:There is nothing in the nature of COBOL or COBOL applications that impacts programmers’ ability to enhance them quickly other than the fact that the applications are typically some of the largest and most complex within an organizations application portfolio.
However, the COBOL development and testing tools and the environment utilized by programmers can have a major impact on their productivity and hence their ability to deliver fast enough to meet the business’ needs.
This is why Micro Focus produces our market leading COBOL IDEs specifically tailored for rapid COBOL development. These provide COBOL programmers with the same contemporary development environments used by C or Java programmers and have been proven to increase programmer productivity by as much as 50% compared with traditional COBOL development tooling.
These IDEs can therefore have a dramatic impact the COBOL development team’s ability to deliver enhancements to existing applications in the timescales the business requires.
Micro Focus delivers specific IDEs depending on where the COBOL applications are deployed i.e. Windows, specific Unix or Linux platforms, IBM mainframes running z/OS or IBM mainframes running z/Linux.
If your development teams can not deliver as fast as your business requires then this is more an issue of tooling and development process which Micro Focus can help you address rather than anything inherently wrong with COBOL or your COBOL applications.
4. COBOL is old and so can not be used to deliver modern business applications
There is a perception that because COBOL started becoming the main stay in the 1960s it has not evolved much and so does not have the capabilities required to deliver the business applications of the 21st century.
NOT TRUE:The COBOL language is indeed an old and mature language but any perception that it does not have the capabilities to deliver modern business applications arises from the ill informed who are not aware that the language has also evolved to enable it to stay relevant and integrate with the most contemporary of technologies.
The basic strengths of COBOL have been enhanced and extended so it provides excellent modernization and extension capabilities.
COBOL can now run in an optimized fashion on any modern platform, integrate with J2EE and .NET frameworks, be used within composite applications with other languages and work in harmony with contemporary user interface systems while continuing to process data in files and databases faster than any other language.
5. As your COBOL experts are nearing retirement you need a COBOL exit strategy
As many COBOL programmers are nearing retirement age it is getting more difficult to find COBOL programmers especially in non metropolitan areas. Combine this with the fact that most new graduates don’t know COBOL and another common myth arises - organizations using COBOL will have to implement a COBOL exit strategy or the business is doomed.
NOT TRUE:The basic facts are accurate but to jump to the conclusion that adopting a COBOL exit strategy is the only solution is not true.
With good application analysis and management tools coupled with modern COBOL development environments, new development staff can work as productively as they can in any other language and any recruit who can program in C, Java or any other language can easily pick up COBOL.
Micro Focus uses COBOL extensively ourselves and we regularly recruit new graduates and introduce them to COBOL in this way. This strategy is substantially more cost effective and lower risk than if we were to attempt to re-write our compiler and the other elements of our products that are currently written in COBOL.
An alternative approach employed by some financial and insurance organizations in both Austria and in the USA was to get together with other organizations in their area that depend heavily on COBOL and approach the local universities and colleagues. They basically complained that the computer science graduates had plenty of Java or C skills but no COBOL or PL/I which is what these groups of organizations required. In both situations the faculties obliged and added COBOL and PL/I back on to the curriculum.
6. Re-writing COBOL applications in a more modern language will solve all our issues
With the negative perceptions about COBOL discussed above combined with sheer amount of media coverage of more modern languages the most dangerous misconception of all has arisen i.e. if an organization simply re-writes its COBOL applications in a more modern language the key issues being encountered with these business systems will magically disappear:
NOT TRUE: As explained above, the only real issue with existing COBOL applications is that because of their very nature, they have grown to become some of the largest and most complex systems in the world. The fact that they are written in COBOL is a positive, if they were written in another language the issues would simply be magnified. There is no magic facility in any other language that would remove any of the issues that are being attributed to the fact that the application is written in COBOL.
In fact rather than solving all the current issues, a more realistic scenario is:
- A huge expenditure, estimate at around $25 per line of working COBOL code
- The project will unlikely ever be completed, the majority are not
- If a new system actually ever makes it to production, it will be years over schedule
- The new application will be at least the same size of the COBOL application
- It will be significantly more complex and even more difficult to maintain and enhance.
- The new system will provide the same business functions as before but with more problems
- It will take another 5 years for the system to mature to the stability of the existing system
- The new system will perform significantly slower than the original COBOL application
7. Replacing core COBOL applications with packages will make us more competitive
Package application implementations to replace internal systems that perform generic functions that are not part of an organizations core business usually makes complete business sense.
Over the last 10-15 years this has become very common, so the COBOL systems that remain are typically core business applications. Many Insurance organizations have, for exampled replaced in house applications performing Human Resource functions with an HR package but have retained COBOL systems which offer them some unique business advantage.
Unfortunately there is a misconception that also replacing these core business applications with packages makes sense because this will automatically make the business more competitive.
NOT TRUE: This will be very dependent on how much unique business process code is contained in the COBOL system.
The generic package will obviously not contain these unique business processes or business rules and so they must somehow be added to the package or you risk actually losing your competitive advantage.
Depending on how much effort this is, this can actually influence whether implementing the package makes business sense compared with adding new functionality to the original COBOL system or integrating aspects of the original COBOL system with the new package.
