Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch
Subject: Re: RE: IBM-ASCII-C-Etc
Message-ID: <1928@rlgvax.UUCP>
Date: Wed, 16-May-84 19:53:29 EDT
Article-I.D.: rlgvax.1928
Posted: Wed May 16 19:53:29 1984
Date-Received: Thu, 17-May-84 04:38:43 EDT
References: <2587@ncsu.UUCP> <627@ariel.UUCP>, <1915@rlgvax.UUCP> <286@unisoft.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 48

> >> > The original IBM 360 assembler that we used in Kingston, NY in
> >> > 1966 was actually a cross assembler which ran on IBSYS on a
> >> > 7094 across the road.  We used a three tape rotation system.
> >> > This is probably why the 360 had an ASCII bit in the PSW.
> >> 
> >> But didn't the 7094 use BCDIC (the six-bit predecessor to EBCDIC) rather
> >> than ASCII?  There was probably an ASCII bit there because IBM wanted to
> >> be able to support 8-bit ASCII when it came out - 7-bit ASCII was already
> >> out (or coming out soon), and there was an 8-bit version in the works - but
> >> it turned out the final version of 8-bit ASCII was not going to be what
> >> IBM expected it to be and not what the 360 implemented.  For that reason,
> >> and because converting all the 360 hardware and software to ASCII would
> >> have been a major undertaking, IBM canned the ASCII mode in the 370.
> >> 
> >>	 Guy Harris
> >> 	{seismo,ihnp4,allegra}!rlgvax!guy

> No no. IBM provided the ASCII bit in the PSW to allow the packed decimal
> instructions (and a few other instructions of the same ilk) to handle
> ASCII character data to/from numeric computations. This bit was used
> in the new 370's to indicate new modes of machine supervisor state
> operation. IBM announced at the time that it took a survey of customers
> to find out who was using the ASCII bit and found nobody was. Thus,
> since bits in the PSW were getting in short supply, they resused it.
> There was never any intention by IBM to convert to ASCII, nor was
> this bit anything more than a numeric character conversion aid.

There's a very easy way to handle ASCII character data to/from numeric
computations without an ASCII bit; convert to EBCDIC using "UNPACK" (or
whatever the BAL opcode was) or "EDIT"/"EDMK" and then convert to ASCII
using the translate instruction.  The ASCII bit would have been most useful
for programs running entirely with ASCII character strings, and such programs
would have been useful only if IBM had converted to ASCII.  In other words,
there are easier ways to convert packed decimal to ASCII than providing a
(non-user-settable! - LPSW is privileged) mode bit.  True, the only *effect*
of the ASCII bit is to change the behavior of PACK, UNPACK, EDIT, and EDMK;
but that change isn't really useful to programs running in EBCDIC, only to
programs running in ASCII.

Early in the life cycle of the 360, it might have been possible for IBM to
convert to ASCII.  Once enough of the machines got out there with EBCDIC
software and data files (ooh, sorry, "datasets"), it was too late - the
ASCII-8 standard didn't settle down in time.  It's not surprising that
nobody used it, considering 1) nobody was interested enough in ASCII and
2) IBM didn't support it except in the hardware.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy