The EBCDIC Format: A Multipart Series

For a developer who has only written software for only server and client systems it is easy to see the monolithic mainframe systems with a bit of a legacy mindset. Whether or not the legacy bit is actually true -- I am not here to debate that topic -- the fact remains that, depending on what industry you find yourself writing software solutions for, there are a lot of mainframe systems out there that we must interface with, at least with the output of these systems.

By and large, the output from these systmes will be in a binary format referred to as EBCDIC, which is an acronym for a term created by IBM that is _Extended Binary Coded Decimal Interchange Code. _If there was only uncompressed (also known in EBCDIC-land as unpacked) plain text fields with no special features like field Redefines or Occurs, etc., the translation would be as easy as flipping the code page to ASCII to translates the bytes. However, that is the rarely teh case when dealing with an EBCDIC file, and as with most problems in computer science, the devil is in the details.

This multipart series, which I hope to publish over the coming weeks, will break apart each of the different facets that pose a problem for the conversion of EBCDIC data into ASCII so that it might be of use on PC based systems. This will largely be decoupled from any particular platform or OS, however, if examples are given that are coupled, then it will be usin C# and the .NET CLR 2.0.

Stay tuned...