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.


New to Outlook? Here are the first steps I took!

We just switched from Lotus Notes to Outlook this week at work.  It’s a pretty big transition, and a much different environment.  I do enjoy having a standalone IM client in Lync, even though it has its own set of quirks.  After getting Outlook 2010 installed, I started comparing it to my old Notes experience.

The first thing I noticed was Outlook’s difficulty in highlighting new messages in collapsed folders.  I use many mail rules to filter messages away from my inbox, and all the folders live under a “Business Critical” folder.  Well, if I have that folder collapsed, I get no persistent marker that there is unread mail sitting below that level!  Notes would at least bold the folders all the way up the hierarchy if there were unread messages below.  Thankfully, Outlook has dynamic “Search Folders” that make this much easier to deal with.  I created a search folder for today’s unread mail, and for mail addressed to anyone on my team.

That brings me to the other major change to my flow, mail rule settings.  After reviewing the rules I had set up in Notes, I found that I could not easily duplicate all of them into Outlook.  In several of my old rules, I had several conditions “OR”ed together, and Outlook can only “AND” different types of conditions.  It’s not a problem if you are filtering on multiples of the same type (from / to / in subject or body / etc.).  The issue arises when there are multiple conditions in different fields that should trigger a rule.

I used to have some rules that would filter based on a list of senders, or on key words contained in the subject or body.  I now have to create multiple separate rules in Outlook to achieve similar results.

Finally, the team calendar view is a much better experience in Outlook.  I constantly found myself creating meetings in Notes just to check the availability of several people at once.  In Outlook I can just add them to the list of calendars to display and check them off down the row.  Now to get the others on my team to set up the view permissions with each other so we can see a little more detail than just free / busy time.