Xref: utzoo comp.lang.c:22733 comp.sources.wanted:9022
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.c,comp.sources.wanted
Subject: Re: need EBCDIC to ASCII function
Message-ID: <10946@riks.csl.sony.co.jp>
Date: 6 Oct 89 10:15:50 GMT
References: <1060@einstein.misemi> <1989Oct4.203729.11700@utzoo.uucp>
Reply-To: diamond@riks. (Norman Diamond)
Followup-To: comp.lang.c
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 24

In article <1989Oct4.203729.11700@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

>You will have to be more specific.  Which flavor of EBCDIC?  EBCDIC is
>not a single well-defined character code, but a family of somewhat-similar
>codes.  (Which is why the Unix `dd' command has two different conversions,
>plus an entry in the BUGS section discussing this problem.)

For quite a while IBM pretended that ASCII was poorly defined too.
IBM played games with the parity bit in an effort to lock their
products out of a standard marketplace, though we all know that
they failed in this effort :-)

In fact EBCDIC is just as well-defined as ASCII.  Only some IBM print
trains did not use EBCDIC.  "dd" provides an alternative table so that
certain characters will print properly on those printers, but that
target code is not EBCDIC.  Also IBM terminals usually did not use
EBCDIC, so the operating system had to translate to and from the
device codes.

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.