SoftwareMining
Simple, Safe & Effective COBOL to Java / C#


Managing COBOL to Java / C# Projects by an Incremental Approach

Overview

A big-bang approach to modernization is not too suitable for large applications running on Mainframe computers. In this paper we are using our experiences to provide overview an approach which allows translation of part of application to Java, and allow the new Java parts to co-operate and co-exist with the yet un-translated COBOL code.

This approach allows the migration of larger applications to be broken down into manageable pieces, which are completed over a number of years. In this page we are endorsing an iterative approach where a small part of the codebase is translated, testd, moved to production (to co-operate with the existing COBOL application), and then the next iteration started for next set.

The immediate benefits would be to gradually provide access a larger pool of Java developers for maintenance (and enhancement) of the application, as well as integration of new technologies (HTML and Web-Services and SOA).
The next benefit materializes after Java code has been tested and moved into production. At that stage the data-files can be gradually migrated from VSAM /CICS/Mainframe-DB to an SQL.
The final benefit is on hardware: Once codebase is in Java and database is in SQL format, the application can be deployed on many different platforms such as a private cloud.


COBOL and Java co-operation: Its a Data problem

Many platforms such as IBM machines already support Java and provide means of accessing the data through either a Java layer (e.g. JCICS) or SQL (e.g. on DB400). Hence accessing the data from Java applications is not actually a problem provided the following issues are considered and addressed:

View/leave comments on the information provided on this page


Data and Java Data-Access-Objects

For every COBOL data-structure, SoftwareMining's translator will generate a java Data-Access-Objects (DAOs) who will contain same fields as the original COBOL structure. During the translation the system will monitor how each fields are used by each program. The allows the translator determines what level of formatting information is required by every (java) fields. It can then generate a DAO suitable to the needs of the programs: COBOL binary compatible versions which can be used in communication with other programs, or pure java (POJO) with significantly better performance.

The following are examples of types of operations where binary compatible formatting information will be required: In the above cases, the data representation of the DAO will be binary compatible with the COBOL's representation.
For all other cases, the translator will use native Java data-types. E.g. a numeric field originally represented COMPUTATIONAL will be represented as a java "double" or "BigDecimal".
The use of Java native data-types has a huge difference on the application's runtime performance.

Reading and writing data to VSAM, CICS and Sequential files

As data in generated Java Data-Access-Objects (DAOs) are compatible with COBOL versions, the only outstanding issue would passing the data from File-System to the said DAO objects.

For this the DAO's can use IBM Native support libraries: IBM JCICS or other Java libraries provided by the suppliers.
This will allow the Java version of application to work on same data-files as COBOL application.

Reading and writing data from ESQL (DB2) or DB400

ESQL/DB2: The translator will convert Embedded SQL statements from COBOL to Java (or C#) dialect. The new Java application will hence have no problem in communicating with DB2 and can co-exist with the other COBOL modules.

The Data-Access-Objects (DAOs) generated for DB400 by default use SQL to read and write their data. As DB400 provides SQL communication layer - there will be no issues in Java and COBOL versions of application co-existing. The only outstanding issue would passing the data from File-System to the said DAO objects.

Sequential Files

The Data-Access-Objects (DAOs) generated for Sequential files are also binary compatible with the COBOL ones.
All that is need is to define the underlying character-set used: ASCII or EBCDIC. These files will be interchangeable between the Java and COBOL part of application.

Communication between COBOL and Java

In a carefully planned migration, no cross-language communication should be required!
This can be achieved using call-Chain analysis tools to identify the "sets" of programs which can be translated.

When translation of entire sets is not possible, then cross language communications mechanisms can be considered. At the most basic level data can be interchanged through reading/writing to file-system. At most complex would be to use web-services. But usually each platform will provide mechanisms with significantly better performance.

Long term objectives: Roadmap for moving from VSAM to SQL

The generated Java programs access the data through the Data-Layer described above Data-Access-Objects (DAOs). This data-layer by default uses SQL to communicate with a database. Changing the underlying access mechanism from JCICS/VSAM to the default SQL is as simple as changing configuration.
I.e. data-migration will not involve any changes to business-logic layer and hence no functional testing. (This is unlike previous moves from COBOL/VSAM to COBOL/ESQL where all programs had to be changed).

The big task will be the data-migration activity itself. But overall the migration should be a very manageable project.



If you have found the information on this page useful and have Facebook account - then please click on the "Like" buttons below.


                       



  © 2017, SoftwareMining Technologies. All Rights Reserved. "SoftwareMining Technologies" is a trademark of Software Modernization Technologies Ltd (UK). Software Modernization Technologies Ltd. Registered in England company no: 7300248. Reg Offices: 8b Accommodation Road, London NW11 8ED, United Kingdom.