SOS: C Routines for ASCII to EBCDIC Conversion and Vice-versa

[P E Smee]

In article <1991Jun19.190752.28034 at ssdc.honeywell.com> satya at ssdc.honeywell.com (Satya Prabhakar) writes:
>I am involved in developing the ISO/RDA protocol between CDC 920
>and IBM 3090.  CDC 920 uses ASCII representation and the IBM
>uses EBCDIC. I am looking for C routines that convert ASCII strings
>into EBCDIC strings and vice-versa.  We need these DESPERATELY and
>asap. If you have some information re: these, please let me know
>asap. I would REALLY appreciate your help.

There's a basic problem here, which is that there is (still) no such
thing as EBCDIC.  At present, for example (and I may have missed some
possibilities) the following codings might be used for 5 example
special chars:

    Char   ASCII    EBCDIC
    {      0x7b     0x43, 0x44, 0x51, 0x63, 0x9c, or 0xc0
    }      0x7d     0x47, 0x54, 0xd0, or 0xdc
    [      0x5b     0x4a, 0x90, 0x9e, 0xb1, 0xb5, 0xba
    ]      0x5d     0x51, 0x5a, 0x9f, 0xb5, 0xbb
    |      0x7c     0x4f, 0xbb

and, there are some characters in each set which don't exist in the
other.  Apropos those codes above, the problem is that original EBCDIC
did not define codes for a lot of the special chars, but they DID exist
on various IBM printer belts (in different places).  So, as a pragmatic
approach, various packages used, internally, the encodings which they
though most likely to work with the types of print belts that they
thought their type of users would use.

The UK's BlueBook file transfer protocol suggested using the following
mapping, which seems to work pretty well most of the time, which is as
good as you're gonna be able to do (has the advantage of being 1-1 and
reversible as long as the chars involved exist in the ASCII set):

    0x  1x  2x  3x  4x  5x  6x  7x  8x  9x  Ax  Bx  Cx  Dx  Ex  Fx
x0  00  10  40  F0  7C  D7  79  97
x1  01  11  5A  F1  C1  D8  81  98
x2  02  12  7F  F2  C2  D9  82  99
x3  03  13  7B  F3  C3  E2  83  A2
x4  37  3C  5B  F4  C4  E3  84  A3
x5  2D  3D  6C  F5  C5  E4  85  A4
x6  2E  32  50  F6  C6  E5  86  A5
x7  2F  26  7D  F7  C7  E6  87  A6
x8  16  18  4D  F8  C8  E7  88  A7
x9  05  19  5D  F9  C9  E8  89  A8
xA  25  3F  5C  7A  D1  E9  91  A9
xB  0B  27  4E  5E  D2  AD  92  C0
xC  0C  1C  6B  4C  D3  E0  93  4F
xD  0D  1D  60  7E  D4  BD  94  D0
xE  0E  1E  4B  6E  D5  71  95  5F
xF  0F  1F  61  6F  D6  6D  96  07

This is EBCDIC on the inside, ANSI (IA5) on the edges.  So, to turn
ASCII 0x21 into EBCDIC, you look in the column headed 2x on the row
labelled x1, and come up with EBCDIC 0x5a.  To find out what EBCDIC
0xD1 is, you find D1 in the table, in column 4x, row xA, so it is ASCII
0x4a.  (Note this assumes 0-parity ASCII, as well.)

Warning, EBCDIC is bigger than ASCII.  if you turn this into a set of
translation tables, you have to decide what you are going to do with
EBCDIC chars which do not appear in the table (with no corresponding
char in ASCII).  IBM's normal response is to just map them all to one
printing char (forgotten which, something like $ or &).

The above mapping seems to do the right sort of things with most IBM
applications -- e.g. ASCII C programs moved to an IBM and translated
this way will probably compile with the IBM C compiler.  Ditto other
language sources.

For a real real definitive answer, you'll have to get friendly with
someone in IBM.  I know THEY are trying to come up with a definitive
ASCII<->EBCDIC mapping as part of their SAA project; to dig themselves
out of the hole caused by the fact that IBM/PCs speak ASCII, while IBM
mainframes speak EBCDIC.  God only knows what mapping they'll end up
with.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee at bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132