COBOL Is Not The Problem; The Data Is
June 1, 2020 Brad Thomas
The COVID-19 pandemic has put a spotlight on COBOL, with multiple news stories about COBOL systems struggling as unprecedented demands have been placed on them. And then there are the urgent requests for COBOL developers to help ensure these mission-critical systems do their jobs.
Eventually, the dust will settle, but some tough decisions will loom for organizations that rely on COBOL. The reality, though, is these decisions were already on the horizon because of the constant evolvement of other data management technologies, surging data production and the rapidly increasing average age of COBOL developers. When the dust does settle, it is important for decision makers in these organizations to understand their unique situations.
“Right now in the news media we are seeing all of these use cases being lumped together as ‘COBOL applications’ merely because of the use of the language,” explains Evaldo Oliveira, COBOL evangelist at FairCom Corporation, a maker of the C-Tree line of application modernization tools for mission critical systems. The C-TreeRTG file system is meant to replace the underlying legacy COBOL flatfile data storage and has SQL interfaces and APIs to allow for integration with other applications and modernization of the COBOL applications. “For the general public’s awareness that’s good enough. What is important for decision makers and anyone more seriously interested or affected by what is going on to understand is that there are two major implementation styles of COBOL: those based on the mainframe and those based on open COBOL. Depending on which is in use, greatly affects the options available and ease of moving forward.”
Oliveira says there are three common options for organizations that use non-mainframe COBOL: migrate, maintain the status quo or modernize. And of the three, COBOL modernization is the option that offers the lowest risk and the highest rewards, especially if the approach emphasis is put on the data.
“Modernization for non-mainframe systems is the most viable route from a total cost of ownership and from a risk standpoint. If done right, modernization will allow organizations to use analytics, stop the inherent data corruption problem, and use modern programming languages,” Oliveira says. “Migration requires building an entirely new system that could take years, likely will not utilize any existing resources and will be expensive. Of course, the option of not doing anything and hoping for the best with a COBOL system is doomed to fail at some point because of the decreasing number of developers and the strain of heavier data management demands, both of which, unfortunately, have been exemplified during the COVID-19 pandemic.”
Data-Centric Modernization Or Language-Focused Modernization
Currently, there are two main methods for modernizing non-mainframe COBOL systems. The most common approach is a migration with a language-focused approach. The less-taken modernization route focuses instead on the data. Of these two approaches, Oliveira believes the data-focused modernization approach is better overall because of decreased risks and lower costs during and after the process. With the data centric approach, the modernization efforts shift from rewriting the COBOL programs, which involves a lot of time and leaves room for errors from simple coding and translation mistakes, to providing better access to the original data files. This can be done by replacing the COBOL file system with newer technology and can occur without touching COBOL source code.
“The problem with COBOL is not the language. COBOL delivers just like any other language does: Processing large amounts of data fast and reliably. In great part, the reason why these systems were not migrated is exactly because of that: They work and work well,” Oliveira says. “However, the data it uses and produces is pretty much inaccessible outside of COBOL, and that makes it a data problem.”
The non-mainframe COBOL data is located mostly in proprietary file formats that other modern systems struggle to access, forcing developers to continue to actively maintain these systems. According to Oliveira the focus should be shifted from the language to the data because COBOL file systems are replaceable.
“Data-centric modernization is a viable route that organizations running non-mainframe COBOL should explore before heading down the costly, painful and potentially dangerous path of migration away from COBOL. You can preserve your investment in COBOL, and modernize it at the same time,” Oliveira contends. “Because the core data management engine stays in place, less work is required and the risks of failure are much lower. It must also be emphasized that once this new modernized system is in place, it is highly unlikely that the COBOL code will need to be touched since updates to the system can be done with other languages, which also provides a long-term path to slowly decrease your dependency on COBOL.”
According to Oliveira, until recently, the data-centric modernization approach has been less popular because most companies attempted to get access to the data via conversion to a relational, SQL-only database. While many of the projects that took this route succeeded, success came at high costs, proved painful and took many years to complete. The reason for the pain is because COBOL is more like NoSQL.
“Converting COBOL data to SQL is not an ideal approach because COBOL data is typically non-relational, and converting it to a relational database management system (RDBMS) created more complications than originally thought,” Oliveira says. “This, however, changed with NoSQL databases, especially those that can provide similar data structures as COBOL.”
With the language-focused method, non-mainframe modernization occurs by rewriting the source code in a different language, so that it no longer uses COBOL. According to Oliveira, the major benefit of this approach is the complete removal of COBOL from the system. He warns, though, that this route carries a high number of risks and costs. “Rewriting the application means going from a well-tested COBOL system to a version 1.0 of a new system,” says Oliveira. “It will most likely take years to get the system stable again. It is also likely it will take multiple attempts to get it to work, and it might never become as good as the original COBOL one was.”
Modernization Benefits
The most obvious benefit of modernization through data is that it prolongs the life of non-mainframe COBOL systems for a significant period of time, allowing an organization to preserve the years of time and money invested. It easily addresses the COBOL developer shortage problem because it allows system integration with PHP, Python, Java and other languages, which is also advantageous since a number of organizations have multiple systems running on different languages.
The data-centric approach enhances the value of the existing COBOL data. With newfound access to business intelligence and analytics capabilities, organizations can extract more insight from this data. It also opens the door to more-user friendly backup and disaster recovery options, as compared to the unreliable and tedious hot and cold backup and manual recovery methods. These enhanced data management capabilities reduce TCO due to less time spent creating reports and performing data protection tasks, for example.
Oliveira adds that regardless of which approach an organization takes, it is important to research the solution providers and consultants that provide these services.
“There are organizations in the market with a strong track record of non-mainframe COBOL modernization who will be able to provide a detailed plan that best suits the unique needs of the customer, while providing examples of their successes,” he says. “There is no such thing as a ‘one-size-fits-all’ modernization solution. But one thing is for sure, before embarking on a long, multi-year project to rewrite your non-mainframe COBOL systems, ask yourself the question, ‘Isn’t having access to COBOL data all I need?’ If the answer is yes, choose the less risky approach of modernizing through data. You will have a much higher chance of succeeding and spending much less money.”
Brad Thomas specializes in content development for the tech and health care industry. After starting out as an editor for Gannett, he spent 13 years in public affairs for NASA’s human spaceflight mission operations and biomedical research directorates. He has spent the past seven years in the software industry, including three at FairCom Corporation. Thomas is a graduate of Louisiana Tech University and spent six years in the U.S. Navy Reserves working in meteorology and oceanography.
RELATED STORIES
As I See It: COBOL In The Time Of COVID
IBM Bolsters RPG And COBOL Development
Profound Logic Taps Node.js and COBOL For New Directions
COBOL And RPG Take Similar Roads To Revival
Looksoftware Introduces Open Access to COBOL Development
If COBOL Is Too ‘Un-Cool’ For School, What’s That Make RPG?
They should have left COBOL and RPG in the classroom so there won’t be any problem finding people to replace the retirees! I myself am counting it down!
BS, working form home with cobol systems is not an issue. Use Citrix server or Remote Desktop Server works fine without re-writing in a WEB environment.
This vendor fluff is unacceptable on The Four Hundred. This guy repeatedly refers to non-mainframe COBOL while referring to older mainframe database technology when he says flatfile. DB2/400 is not a proprietary, flatfile database as an older mainframe database can be called. In addition, this is a lot of gobbledygook for just saying recreate all the DB2/400 files as DDL.
While every vendor loves to talk this stuff, to insinuate that DB2/400 files are not up to any level of transaction processing you care to throw at it is a flat out lie. And this is yet another flat out lie the The Four Hundred has published on IBM i COBOL, and I’m not even a COBOL programmer, although I got training on it and RPG equally in both school and my first consulting job.
I know you guys at The Four Hundred have no peers when it comes to news on hardware, but this really is unacceptable to let these vendors or even your own staff bad mouth COBOL on the IBM i. I of course would do it in RPG, but COBOL has the same underlyinig principles. You give me something, anything, that some marketing fluff says is too much for IBM i, DB2/400, and RPG or COBOL, and I’ll flat out prove they’re a clueless liar. I have an enterprise level 720 sitting here in my apartment with 2 TB I can work with, and a 28 TB network server I can pull from with business class internet to load it from. Bring it on, marketing fluffs. Give me a freaking state unemployment backlog, whatever, I’ve processed bigger 24/7 loads for the past 30 years than anything you fluffs deal with. I can do it in my apartment if it comes to that. I’m tired of the snarky bs about IBM i.
I disagree with Brad Thomas’ article on the issue of COBOL. I spent more than 25 years of my career working for numerous companies across several industries all with COBOL applications on Mainframe or Midrange hardware, and the problem I saw most frequently was outdated or poorly maintained equipment. Most of the organizations that still run COBOL based applications have long since shifted new development into newer platforms, but still run the old applications on the old hardware bought 10-20 years ago. The problem is neglect and not investing in the core business systems as these are simply seen as reliable; that is until such time where a heavy stress load is thrown at them and then we see that they haven’t been updated to keep up with such a demand.
I think you have a point, Ron. Many of these platforms could have used better investments throughout the years to keep up with the increasing demand, and in stressful situations like the pandemic, they were simply derailed. There is also another issue, especially in the COBOL world: runtime licenses. From our own experience, we have customers struggling with older platforms that cannot be updated or upgraded simply because of the prohibitive costs of re-purchasing all runtimes. The market consolidation on COBOL vendors left them exposed to this threat. A good example is SCO, or NCR Unix, both real cases of customers we helped. The article is trying to show that there are ways to help these customers.For example, they can port their data management systems to a different platform. We have customers that kept all their programs running on their original operating systems and hardware, but moved all their files to Linux or Windows, using our technology to manage that. This reduced the stress on the original hardware, which was on the verge of imploding due to the lack of available resources, and without forcing them to re-buy any COBOL runtime license. Either way, your point is well taken: Without proper investment, either by keeping up with the infrastructure, or by modernizing what can be modernized, any crisis becomes a big crisis. Thank you for you input!