Changing COBOL to Java line by line may look like a simple method to mainframe modernization, however enterprises that go that route will not have the ability to absolutely escape COBOL’s clutches, consultants say.
COBOL continues to be a mainframe staple greater than six many years after its inception, however COBOL programming abilities are briefly provide. Mainframe modernization and transferring apps to the cloud may give enterprises entry to a bigger pool of software program builders versed in newer languages. However earlier than cloud migration can occur, COBOL normally have to be rewritten in a contemporary language reminiscent of Java.
Such conversions are powerful due to the software developer shortage — and since the ensuing Java will retain some COBOL options, which implies enterprises won’t ever have the ability to absolutely sever their ties to COBOL, mentioned Jason Bloomberg, founder and president at analyst agency Intellyx.
COBOL-to-Java conversions end in JOBOL — a portmanteau that describes Java code with COBOL syntax. Whereas JOBOL is technically legitimate Java code, it leaves the unique software program structure in place and preserves COBOL semantics, requiring builders to deal with the Java as if it have been COBOL, Bloomberg mentioned.
“The issue, due to this fact, is partly because of the developer talent set, however even probably the most senior builders would have a tough time with line-by-line transformed COBOL,” he mentioned.
The JOBOL conversion downside
Even when an organization has skilled builders on board, COBOL and Java’s incompatible atmosphere and translation hurdles make for difficult translations, mentioned Nick Twyman, senior director of software engineering at Truss, a software program growth firm.
For instance, when builders do a like-for-like translation between COBOL knowledge varieties and kinds in Java, they run into semantic variations in how they behave in edge instances reminiscent of integer overflow, he mentioned. Overflow occurs when builders attempt to retailer values which can be outdoors the vary of the variable’s allowed worth.
Tom Taulli, software program developer and writer of Fashionable Mainframe Improvement: COBOL, Databases, and Subsequent-Era Approaches, agrees that the 2 languages are difficult to translate.
“It is not unusual for the legacy code to have unorthodox approaches, reminiscent of with GO TO statements,” he mentioned, referring to the COBOL assertion that’s an unused however reserved keyword in Java — which implies it could possibly’t be used as an identifier for any program components.
Earlier than these tasks even start, most of them are in bother since builders could also be engaged on code areas that will by no means be utilized by an finish person. David GarthePresident, Gravyware
In response to Twyman, COBOL-to-Java idiosyncrasies produce “stilted” Java code that does not convey its intent to fashionable programmers. The result’s opaque code that’s exhausting to take care of.
One other downside builders encounter is an absence of full documentation of an software’s performance, mentioned David Garthe, president of on-line advertising agency Gravyware. An software is perhaps previous and beforehand modified by many builders, with orphaned performance inflicting code bloat, he defined.
“I’ve discovered that the majority corporations will know which areas they use probably the most, however cannot say for sure all of the features and whether or not they’ll be wanted,” Garthe mentioned. “So earlier than these tasks even start, most of them are in bother since builders could also be engaged on code areas that will by no means be utilized by an finish person.”
Dearth of COBOL abilities worsens conversion woes
In a perfect world, corporations might rent builders who’re skilled in each COBOL and Java programming, however that’s tough, partially as a result of there are few such people available on the market, Bloomberg mentioned.
In response to Taulli, it is powerful to seek out COBOL programmers as a result of lots of them are retiring. “This has put enterprises in a troublesome bind — and that is spurring extra modernization efforts,” he mentioned.
Compounding the issue is that even among the many few builders who’ve COBOL abilities, the quantity keen to work in COBOL can also be restricted, so an enterprise would possible want a big finances to seek out high expertise keen to do the work, mentioned Tyler Martin, vice chairman of expertise provide at Toptal, a software program growth outsourcing agency.
Even when giant salaries are supplied, builders nonetheless won’t leap on the lure of upper pay.
“Many builders that know [COBOL] haven’t labored with it for years and like to not work with it sooner or later,” Martin mentioned. “What we continuously hear from builders is that rising their very own abilities and dealing on cutting-edge tasks are a stronger incentive than monetary compensation.”
COBOL has a protracted historical past as a mainframe staple.
Future for COBOL conversion seems to be bleak
Garthe, who has intensive expertise with on-premises to cloud migrations, has by no means been capable of convert a legacy app to a more moderen language line by line.
“Most languages do not actually work that method, however we have definitely tried nonetheless,” he mentioned.
Twyman has confronted related difficulties.
“We’ve not had a lot success with a naive line-for-line method to changing COBOL code, preferring a rewriting, which captures the unique intent and habits in additional idiomatic code,” he mentioned.
At finest, Twyman mentioned, builders might use line-by-line translations as a tough start line to select code from, however it’s no substitute for understanding and modeling the underlying enterprise processes and intent behind the unique code.
Intellyx’s Bloomberg cautions that even when an enterprise is successful at converting COBOL to Java, the ensuing JOBOL implies that enterprises should proceed to coach builders on COBOL.
“But when you are going to require ongoing COBOL abilities, why not simply keep on the mainframe?” he mentioned.
