IBM Mainframe FTP – extended ASCII problem solved

I came across an issue when adding some new data to an existing FTP transfer in one of our nightly batch jobs.  The current functionality is only transferring standard ASCII encoded characters to an IBM mainframe dataset without issue.

The new version of the job, however, will be sending a block of extended-ASCII values in a field that we were not previously using.  The issue started when I had the new field populated and sent some test files to the mainframe.  The new extended-ASCII field was not being properly mapped to EBCDIC during the transfer, and the result consisted mainly of ‘?’ characters.

I tried changing the FTP transfer mode to binary, but that only made the rest of the file unreadable without viewing as hex values.

After searching around for a while, I found this post on technet dealing with Spanish characters not translating through FTP to a mainframe.  The fix for his issue, and mine, was to change the encoding used to call GetBytes with.  Instead of using Encoding.ASCII, I am now using the Windows-1252 encoding, which is providing correct results in the FTP file.

Update: Found out that the Windows-1252 encoding does not map all values from 0-255.  Several characters in my sample data were being encoded as the byte ‘3F’ instead of the correct value.  I found this post on stackoverflow, which pointed me to the true answer to my problem.  I have updated my code to use ISO-8859-1, which retains the original byte value after encoding.  I also changed the FTP connection to binary mode, and no longer have to write the “\r\n” newline bytes after each record.

The code below is using the library System.Net.FtpClient, found on CodePlex.