Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!amelia!msf
From: msf@amelia (Michael S. Fischbein)
Newsgroups: comp.arch
Subject: Re: Compatibility with EBCDIC (was Re: Was the 360 badly-designed?
Message-ID: <2573@ames.arpa>
Date: Mon, 24-Aug-87 07:34:20 EDT
Article-I.D.: ames.2573
Posted: Mon Aug 24 07:34:20 1987
Date-Received: Tue, 25-Aug-87 01:44:17 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <1035@bsu-cs.UUCP> <26312@sun.uucp> <1044@bsu-cs.UUCP>
Sender: usenet@ames.arpa
Reply-To: msf@amelia.UUCP (Michael S. Fischbein)
Organization: NASA Langley Research Center, Hampton, VA
Lines: 63

I shouldn't say anything about the addressing or stack capabilities of the
360, since I didn't work on one, but even the smaller IBMs used EBCDIC and
I get tired of what I consider unjustified slams against it.  (Particularly
since there are several justified slams :-) ).

In article <1044@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>ASCII was designed quite logically.

So was EBCDIC.  So, for that matter, was CDC's 6-12 bit code, baudot 5-bit,
and (hold this thought) 12-bit hollerith.

>There were a few other design thoughts that went into ASCII but I don't
>remember them; I seem to faintly remember there was another way of
>deriving a subset alphabet.  Certainly it wasn't put together
>haphazardly like EBCDIC was.

Shucks, and I thought significant thought went into EBCDIC, too.  Of course,
being so much older than ASCII, different considerations were paramount.

>  It's hard to defend a character set in
>which (x >= 'A' && x <= 'Z') doesn't assure us that x is alphabetic:
>this is plainly a very undesirable property of EBCDIC.

But if you use that as the test, then ASCII lower case letters are not
alphabetic!  Or maybe you meant ( x>='A' && a<='z'), in which case \, ^,
_, and ` are alphabetic.

>  On the other
>hand, perhaps we should count our blessings and be thankful that IBM
>chose to make the digits contiguous, so we don't have to use a lookup
>table to evaluate a string of digits.

Of course, this is a fairly logical necessity if one is to start from
Binary Coded Decimal :-).

Now, project yourself back into the early 60s.  (Yes, EBCDIC is older than
that, but I think this is adequate).  What is the major data storage code,
dating back to the 1900 census?  12-bit hollerith encoding.  Quick now,
using the electronic components available then, design a simple unit record
device that will take punched cards and print the alpha contents on them.
Or, look at a blank punched card (ie, no printing, just holes) and
translate the punches into ASCII, in your head.
Difficult feat of memory?  Well then, why switch from that convenient
EBCDIC?  You could do that translation as fast as you could write down the
characters.  Further, so could your card reader.  ASCII would have slowed
it down.

Now, in the 80s, does EBCDIC still make sense?  Well, not really, except
where continued compatability with 25 year old records and programs is
important, or where the extra costs of conversion can't be justified in terms
of possibly increased efficiency in sorting.  If you want to slam EBCDIC,
talk about 026 vs 029 incompatibilities and such; don't spout about `holes'
or sorting order.  Every one of the myriad character codes available has
some advantages and some disadvantages, none are perfect.  ASCII is the
best compromise mostly because it is the most widely accepted, not because
it has some magic in its design.

		mike

Michael Fischbein                 msf@prandtl.nas.nasa.gov
                                  ...!seismo!decuac!csmunix!icase!msf
These are my opinions and not necessarily official views of any
organization.