Problem:
Converting a data file from EBCDIC to ASCII that contains packed numeric fields (usage COMP-3) using DFCONV from the command line, or alternatively the File Convert data tool from the Net Express IDE, results on corrupted data in the numeric fields.
Resolution:
The problem may be that the packet fields are not EBCDIC character data, they are just numeric data that follows a particular format (packet decimal) but it always follows the same format whatever the OS. I will give you an example.
If you have the following hexadecimal data from the mainframe:
94
2C
What would you say it is?
It could be the value 924 in packet decimal format, but it could also be the EBCDIC string "k<".
If you tell the File Convert tool that your file is all in EBCDIC, it will take it as the string "k<" and generate its ASCII equivalent, in hexadecimal:
63
BC
This is perfectly valid if it really was the string "k<", but if that was a packet decimal field, it would have corrupted it as the resulting is not a valid packet decimal number. And even if it was, the numeric value would be a completely different one, which would be even worse because it would go undetected.
Not all numeric data is like this, if you have numeric data in DISPLAY format, which means that it uses numeric characters to represent it, you do need to translate them because characters need translation.
How does File Converter know that it doesn't have to convert a particular field? The answer is using a mask.
To define a mask you need to use a record structure that fully defines the contents of your records. The .str file needs to have at least a different field defined for each packet decimal field in the file. You may have to define a conditional structure if your data file has different types of records.
It is not difficult to define a conditional structure, basically you define different records depending on the value of a field. Once you have this conditional structure, you can define a mask for File Convert by selecting the fields that are not character and shouldn't be converted from EBCDIC to ASCII (because they are not EBCDIC in the first place).
More details about this subject can be found in Knowledge base article 17878.
