Lessons Learned from an Enterprise IBM CICS Modernization Project
Project Background
This page summarizes practical lessons learned during an enterprise government modernization project involving IBM COBOL, CICS, VSAM and batch applications. Many of these findings subsequently influenced enhancements to SoftwareMining's COBOL-to-Java translation technology and runtime libraries.
Information Analytics Incorporated (IAI), a systems integrator working for a US state government organization, engaged SoftwareMining to assist with the modernization of IBM COBOL CICS and VSAM applications to Java and Oracle. The project included online and batch applications, while the associated JCL was translated separately by IAI. SoftwareMining also contributed to testing and technical support during the delivery phase.
One of the most important observations from the project was that the long-term success of an enterprise modernization depends not only on functional correctness, but also on the readability and maintainability of the generated Java application. Java developers should be able to understand, modify and test the translated code without requiring extensive COBOL expertise.
The project also reinforced the importance of minimizing unnecessary dependencies on legacy architectures. Wherever practical, SoftwareMining restructures COBOL control flow into standard Java constructs while preserving application behaviour. Simple control-flow patterns can often be converted automatically, whereas more complex structures may be retained where this results in clearer and more maintainable generated code.
The following sections summarize the principal technical lessons learned from the 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.
