COBOL to Maintainable Java & C#


COBOL to Java / C#, Performance comparison of converted code

COBOL is a compiled language and tends to have slightly better performance than interpreted languages such Java and C#.
But then Java / C# languages were designed with multi-threading and distributed processing in mind - making it easier to benefit from low cost multi-processor & multi-core system, or Cloud deployment.

This paper looks at the performance considerations of Java and C# applications generated from translation of COBOL code.

Performance Consideration

How performance issues are addressed

MIPS : Mainframe or Cloud Scalability remains a very powerful benefit of Cloud deployment. For applications deployed on Cloud, the processor availability/power can be scaled up/down according to high/low demand times. I.e. whether an application is deployed on Microsoft Azure, Amazon AWS or private Cloud, the MIPS can be adjusted to requirements of the hour, day or month.
The scalability effectively removes many of the performance questions for applications deployed on cloud.

For more information see: Mainframe COBOL to Cloud Roadmap & Checklist
Batch Applications Batch applications sometimes require to run within a set time-frame. Performance sensitive batch applications can benefit from following approaches:
  • Cloud: reduce processor load by running different batch jobs on different processors
  • Parallelization. This involves a breaking up of a process going from A to Z into two processes to run in parallel. In this example, first thread will process records from A to M, and the second process processes records N to Z.

    The important aspect is the translated code & framework-libraries should have built in support for parallelization
Online Applications The Java or C# translation of Online Cobol code utilizes Application Severs such as Apache-Tomcat, WebSphere, Weblogic or Microsoft IIS. The performance of online applications are generally related to number of concurrent users: the higher number concurrent users the more load on processor and the larger the memory requirement.
However, this is not a new problem. There are many load-balancing strategies for running Application-Servers to cater for huge number of concurrent users. Think of the many concurrent users on Google, Amazon or Facebook.

VSAM / KSDS vs SQL Making SQL request involves a lot more work than reading a VSAM file. It requires instantiating and loading drivers, establishing (TCP) connections, sending/receiving data via TCP to the database server, ...

SQL Databases have much better integration and maintainability prospect. Even in COBOL world many applications have already migrated from using VSAM/KSDS to databases.

To reduce the performance impact, the translated Java/C# system should provide mechanisms to reduce the database activity. For example, when retrieving information from database table containing millions of record, does an online program need to retrieve all the millions of record? would a data-entry personnel be scrolling all of them? Can such request be limited to several hundred records?
For more information see Moving VSAM / KSDS files to SQL Database
Limiting COBOL Emulation It is important to remember the original application was designed to use certain COBOL features. For example, the use of Packed-Decimals, moving a value to groups of variables, REDEFINE statements, GO TO statements and etc.

Such features have to be either removed during the translation to Java/C#, or catered for in the target deployed application.

We have found the best approach is to have a case-by-case evaluation. For example, a detailed usage analysis of each variable during the conversion provides sufficient information to:
  • Convert only applicable variables from Packed-Decimal to better performance Java/C# data-types
  • Use caching strategies for applicable variables to reduce conversion between COBOL data-type format and Java/C#
  • Remove / Restructure GOTO statements
  • ...

For more information see 16 Features Essential for Successful COBOL to Java Conversion Projects

JCL SORT SoftwareMining's pure java implementation of SORT utility covers 95% of SORT/DFSort functionality, and can be deployed on any platform supporting Java. However, from performance point of view, it cannot compete with the very efficient system designed to operate on mainframes.
Applications requiring higher performance levels can use one of the many other high performance SORT utilities available on market such as Syncsort or AHLSort .

For more information see SoftwareMining's JCL to Unix / Windows Shell Scripts





Share this page







  © 2019, 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.