Changing COBOL to Java line by line would possibly look like a simple method to mainframe modernization, however enterprises that go that route will not be capable to totally escape COBOL’s clutches, consultants say.
COBOL remains 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 shifting 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 should be rewritten in a contemporary language equivalent to Java.
Such conversions are robust due to the software program developer scarcity — and since the ensuing Java will retain some COBOL options, which implies enterprises won’t ever be capable to 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 have been COBOL, Bloomberg stated.
“The issue, due to this fact, is partly because of the developer ability set, however even probably the most senior builders would have a tough time with line-by-line transformed COBOL,” he stated.
The JOBOL conversion drawback
Even when an organization has skilled builders on board, COBOL and Java’s incompatible surroundings and translation hurdles make for difficult translations, stated Nick Twyman, senior director of utility engineering at Truss, a software program improvement 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 instances equivalent to integer overflow, he stated. 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 creator of Fashionable 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, equivalent to with GO TO statements,” he stated, referring to the COBOL assertion that’s an unused however reserved keyword in Java — which implies it will probably’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 consumer. David GarthePresident, Gravyware
In line with 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 laborious to keep up.
One other drawback builders encounter is an absence of full documentation of an utility’s performance, stated David Garthe, president of on-line advertising and marketing agency Gravyware. An utility may be 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 probably the most, however cannot say for sure all of the features 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 consumer.”
Dearth of COBOL abilities worsens conversion woes
In a perfect world, firms may rent builders who’re skilled in each COBOL and Java programming, however that’s tough, partly as a result of there are few such people in the marketplace, Bloomberg stated.
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 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 possible want a big finances to seek out prime expertise keen to do the work, stated Tyler Martin, vp of expertise provide at Toptal, a software program improvement 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 regularly 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 appears to be like 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 means, however we have actually tried nonetheless,” he stated.
Twyman has confronted related difficulties.
“Now we have 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 stated.
At finest, Twyman stated, builders may use line-by-line translations as a tough start line to choose 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 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.
