Migrating EBCDIC data-files when moving from COBOL to Java and C#
Mainframes use EBCDIC character sets to maintain data files.
During the migration of a COBOL application to Java or C#, it is sometimes necessary to convert SEQUENTIAL files from EBCDIC to ASCII or vice-versa.
Additionally, it may also be desirable for translated Java / C# applications to continue working with EBCDIC data files for a limited period.
This paper provides an overview of the issues associated, and the solution to working with EBCDIC data.
Complications introduced by Packed-Decimal (PD) fields
Packed-Decimal (PD) fields are represented by the same binary values (and therefore the same characters) as in ASCII and EBCDIC.
Therefore, the character set conversion process should be aware of their position and length, and exclude them from the conversion process.
This means the standard FTP utilities with character set conversion facilities will generate incorrect results.
Solution-1: Using SoftwareMining's EbcdicConvertor
SoftwareMining's EbcdicConvertor addresses the problem by taking note of the position of PACKED-DECIMAL fields.
The utility can use two separate modes of operation:
Using the Data-Access-Objects generated during the translation SoftwareMining's COBOL to Java/C# translator generates Object-Relational Data-Access-Object (DAO) for every 01 level declaration in COBOL's DATA-DEFINITION.
These DAO classes will contain the size and position information on every field.
SoftwareMining's EbcdicConvertor uses this information to perform EBCDIC <-> ASCII conversion on all fields except PACKED-DECIMAL fields.
The system also caters for structures containing REDEFINITIONS and OCCURS-DEPENDING.
In the following example, the Java class "CustomerRecord" is a basic DAO which contains all the necessary information for a successful character-set conversion:
Structure definitions as runtime parameter
Alternatively, when an application has not been translated or it is unclear as to which structure is responsible for the generation of the data-file,
the record definitions can be defined as the runtime arguments to EbcdicConvertor utility. For example:
By default, the translated applications uses the same character set (UTF) for everything
from reading/writing (sequential) data files to displaying data on screen, database access and writing to Log-Files.
However, the runtime system can be configured to use different character-sets for each of the above operations.
This would allow the system to continue updating the database and screens in UTF, but still use EBCDIC for accessing sequential data files.
