| COBOL To Java Explored |
| Written by Kay Ewbank |
| Tuesday, 21 August 2018 |
|
There's an interesting write-up of the experience of migrating a COBOL system running on an IBM mainframe to Java on Linux. The data was taken from VSAM KSDS files to Oracle. If you thought COBOL was something only ancient programmers reminisce about when they've had one cocoa too many, think again. There are still systems out there that are running on mainframes in COBOL because moving them is just too difficult, and when companies do eventually bite the bullet and move to more modern systems, it still isn't easy. This paper sets out the experience of migrating an American newspaper company's (The New York Times') application for managing daily home delivery of the newspaper. The IBM mainframe system had been in operation since 1979, but needed modernization to increase interoperability with other newer systems, as well as reducing operating costs. While a home delivery system sounds relatively straightforward, the application had grown to more than two million lines of COBOL code implementing billing, customer account maintenance, and delivery routing. An earlier attempt to redevelop the home delivery application between 2006 and 2009 had failed, so the new plan was to start again from scratch and deliver 'functional equivalence'. This was done by putting together sets of related components to perform some subset of the main application. The component group would be runnable and testable as a “black-box” through existing externally accessible interfaces, such as SOAP Web Services, User Interface screens, database tables, and files.
"Given the same inputs, the output of legacy component groups were compared to the output of their modernized counterparts. When they matched, the test was considered to have passed. When they did not, root-cause analysis was performed to find the source of the mismatch."
Though this sounded fine in theory, in practice things weren't quite so straightforward:
"The vast majority of legacy application components did not have a high enough level of test coverage to codify the required information for functional equivalence testing. As a consequence, much time was spent trying to analyze inputs, outputs, and sometimes even the internal behavior of components when tests failed and root-cause analysis had to be performed. This was especially time-consuming and difficult for the more complex batch jobs (i.e. many man-
months of work)."
The process of rewriting the code overran by a year but was judged 'a success', even though there are "a few production issues". The developers say:
"the modernized application has proven to be quite stable in production over the last eight months and newspapers still get delivered daily."
They also admit that new feature development remains "challenging". It requires knowledge of COBOL programming idioms and mainframe concepts that Java software engineers on the team do not possess. Mainframe COBOL developers on the team know the idioms and concepts, but are not yet proficient in Java. The team are cross-training developers and hope that this will help with knowledge transfer. They also note that it has been difficult to recruit new Java developers due to a lack of interest in working with the translated code.
More InformationCOBOL to Java and Newspapers Still Get Delivered Related ArticlesGnuCOBOL 2.0 Adds VS Build Support Free COBOL in Enterprise Developer Personal Edition To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin. 
Comments
or email your comment to: comments@i-programmer.info |
| Last Updated ( Tuesday, 21 August 2018 ) |
