Introduction

60 years of COBOL, and, most likely, it’s here for the future. In this article, we have the pleasure of interviewing Adrian Tot about the past, present, and future of this technology that still has a very significant impact on our day-to-day business operations.

As software developers, we dream of using the latest technologies to solve various business use cases. However, lots of software systems still run on COBOL, a 60-year-old English-like data processing language inspired by Grace Hopper’s idea of having a programming language that’s machine-independent.

Every now and then, I kept on stumbling on articles about COBOL that made me more curious about it. For instance, it was in 2014 that I read that there are 200 times more COBOL transactions executed on a per-daily basis than Google searches.

Or, I remember reading an article in 2017 about U.S. Digital Service attempts to modernize some legacy systems, which required interconnecting a Java-based application with a COBOL mainframe application. In the article, Marianne Bellotti explained that it was Java that was the bottleneck since the COBOL application response time was just 1 millisecond.

Or, recently, at the beginning of the COVID-19 epidemic, the U.S. Department of Labor was switching to the paper applications because the 40-year old COBOL system responsible for unemployment claims was overwhelmed with the afflux of requests.

This is a very interesting topic, and since I’ve never worked with COBOL, I decided to interview one of my friends, Adrian Tot, who has been using COBOL for over 15 years.

Hi, Adrian. Would you like to introduce yourself and tells us a little bit about yourself and ERP Contact?

Hi Vlad. I started my IT career back in 2005, working on a highly complex legacy ERP system running on the mainframe. In the same year, I obtained my bachelor’s degree in Automation and Computer Science from the Technical University of Cluj-Napoca. I knew very little about legacy systems before my first job, and it was very different from the things we learned in school, so the beginning was not easy. My investigative, “puzzle solver” nature helped a lot.

At the end of 2007, my partners, Alexandra Onetiu and Sorin Martinescu, and I, founded ERP Contact, offering legacy applications support and maintenance. For the past 5-6 years, we were also involved in migration projects from legacy to Oracle EBS, and we are performing support and development for the Oracle EBS applications.

Can you tell us why COBOL is still so dominant even if there are so many modern technologies competing in the enterprise software development industry?

First of all, let’s consider the lifespan. COBOL is the third oldest high-level programming language, preceded only by FORTRAN and LISP. The C programming language, for example, started to become popular about 20 years after COBOL was released. By that time, COBOL was a worldwide standard for enterprise application development.

And talking about C, there is another big difference that made businesses favor COBOL even as the popularity of C was growing. COBOL syntax was meant to be understood by any English speaker. So, business users could easily go through the code and understand the functionality. With the C syntax, this was obviously out of the question. So, as a first conclusion, COBOL had a huge head start, and modern technologies were simply not able to catch up as of yet.

Another reason is that many organizations that use COBOL are not very eager to migrate. COBOL is at the core of critical applications for both businesses and governments. It is a known fact that legacy systems migration is very challenging, with a high failure rate. And even if the migration is successful, it surely implies a huge investment of money and people over a sizeable period of time. There is no easy way to do it.

How come COBOL is so fast, as recalled by Marianne Bellotti‘s articles?

COBOL was developed at a time when hardware resources were very limited. The developers could not afford to waste these limited resources on fancy features. Therefore, the focus was on getting the job done.

COBOL is more of a domain-specific programming language in the sense that it is meant to be used for solving a rather narrow set of business requirements, mostly manipulating large sets of record structured data.

Also, fixed-point arithmetic is tremendously important for business applications where precision in handling money amounts is essential. It’s true that general-purpose programming languages would be able to offer solutions for these problems in one way or the other, but COBOL was built for this.

COBOL’s performance lies in the compiler, in how the translated to machine code is able to squeeze all the juice from the underlying hardware. IBM, in particular, has a really long COBOL history, and when it comes to performance, they were always focused on getting the most out of their compilers.

Related to the U.S. Department of Labor incident, do you think that it is worth it for a young developer to learn COBOL and try to address this COBOL skill demand crisis?

Yes, definitely. Billions of lines of COBOL code are currently in use. It is present in some of the most critical software systems around the globe. Many developers from the older generations who worked with COBOL are already retired, and the younger generations are more attracted to modern technologies, so it’s likely that this COBOL skill demand will continue for the foreseeable future. Even in our local market, it is much easier to find a COBOL developer job now than it was 15 years ago.

Why do you think it’s so complicated for an existing company to move from COBOL to Java or some other technology? Can you tell us what are the pain points and how long this kind of process could take?

From a risk perspective, a legacy migration project can be viewed as replacing the engine while the plane is flying. This is why many prefer the much safer “if it ain’t broke, don’t fix it” approach. The process is definitely complex. Some of the most common challenges include:

• Lack of support. The people who knew best the legacy systems are those who maintained them back in the day. Most of them are long gone now.
• Lack of documentation. Documentation is usually scarce and not up to date if any. In some cases, even finding the source code can be challenging.
• Lack of standardization. Many developers touched the code during its long life, each with his own coding style and preference. Many COBOL versions can coexist within the same application, each with its own flavor.
• Lack of time. This is a huge effort of the entire organization over an extended period of time (measured in years). Many organizations just cannot afford to spend that much time and effort on migration.

Another factor might be the lack of motivation. I mean, if you think about it, you have a strong and reliable system that successfully passed the test of time. Is it really worth it to decommission it completely just because it’s old-fashioned and start from scratch with a completely new system?

Maybe it would make more sense to let the legacy system do what it does best (and you know it can do it because it did it for the past 40-50 years) and use the modern programming languages to build a better UI, a mobile application, and other modern features on top of it.

For 30 years, we’ve been told that COBOL is dead. Yet, it looks like COBOL is not going anytime soon. What do you think is the future of COBOL?

I think it’s unlikely that organizations that don’t have COBOL in their IT footprint will choose it for future development projects. But most organizations that already have it will probably keep it and build functionality on top of it.

Also, let’s not forget that, like any other software language, COBOL is evolving. Most people think of COBOL as this archaic language, but the latest versions of COBOL are Object Oriented, include many features specific to modern software languages, which can run on Windows or Linux. Also, modern-looking IDEs like OpenCobolIDE offer a much-improved development experience compared to the 3270 terminal emulators.

Thank you very much, Adi, for taking the time for this interview and helping us get a better understanding of this topic.

Thank you, Vlad, always a pleasure talking to you.

I'm running an online workshop on the 20-21 and 23-24 of November about High-Performance Java Persistence.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

60 years later, COBOL has a future since there are around 250 billion lines of COBOL that handle various mission-critical applications, from finance to insurance or government operations.

If you are struggling with a COBOL system and you’re looking for someone to help you with the lack of COBOL experts, then you can contact Adrian’s company, ERP Contact, as not only do they know how to develop COBOL-based applications, but they also know what it takes to migrate a legacy COBOL application to a present-day Oracle EBS platform.

Insert details about how the information is going to be processed

DOWNLOAD NOW