Download COBOL Converter Free Trial

Testing the Translated Application

Testing a translated COBOL application should focus on proving behavioural equivalence between the original system and the generated Java or C# system. The objective is not to create new functional tests or reinterpret the business rules. The original COBOL application is treated as the reference implementation, and the translated application is expected to produce the same observable results when executed with the same inputs.

For batch programs, testing is normally performed end-to-end. The client provides representative test data, including sequential files, indexed files, database content, job parameters, control cards, and any required environmental settings. Where mainframe files are involved, SoftwareMining utilities can be used to convert EBCDIC data to the required ASCII or Unicode format. The translated job can then be executed using the generated Java or C# application, normally driven from the translated JCL or equivalent execution script.

The expected results are obtained by running the original COBOL program against the same test data. The actual results are obtained by running the translated application. Output files, reports, return codes, logs, and other generated artefacts can then be compared using standard file comparison tools or the SoftwareMining Java-based DIFF utility. Where the application updates database tables, the client database administrator may create the required test databases and use appropriate database comparison tools to verify the before-and-after state.

This approach allows the client to validate the translated application using real application data and real execution paths, without requiring SoftwareMining or the migration tool to infer business meaning from the code. The purpose of testing is therefore to confirm that the translated system preserves the behaviour of the original COBOL application, including file handling, numeric precision, report layout, database updates, control flow, and exception behaviour.

Typical Batch Testing Workflow

Step Activity Typical Responsibility SoftwareMining Support
1 Prepare representative input files, parameters, database content, and job settings. Client / SI Guidance on required inputs based on translated programs and JCL.
2 Convert mainframe data files from EBCDIC to ASCII or the required target encoding. Client / SI EBCDIC to ASCII conversion utilities.
3 Create or refresh test databases for the translated application. Client DBA Generated DDL and data-access structures where applicable.
4 Run the original COBOL batch job to produce the reference output. Client / SI Not applicable, as this is performed in the client mainframe environment.
5 Run the translated Java or C# batch program using the translated JCL or equivalent command. Client / SI Generated Java or C# application and runtime libraries.
6 Compare generated sequential files, reports, logs, and return codes. Client / SI Java-based DIFF utility suitable for use in automated test scripts.
7 Compare database updates where batch programs modify SQL tables. Client DBA / SI Database schema and generated persistence layer where applicable. Database comparison is normally performed using client-selected DB tools.
8 Investigate and resolve any differences. Client / SI / SoftwareMining as required Support for translation-related issues, runtime behaviour, data conversion, and generated code analysis.

Once the translated application has been accepted, future business changes are normally made directly to the Java or C# codebase. For this reason, the primary testing requirement during migration is equivalence testing between the original and translated systems, rather than ongoing regeneration-based testing.



Executive updates on COBOL modernization:
Comments and feedback (moderated):
* Name:
* Company email:
Comments:
We use your email only to respond and to send updates if selected. We do not sell your information.