Changing COBOL to Java line by line may appear to be a simple strategy to mainframe modernization, however enterprises that go that route will not be capable of absolutely escape COBOL’s clutches, consultants say.
COBOL continues to be a mainframe staple greater than six a long time 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 often should be rewritten in a contemporary language corresponding to Java.
Such conversions are robust due to the software developer shortage — and since the ensuing Java will retain some COBOL options, which suggests enterprises won’t ever be capable of absolutely sever their ties to COBOL, mentioned 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 mentioned.
“The issue, subsequently, is partly as a result of developer talent set, however even essentially the most senior builders would have a tough time with line-by-line transformed COBOL,” he mentioned.
The JOBOL conversion drawback
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 improvement firm.
For instance, when builders do a like-for-like translation between COBOL knowledge sorts and kinds in Java, they run into semantic variations in how they behave in edge circumstances corresponding to integer overflow, he mentioned. Overflow occurs when builders attempt to retailer values which might be exterior the vary of the variable’s allowed worth.
Tom Taulli, software program developer and writer of Trendy Mainframe Growth: 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, corresponding to with GO TO statements,” he mentioned, referring to the COBOL assertion that’s an unused however reserved keyword in Java — which suggests it might probably’t be used as an identifier for any program parts.
Earlier than these tasks even start, most of them are in hassle since builders could also be engaged on code areas which will by no means be utilized by an finish person. David GarthePresident, Gravyware
In line with Twyman, COBOL-to-Java idiosyncrasies produce “stilted” Java code that does not convey its intent to trendy programmers. The result’s opaque code that’s laborious to take care of.
One other drawback builders encounter is a scarcity of full documentation of an software’s performance, mentioned David Garthe, president of on-line advertising and marketing agency Gravyware. An software is perhaps outdated 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 mentioned. “So earlier than these tasks even start, most of them are in hassle since builders could also be engaged on code areas which will by no means be utilized by an finish person.”
Dearth of COBOL abilities worsens conversion woes
In a really perfect world, firms may rent builders who’re skilled in each COBOL and Java programming, however that’s troublesome, partly as a result of there are few such people in the marketplace, Bloomberg mentioned.
In line with Taulli, it is robust 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 prepared to work in COBOL can be restricted, so an enterprise would seemingly want a big price range to seek out prime expertise prepared to do the work, mentioned Tyler Martin, vp of expertise provide at Toptal, a software program improvement outsourcing agency.
Even when giant salaries are supplied, builders nonetheless may not bounce 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 in a position to convert a legacy app to a more recent language line by line.
“Most languages do not actually work that manner, however we have actually tried nonetheless,” he mentioned.
Twyman has confronted related difficulties.
“We’ve got 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 mentioned.
At finest, Twyman mentioned, builders may use line-by-line translations as a tough place to begin 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 profitable at changing COBOL to Java, the ensuing JOBOL signifies 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.