EBCDIC-to-ASCII and UTF-8 Conversion Tools for COBOL-to-Java Modernization

Converting mainframe EBCDIC data is more complex than translating one character set into another. A single COBOL record can contain both character and non-character data, so converting the complete record as text can corrupt values and damage its fixed-length structure.

As part of SoftwareMining's COBOL application modernization process, the toolkit uses COBOL record definitions to interpret each record layout. It converts character fields to ASCII or UTF-8 while handling non-character data according to its COBOL definition.

Case Study: ING Bank COBOL-to-Java Modernization, Including EBCDIC Data Migration

Complications Introduced by Packed Decimal Fields

Packed Decimal (PD) fields use the same binary representation in both ASCII and EBCDIC. During conversion, these fields must be excluded to avoid corrupting data. The conversion process must therefore know the exact position and length of each PD field.

Standard file transfer tools, such as FTP with automatic character conversion, do not account for these fields and may produce incorrect results.

SoftwareMining's EbcdicConvertor solves this problem by using the COBOL record structure to identify character and binary fields. Character fields are converted while Packed Decimal fields are preserved unchanged. The tool supports two modes of operation:

Mode 1: Using Generated Data Access Objects (DAOs)
SoftwareMining's COBOL translator generates Java or C# data structures for COBOL 01-level records. These retain information about field types, positions, and lengths, allowing EbcdicConvertor to convert character fields while preserving Packed Decimal fields. Structures containing REDEFINES and OCCURS DEPENDING are also supported.

Example:
```
> java com.softwaremining.jcl.EbcdicConvertor e2a com.poc.CustomerRecord infile.txt outfile.txt
```
Mode 2: Using Record Definitions at Runtime
When a generated structure is unavailable, the record layout can be supplied as a runtime argument. This identifies the position, length, and type of each field, allowing precise control over which data is converted and which is preserved.

Example:
```
> java com.softwaremining.jcl.EbcdicConvertor e2a (1,20,CH,21,4,PD,24,60,CH) infile.txt outfile.txt
```

Evaluate COBOL Converter Free Trial

By default, translated Java or C# applications use Unicode-based character handling for reading, writing, displaying, and processing data. The SoftwareMining runtime can also be configured to work with EBCDIC files when required during migration and testing.

This is particularly useful when translated applications need to process existing mainframe files, for example when validating translated SORT operations against the original COBOL environment. It allows testing to proceed before permanent data conversion has been completed.

Continued use of EBCDIC is not recommended for the final production environment. Character data would need to be converted from EBCDIC when read and converted back when written, adding unnecessary processing overhead. For production deployment, converting application data to the target environment's character encoding avoids this repeated conversion and provides better performance.

Reliable EBCDIC Handling During COBOL Modernization

EBCDIC data conversion requires an understanding of COBOL record structures and binary formats, not simply character-set conversion. SoftwareMining supports safe conversion of structured EBCDIC data while preserving Packed Decimal and other binary fields. Existing EBCDIC files can also be used during migration and testing, while conversion to the target environment's character encoding provides the preferred approach for production deployment.

Run the Translated Java CardDemo

Continue Exploring

If you're evaluating approaches to COBOL modernization, the following resources may also be useful: