"I have seen this before"--what is "this"? I'm curious about your assertion that ASCII/EBCDIC cannot translate cleanly. With the right EBCDIC code page, we do this every day. The basic etoa() and atoe() work fine, have not caused problems--and we care a lot about specific characters, as we support "encrypt in EBCDIC, decrypt in ASCII" and vice versa with Format-Preserving Encryption.
It seems clear that if IBM had inflicted (no scare quotes needed) ASCII as the native encoding for S/360, there would have been more resistance. OTOH it's not clear what realistic choice those customers would have had. There is always the "If I have to do a conversion, I will at least look at alternatives", and with IBM's fate hanging on the success of S/360, maybe that would have been the proverbial straw; we'll never know. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tom Marchant Sent: Wednesday, May 8, 2024 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EBCDIC/ASCII - FTP I have seen this before, and I am not persuaded. I find it interesting that all of the references provided were written by Mr. Beemer himself, some of them with another author. Perhaps, in hindsight it would have been better if IBM had made the System/360 an ASCII only machine. But at the time, ASCII was new and relatively unknown. As it was, the market had generally rejected ASCII on System/360, so the USASCII bit was removed with the introduction of System/370 in 1970. Both ASCII and EBCDIC are limited. ASCII, even more so because it is a 7 bit code, though there are proprietary 8 bit extensions. No one knew in 1964 that Unicode would later be designed based upon ASCII. The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] exists" is false.Each includes characters that are not defined in the other. This has always been the case. If IBM had "inflicted" ASCII on its customers in 1964, would the System/360 have had the wide acceptance that it did? We will never know. According to "Architecture of System/360" https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf <quote> The reasons against such exclusive adoption was the widespread use of the BCD code derived from and easily translated to the IBM card code. To facilitate use of both codes, the central processing units are designed with a high degree of code independence, with generalized code translation facilities, and with program-selectable BCD or ASCII modes for code-dependent instructions. Neverthe- less, a choice had to be made for the code-sensitive I/O devices and for the programming support, and the solution was to offer both codes, fully supported, as a user option. Systems with either option will, of course, easily read or write I/O media with the other code. </quote> Aside from that, it wasn't the "P-bit", but the A bit. -- Tom Marchant On Wed, 1 May 2024 11:31:56 -0500, Paul Gilmartin <paulgboul...@aol.com> wrote: >Seriously!? After IBM inflicted the burden of EBCDIC on users: ><https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-B >IT.HTM> it chooses to torment them with the need to learn different >conventions for various products? Consistency would be a boon here. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
