Mainframe COBOL to Java, C# & Cloud

IAI uses SoftwareMining for COBOL-Java Translation



Government Application - COBOL with CICS to Java

Information Analytics Incorporated (IAI) is a systems integrator for a US state-level government organization and approached SoftwareMining to carry out an IBM COBOL CICS VSAM migration to Java Oracle. The project involved the translation of IBM CICS online and batch applications to Java, while the associated JCL was translated to PERL scripts by IAI. SoftwareMining also contributed to the testing and delivery phases of the wider project. As part of this delivery and testing team, it became clear that much of the project's success would depend on the legibility of the generated code. If the code is easy to understand by Java developers, and the developers do not require large amounts of training to understand legacy issues, then a project has a much better chance of succeeding. The first thing to emphasise, emphasise and emphasise again, is to use a COBOL to Java converter which can yield the best quality code, and which can remove as much dependency on legacy architecture as possible. It is not always possible to remove all legacy dependencies, and around 75% of GOTO statements can be removed by simply restructuring the code. However, removal of the remaining 25% may result in spaghetti code – it may be better leaving them alone. As a result, important lessons were learned from this project:

VSAM Data migration

Before VSAM structures could be migrated to SQL tables, a manual process was required to identify which structures are the same. Once they were identified, the information was fed to the conversion tool in order to generate code addressing the same tables in both cases. This type of analysis is best performed by COBOL developers who are familiar with the system. Do this before the last expert leaves the organization! Oracle was selected as the target database, and Oracle utilities were then used for the migration of VSAM data files to the database.

Data access performance – VSAM and SQL are different animals

The process of moving from VSAM to SQL was a lot simpler than in rehosting projects where VSAM APIs are manually replaced by custom-made SQL statements. This is because the new object-relational Java-classes generate the SQL at runtime automatically/dynamically. For example, to read the customer record, the system merely writes: customer.read() . In this case, all SQL statements are automatically generated by the Java framework - similar to Java HIBERNATE framework.
However, the big change in architecture (VSAM to SQL) caused a few performance issues which needed addressing. The issues were caused because, when COBOL reads a data-file using an index, the system merely places the file–pointer to the beginning of that index. To achieve the same thing in a database, an SQL statement has to be issued to read all records which match the index / selection-criteria. Potentially millions and millions of records could match, creating a huge load on the database. The solution was to provide sets of APIs to developers, allowing them to effectively reduce the number of records matching the search result. Four different solutions were evaluated and developed within the Java-framework layer. Two of them were used successfully to overcome the performance issues. The selected solutions did not require developers to rewrite SQL statements – but merely used new object-relational APIs to reduce the size of the search space.

From BMS to HTML

Managing the end user's expectations became very important when dealing with new screens. For example, the original application was designed to utilize F1 or F5 keys for a particular function. Unfortunately, Internet Explorer launches the help screens when the F1 key is pressed, and F5 always refreshes the page. The users have to click on F1 and F5 buttons rather than pressing the keyboard keys. Of course, there are ways of disabling the default functionality of the browsers, but this had other implications.

keeping original developers involved

Over the course of this project, the importance of the original COBOL developers became very clear. The testing phase (where most of the time/money was spent) went a lot more smoothly when one of the original developers was involved.

Knoweldge of how the application is supposed to behave, the intention of a particular piece of code, and whether it is still being utilised, turned out to be extremely helpful. Our experience showed it would be beneficial to retrain existing developers in Java, and to allow them to continue their involvement with the application. We learned that it's very helpful to conduct migrations before the original developers move on to new roles or jobs.


  © 2024 SoftwareMining is a trademark of Software Modernization Technologies Ltd (UK). Registered in England company no: 07300248. Reg Offices: 79 Stevens House, Jerome Place, Kingston Upon Thames, KT1 1HX, United Kingdom.