C# encoding a file in EBCDIC with packed decimals
I have to prepare a file for an outside entity, and this entity uses an IBM mainframe with COBOL and requires the file to be encoded in EBCDIC. I am creating the file in C#. I guess this is a two-part question...firstly, is the code below sufficient to ensure that the file will be generated in a manner that they can read?
StreamWriter sw = new StreamWriter(@"C:EBCDICFileEquivalent.txt", false, Encoding.GetEncoding(37));
Secondly, several fields in the file require packed decimal, in the format S(9)13 COMP-3. Since I have already specified EBCDIC encoding, can I just write the decimal number (eg 1234500000001) to the file using:
sw.WriteLine("1234500000001C");
...and have it turn out correctly in the generated file?
Have never done anything with EBCDIC or COMP-3.
That code should create an EBCDIC file just fine. This usually isn't necessary, since the FTP process will usually convert the file automatically from ASCII to EBCDIC, but if that is not the case, then the file you are creating should be correct and may be transmitted as binary rather than text.
Writing the number out as text with the appropriate substitutions to satisfy the mainframe zoned signed decimal format is the correct procedure. Of course, making these substituions is a pain, but writing them out as a string as you are doing is the right way to get it into the file that the mainframe can read.
Secondly, several fields in the file require packed decimal, in the format S(9)13 COMP-3. Since I have already specified EBCDIC encoding, can I just write the decimal number (eg 1234500000001) to the file using:
sw.WriteLine("1234500000001C");
...and have it turn out correctly in the generated file?
No, you can't. That statement would write the EBCDIC bytes:
F1 F2 F3 F4 F5 F0 F0 F0 F0 F0 F0 F0 F1 C3
But this field is COMP-3 . That's not encoded characters; it's BCD with a sign nybble (C=positive, D=negative, F=unsigned).
12 34 50 00 00 00 1C
Assuming code page 37 is correct, you could write this to the file using the string "u0012u0094&u0000u0000u001C" , but it would make much more sense to write these non-text fields in binary mode.