Changing COBOL to Java line by line would possibly seem to be an easy strategy to mainframe modernization, however enterprises that go that route will not be capable of totally escape COBOL’s clutches, specialists say.
COBOL remains to be a mainframe staple greater than six many years after its inception, however COBOL programming abilities are in brief provide. Mainframe modernization and transferring apps to the cloud can provide 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 akin to 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 be capable of totally sever their ties to COBOL, stated Jason Bloomberg, founder and president at analyst agency Intellyx.
COBOL-to-Java conversions lead to 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 had been COBOL, Bloomberg stated.
“The issue, due to this fact, is partly as a result of developer ability set, however even essentially the most senior builders would have a tough time with line-by-line transformed COBOL,” he stated.
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, stated Nick Twyman, senior director of utility engineering at Truss, a software program growth firm.
For instance, when builders do a like-for-like translation between COBOL information sorts and kinds in Java, they run into semantic variations in how they behave in edge circumstances akin to integer overflow, he stated. Overflow occurs when builders attempt to retailer values which can be exterior the vary of the variable’s allowed worth.
Tom Taulli, software program developer and creator of Trendy Mainframe Improvement: COBOL, Databases, and Subsequent-Technology Approaches, agrees that the 2 languages are difficult to translate.
“It is not unusual for the legacy code to have unorthodox approaches, akin to with GO TO statements,” he stated, referring to the COBOL assertion that’s an unused however reserved keyword in Java — which implies it may possibly’t be used as an identifier for any program components.
Earlier than these initiatives 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
Based on 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 onerous to take care of.
One other downside builders encounter is an absence of full documentation of an utility’s performance, stated David Garthe, president of on-line advertising agency Gravyware. An utility is likely to be previous and beforehand modified by many builders, with orphaned performance inflicting code bloat, he defined.
“I’ve discovered that the majority firms will know which areas they use essentially the most, however cannot say for sure all of the capabilities and whether or not they’ll be wanted,” Garthe stated. “So earlier than these initiatives 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 an excellent world, firms might rent builders who’re skilled in each COBOL and Java programming, however that’s troublesome, partially as a result of there are few such people in the marketplace, Bloomberg stated.
Based on Taulli, it is powerful to search out COBOL programmers as a result of lots of them are retiring. “This has put enterprises in a tricky bind — and that is spurring extra modernization efforts,” he stated.
Compounding the issue is that even among the many few builders who’ve COBOL abilities, the quantity keen to work in COBOL can be restricted, so an enterprise would probably want a big funds to search out high expertise keen to do the work, stated Tyler Martin, vp of expertise provide at Toptal, a software program growth outsourcing agency.
Even when massive salaries are provided, builders nonetheless won’t soar 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 stated. “What we continuously hear from builders is that rising their very own abilities and dealing on cutting-edge initiatives are a stronger incentive than monetary compensation.”
COBOL has an extended historical past as a mainframe staple.
Future for COBOL conversion seems to be bleak
Garthe, who has in depth 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 stated.
Twyman has confronted comparable difficulties.
“We’ve not had a lot success with a naive line-for-line strategy to changing COBOL code, preferring a rewriting, which captures the unique intent and habits in additional idiomatic code,” he stated.
At finest, Twyman stated, 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 stated.
