EBCDIC <--> ASCII conversion

[P E Smee]

In article <28020001 at otter.hpl.hp.com> adw at otter.hpl.hp.com (Dave Wells) writes:
>Jonathan I. Kamens at Massachusetts Institute of Technology:
>
>|  The Unix program "dd" does this.  In particular, the "conv=ascii" option
>|converts EBCDIC to ASCII, and the "conv=ebcdic" option goes the other way.
>|  See the man page for more information.
>
>It's particularly worth noting this (from that dd man page):
>
>          ASCII and EBCDIC conversion tables are taken from the 256-
>          character ACM standard, Nov, 1968.  The ibm conversion,
>          while less widely accepted as a standard, corresponds better
>          to certain IBM print train conventions.  There is no
>                                                   ^^^^^^^^^^^
>          universal solution.
>          ^^^^^^^^^^^^^^^^^^^
>
>If you're translating "ordinary text files", dd will probably do the trick.
>If you're hoping to translate files or streams containing "unusual"
>characters (e.g. control codes for a graphics terminal), the exact
>translation table may well vary on a per-site basis.

Actually, it *can* be even worse than this, and you don't need to get
into very complicated characters.  Even 'ordinary text' can pose
problems.  Under VM/CMS (for example) there are at least 3 possible
EBCDIC mappings for the square brackets [ and ].  Which you need may
vary not only per-site, but even according to which package you used to
produce the file on a single machine.  Since commercial packages tend
to arrive 'object only', there's not even much you can do about it.

There are other similar problem characters.  []'s come instantly to
mind as a result of having spent some time trying to move a portable C
program into EBCDIC.  Generally, the problem is that such characters do
not exist in 'formal' EBCDIC; but do exist (with varying codings) on
different IBM printer belts.  As a pragmatic solution, package writers
have used the printer belt codes for them; and it appears that their
results vary depending on which belts (and printer models) their
development machine had.

-- 
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