Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

An obscure question but just the kind I know SU users might be able to help with.

I've got a file from an iSeries that's encoded as CCSID 65535 (binary) which basically means that it's hex encoded (in EBCDIC). I'd like to understand how that format works as it seem to arbitrarily skip in and out of the hex encoding. For example:

4040404040404040404040F3F040404040404040404040F1        0      04040404040404040404040F8F0F0F3F54040404040F3F4F0404040F3F0F3F8F1F1F7F1F0F8404040404040404040404040404040404040 2009E2D5F9F6F0F0F0F0F0F7           0           04040404040404040404040404040404040404040

The 40 are EBCDIC spaces, this I know but you'll see that there are literal spaces in the text as well. The transitions happen on odd and even byte boundaries and looking that the first section with literal spaces "F1 0 040" you'll see a hex encoded '1' ("F1"), several literal spaces, a literal '0', some more spaces, a literal '0' again and then a hex encoded space. Tearing my hair out here, there seems to be no logic to it.

I suspect that the 'knowledge' for the format may be held in the iSeries in a separate definition but I can't find any definitive documentation on the web so I'm hoping that a guru here may know how this all fits together. Any guidance gratefully received!

share|improve this question
add comment

2 Answers

Have you checked this reference: Cast Your Data Conversion Troubles Away

share|improve this answer
    
I had read that reference, and I think the critical piece may be the File Field Definition and that's what I'm missing. I'll see if I can get the iSeries team to dump that for me but I was hoping there was something more fundamental that I was just missing that would preclude the need for a definition file which would then need to kept in synch with the iSeries definition. Thanks anyway (+1) –  Lazarus Sep 23 '09 at 12:10
add comment

The answer was that it is the File Field Definition that's the critical piece. There is no means to decode the file without that information. There also doesn't appear to be any .Net libraries for this that I can easily find. I think the difficulty is that you need to:

  • transform EBCDIC to ASCII (or more realistically ANSI or UTF-8)
  • decode the hex-encoded fields (CCSID 65535) to their native EBCDIC then covert those as well
  • you also need to handle the 0E (SI) and 0F (SO) which bracket double-byte EBCDIC and also need converting the appropriate destination character set (and code page)

Quite a lot to do for something that appears an obscure requirement.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.