>I would also add that -- with 21st century hindsight and
>certainly not a design mistake per se -- it sure would have
>been lucky if they had standardized on ASCII instead of EBCDIC!
My understanding of history here is that the design did call for ASCII.
(I'm bracing myself for a shot of "garlic" URLs now. :-))
By the early 1960s IBM liked ASCII a lot. But production realities
intervened, and ASCII peripherals weren't available in time to make the
initial shipments. IBM had to fall back on the EBCDIC devices, and thus
the software evolved to support them. (It was also somewhat easier to get
EBCDIC software out the door, and the software was chronically late as it
was.) The processor certainly didn't require EBCDIC -- how could it if the
designers thought the peripherals would be ASCII? -- and nowadays there are
whole operating systems (e.g. Linux on z) which don't use EBCDIC.
Had IBM waited to finish the peripherals, it's hard to say what would have
happened, but I bet it wouldn't have been good. The 360s would have
shipped much later, IBM might have struggled to keep afloat after betting
the company on that product line, and the idea of a series of general
purpose (scientific and business) computers with upward (and usually
downward) compatibility, abstracting architecture from machine, might have
been deemed overly ambitious at the time. The fact the 360 design
philosophy did actually become reality was a huge breakthrough from a
software and business applications point of view. It directly contributed
to the rise of the middleware and packaged applications industries, for
example. Push the 1965 schedule out to, say, 1967 and you start to wonder
about timelines for software (like IMS and CICS) and whether the 360/67
(and thus VM) would have seen the light of day. And one also wonders
whether it would have been so easy for the large EBCDIC installed base to
move forward if 360 didn't support EBCDIC peripherals, delaying adoption of
the new architecture even further or blocking it altogether. And if IBM
went ASCII ("zig"), would other vendors have gone somewhere else anyway
("zag"), just for competitive reasons? Would the first Apple computers
have used NIVIC (Non-IBM Vendor Interchange Code) instead? :-)
About 15 years ago this looked like a "problem," the ASCII v. EBCDIC issue.
But history has moved on. ASCII is now declining in popularity pretty
quickly, more quickly than EBCDIC. Unicode, particularly UTF-16, is where
the world has moved. So modern operating systems like z/OS and modern
middleware support Unicode, along with the older ASCII character sets and
EBCDIC. What won the ASCII v. EBCDIC war? Unicode did. :-)
And then there's the fact the "A" stands for "American." In Japan, for
example, standard ASCII is only enough to cover romanji, yet there are
three other alphabets. So there are workaround oddities like shift-based
character sets, and those are really quite nasty (IMHO). In other words,
ASCII never really became a global standard even in its biggest days.
Finally, there is the fact that software engineers -- or at least human
factors engineers -- apparently never reviewed ASCII. As we all know,
EBCDIC puts the letters in the correct numerical order, collating uppercase
and lowercase: AaBbCc.... ASCII doesn't. It's ABCDEF...abcdef.... Thus
decades of dumb ASCII software -- and there's a lot of dumb software in the
world -- has frustrated users everywhere. I was listening to a radio
program this year, and the program's host was complaining bitterly about
the fact his studio database filing system thinks "Jackie" is different
than "jackie." (They couldn't find a prop in their inventory for months.)
Quite possibly as a byproduct of ASCII's strange idea of sorting, UNIX and
UNIX-derived operating systems made perhaps the biggest design mistake of
all time: case sensitivity in commands, file names, and directories. I'd
argue strongly that computing systems should be case retentive but not case
sensitive. Grrrrr....
....OK, enough rambling. :-)
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
