COBOL programming skills gap thwarts modernization to Java
The challenge of migrating COBOL applications to run in the cloud is made nearly impossible with tricky line-to-line conversions and a lack of developers with the right skills.
Converting COBOL to Java line by line might seem like a straightforward approach to mainframe modernization, but enterprises that go that route won't be able to fully escape COBOL's clutches, experts say.
COBOL is still a mainframe staple more than six decades after its inception, but COBOL programming skills are in short supply. Mainframe modernization and moving apps to the cloud can give enterprises access to a larger pool of software developers versed in newer languages. But before cloud migration can happen, COBOL usually must be rewritten in a modern language such as Java.
Such conversions are tough because of the software developer shortage -- and because the resulting Java will retain some COBOL features, which means enterprises will never be able to fully sever their ties to COBOL, said Jason Bloomberg, founder and president at analyst firm Intellyx.
COBOL-to-Java conversions result in JOBOL -- a portmanteau that describes Java code with COBOL syntax. While JOBOL is technically valid Java code, it leaves the original software architecture in place and preserves COBOL semantics, requiring developers to treat the Java as though it were COBOL, Bloomberg said.
"The problem, therefore, is partly due to the developer skill set, but even the most senior developers would have a hard time with line-by-line converted COBOL," he said.
The JOBOL conversion problem
Even if a company has experienced developers on board, COBOL and Java's incompatible environment and translation hurdles make for challenging translations, said Nick Twyman, senior director of application engineering at Truss, a software development company.
For example, when developers do a like-for-like translation between COBOL data types and types in Java, they run into semantic differences in how they behave in edge cases such as integer overflow, he said. Overflow happens when developers try to store values that are outside the range of the variable's allowed value.
Tom Taulli, software developer and author of Modern Mainframe Development: COBOL, Databases, and Next-Generation Approaches, agrees that the two languages are challenging to translate.
"It's not uncommon for the legacy code to have unorthodox approaches, such as with GO TO statements," he said, referring to the COBOL statement that is an unused but reserved keyword in Java -- which means it can't be used as an identifier for any program elements.
Before these projects even begin, most of them are in trouble since developers may be working on code areas that may never be used by an end user.
David GarthePresident, Gravyware
According to Twyman, COBOL-to-Java idiosyncrasies produce "stilted" Java code that doesn't convey its intent to modern programmers. The result is opaque code that is hard to maintain.
Another problem developers encounter is a lack of full documentation of an application's functionality, said David Garthe, president of online marketing firm Gravyware. An application might be old and previously modified by many developers, with orphaned functionality causing code bloat, he explained.
"I've found that most companies will know which areas they use the most, but can't say for certain all the functions and whether they'll be needed," Garthe said. "So before these projects even begin, most of them are in trouble since developers may be working on code areas that may never be used by an end user."
Dearth of COBOL skills worsens conversion woes
In an ideal world, companies could hire developers who are experienced in both COBOL and Java programming, but that is difficult, in part because there are few such individuals on the market, Bloomberg said.
According to Taulli, it's tough to find COBOL programmers because many of them are retiring. "This has put enterprises in a tough bind -- and this is spurring more modernization efforts," he said.
Compounding the problem is that even among the few developers who have COBOL skills, the number willing to work in COBOL is also limited, so an enterprise would likely need a large budget to find top talent willing to do the work, said Tyler Martin, vice president of talent supply at Toptal, a software development outsourcing firm.
Even when large salaries are offered, developers still might not jump at the lure of higher pay.
"Many developers that know [COBOL] have not worked with it for years and prefer to not work with it in the future," Martin said. "What we frequently hear from developers is that growing their own skills and working on cutting-edge projects are a stronger incentive than financial compensation."
COBOL has a long history as a mainframe staple.
Future for COBOL conversion looks bleak
Garthe, who has extensive experience with on-premises to cloud migrations, has never been able to convert a legacy app to a newer language line by line.
"Most languages don't really work that way, but we've certainly tried nonetheless," he said.
Twyman has faced similar difficulties.
"We have not had much success with a naive line-for-line approach to converting COBOL code, preferring a rewriting, which captures the original intent and behavior in more idiomatic code," he said.
At best, Twyman said, developers could use line-by-line translations as a rough starting point to pick code from, but it is no substitute for understanding and modeling the underlying business processes and intent behind the original code.
Intellyx's Bloomberg cautions that even if an enterprise is successful at converting COBOL to Java, the resulting JOBOL means that enterprises must continue to train developers on COBOL.
"But if you're going to require ongoing COBOL skills, why not just stay on the mainframe?" he said.
