COBOL vs. Translated Java and C# Application Performance

Drawing on its experience developing automated COBOL-to-Java and COBOL-to-C# translation tools, SoftwareMining examines the performance considerations that apply to generated Java and C# applications. This article compares their performance characteristics with traditional mainframe COBOL across cloud, distributed and on-premises infrastructure.

COBOL applications are compiled and have traditionally delivered reliable performance on mainframe infrastructure. Java and C# applications also use optimized runtime compilation and can take advantage of multithreading, distributed processing, horizontal scaling and modern multicore systems. Performance therefore depends on both the generated code and the architecture on which the modernized application is deployed.

COBOL applications are compiled and have traditionally delivered reliable performance on mainframe infrastructure. Java and C# applications use optimized runtime compilation and can take advantage of multithreading, distributed processing, horizontal scaling and modern multicore systems.

Performance Depends on the Entire Application Architecture

The performance of a modernized application depends on considerably more than the programming language. Overall response time may be influenced by database access, disk I/O, network latency, transaction management, runtime configuration and the underlying infrastructure. Execution of the translated business logic may represent only a small proportion of the total processing time.

Comparisons should therefore evaluate complete business transactions and representative production workloads. Changes to database access, application architecture and infrastructure may have a greater effect than the choice between COBOL, Java and C#.

The following table compares traditional mainframe COBOL with Java and C# applications generated by SoftwareMining's COBOL translation tools, including the supporting runtime and architectural considerations.

Area	Traditional Mainframe COBOL	Translated Java / C#	Comments
Business Logic Execution	Optimized for the mainframe COBOL runtime.	Generally efficient, with some operations handled through SoftwareMining runtime libraries.	Preserving COBOL behaviour requires support for packed decimal fields, numeric conversions, REDEFINES, OCCURS DEPENDING ON and other COBOL semantics. The performance impact depends on how frequently these operations are used within the application.
Database Processing	Depends on DB2 performance, indexes and SQL access paths. The application and database commonly operate within closely connected mainframe infrastructure.	Existing DB2 tables, indexes and SQL can usually be retained. Performance may also depend on connection pooling and the network distance between the application and database.	Where DB2 is retained, database performance should generally remain comparable, subject to the deployment architecture. If the database is migrated to Oracle, PostgreSQL or another platform, the existing table and index design can be preserved, but SQL behaviour, access paths and database configuration must be tested on the target system.
Batch Processing	JCL coordinates COBOL programs, sort utilities and other processing steps, which normally execute sequentially within each job.	SoftwareMining translates JCL into Unix shell or Windows batch scripts that coordinate the corresponding translated programs and utilities.	Processing time depends on the performance of each step, particularly large programs, sort operations and file I/O. Although dependent steps remain sequential, independent jobs can run in parallel and benefit from additional processors, memory, fast storage and sufficient I/O bandwidth.
Online Transactions	CICS provides transaction management, workload control and scaling within the mainframe environment.	Translated transactions operate through Java or .NET application services and SoftwareMining libraries that provide the required CICS and BMS behaviour.	Larger transaction workloads can be distributed across multiple application servers using load balancing.
Sorting	Mainframe SORT utilities invoked through JCL and optimized for large sequential datasets.	JCL sort steps are translated to use target-platform sorting utilities or Java/.NET processing where appropriate.	Large sort operations can require substantial processing time, memory, temporary storage and I/O bandwidth. Performance must be tested using representative file sizes and configured to meet the required batch window. In the ING COBOL-to-Java modernization , translated batch processing included sort files of approximately 10 GB and completed within the required processing window.

No single performance result applies to every translated application. Performance depends on the original workload, the COBOL features being emulated, database and network placement, target infrastructure and runtime configuration. Representative batch jobs and online transactions should therefore be tested during the proof of concept and again before production deployment.

Mainframe MIPS and Cloud Capacity

Mainframe MIPS and cloud processor capacity are not directly comparable. Performance depends on the workload, processor architecture, storage, database access and application configuration.

AWS, Microsoft Azure and private-cloud platforms allow processor, memory and application capacity to be increased when required. This flexibility can help address capacity constraints, but inefficient processing, excessive database access and network latency must still be identified and tested.

Learn more: Mainframe Modernization Strategy .

VSAM and KSDS Compared with SQL

Migrating VSAM or KSDS files to SQL changes the data-access architecture. A direct comparison of individual operations can be misleading because performance depends on indexes, query design, transaction boundaries, connection pooling, network placement and workload patterns.

SoftwareMining generates SQL structures and data-access classes based on the COBOL record layout and indexed-file definitions. Performance should be protected by preserving appropriate indexes, minimizing network round trips and using efficient batch operations where applicable.

Although SQL access may introduce some overhead compared with direct file-system access, relational databases are the standard design choice for most new enterprise applications. Replacing VSAM or KSDS access with SQL is therefore an important part of modernization, providing broader integration, established transaction management, query capabilities and access to modern database administration and development tools.

Learn more: Migrating VSAM and KSDS Files to SQL Databases .

Support for COBOL Semantics

COBOL features such as packed-decimal fields, REDEFINES, variable-length structures and group assignments require equivalent behaviour in the generated Java or C# application. SoftwareMining uses generated target code and supporting runtime libraries to provide these semantics consistently.

Performance testing should include applications that make substantial use of these features. This allows any processing overhead to be measured as part of the complete business workload rather than assessed in isolation.

Get more details: COBOL-to-Java and COBOL-to-C# Translation Features .