Convert COMP and COMP-3 Packed Decimal into readable value with C

Question

I have an EBCDIC flat file to be processed from a mainframe into a C module. What can be a good process in converting the COMP and COMP-3 values into readable values? Do I have to convert the ebcdic characters to ascii then hex for COMP-3? What about for COMP? Thanks

Answer 1

Bill Woodger has given you some very good advice through his comments to your question, actually he answered the question and should have posted his comments as an answer.

I would like to reiterate a few of his points and expand on a few others.

If you need to convert a file created from what is probably a COBOL application so it may be read by some other non-COBOL program, possibly on a machine with an architecture unlike the one where it was created, then you should demand that the file be created using only display formatted data (i.e. all character data). Mashing non-display (binary, packed, encoded) data outside of the operating environment where it was created is just a formula for long term pain. You will be subjected to the joys of sorting out various endianness issues between architectures and code page conversions. These are the things that file transfer protocols are designed to manage - they do it well so don't try to reinvent them. Short answer, use FTP or similar file transport mechanism to move data between machines. And only transport display (character) based data.

Packed Decimal (COMP-3) data types occupy a varying number of bytes depending on their specific PICTURE layout. The position of the decimal point is implied so cannot be determined without reference to the PICTURE used to define it. Packed Decimal fields may be either signed or unsigned. If signed, the sign is imbedded in the low 4 bits of the least significant digit. Each byte of a Packed Decimal data type contains two digits, except possibly the first and last bytes. The first byte contains only 1 digit if the field is signed and contains an even number of digits. The last byte contains 2 digits if unsigned but only 1 if signed. There are several other subtlies that you need to be aware of if you want to do your own Packed Decimal to character conversions. At this point I hope you can see that this is not going to be a trivial exercise.

Binary (COMP) data types have a different but no less complex set of issues to resolve. Again, not a trivial exercise.

So what should you be doing? Basically, do as Bill suggested. Have the program that generates this file use display formats for output (meaning you have to do nothing). Or, failing that, use a utility program such as DFSORT/SYNCSORT do the conversions for you. Going the utility route still requires that you have the original COBOL file layout (and that you understand it) in order to do the conversion. The last resort is simply writing a simple read-a-record-write-a-record COBOL program that takes in the unformatted data, MOVEes each COMP-whatever field to a corresponding DISPLAY field and write it out again.

As Bill said, if the group that produced this file tells you that it is too difficult/expensive to produce a DISPLAY formatted output file they are lying to you or they are incompetent or just too lazy to do the job they were hired to do. I can think of no other excuses.

Answer 2

Use XML to transport data.

That is, write a program that converts your file into characters (if on mainframe, stay with the EBCIDIC but numeric fields are unpacked, etc.) and then enclose each record and each field in XML tags.

This avoids formatting issues (what field is in column 1, what field in column 2, are the delimters spaces or commas or either, etc. ad nauseum).

Then transmit the XML file with your favorite utility that converts from EBCIDIC to ASCII.