Note that there was more than one BCD code; there were even different models of the keypunch depending on whether you wanted a scientific or commercial character set. If you consider other vendors it's even worse.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jonathan Scott <[email protected]> Sent: Monday, November 27, 2017 6:20 AM To: [email protected] Subject: Re: Special character # on ASM names Ref: Your note of Mon, 27 Nov 2017 11:03:11 +0000 > IBM provides the iconv() family of functions that allows it to > transform between codepages. For SBCS 3270 code pages, the IBM GDDM product provides text conversion between the stored text code page and the terminal code page, and that function was used for example by BookManager to display books in a way which hid most code page effects from the user. This was originally implemented for the 3277 internal code pages but the later CECP code pages provided a more flexible solution, in that all of them contained the same characters (the same as the first 256 bytes of Unicode now, which in sequence form ISO 8859-1, IBM code page 819, very similar to Windows 1252). Unfortunately, the invention of the Euro symbol and the need to fit it into those code pages made a slight mess, in that it replaced the general "currency symbol" with the side effect that the new set of code pages no longer mapped 1-to-1 to code page 819. > Of course, your code will then be as ugly as sin; you can blame the > half-baked mess that IBM cooked up in the late 1970s, when they realised > that there was a market for non-English data processing and invented the > so-called 'National Use Characters' in great haste. Although I can't find a definitive reference, I'm sure that National Use characters were available in the form of modified print chains and print heads (for teleprinters and similar) long before that point. Both for EBCDIC and ASCII, the limited number of characters available on physical printing devices meant less commonly used characters were replaced by national use characters. Although systems later became able to display and print many more symbols, many national use encodings were retained to ensure compatibility. EBCDIC was originally a largely compatible 8-bit extension of the previous 6-bit BCD code used in IBM computers before System/360, such as the 1401 series, and even earlier for punched card accounting systems. The IBM 360 was developed before ASCII was finished but was originally intended to support ASCII as well (and had an ASCII mode bit in the PSW, which in the end only affected the representation of packed decimal signs) but was initially constrained by compatibility with existing BCD customer files and with BCD-based peripheral devices such as the 1403 printer, so the software for OS/360 ended up being written entirely in EBCDIC, and the ASCII bit was dropped from the System/360 successors. For some interesting stories about the history of ASCII and EBCDIC, see the website originally created by Bob Bemer, the "Father of ASCII", including for example his article "EBCDIC and the P-Bit (The Biggest Computer Goof Ever)": https://www.bobbemer.com/P-BIT.HTM For IBM, compatibility is one of its greatest strengths and also one of its greatest problems. Many user programs written for OS/360 in the 1960s would still run unchanged today, even without being recompiled, which is amazing. But whenever IBM creates a better way of doing something, it is very hard to introduce an easy way to make it the "normal" way without causing problems for existing users. So for example we can add new checks to HLASM to warn people when they are doing things which are probably a mistake, but it is not normally acceptable for us to enable these new helpful checks by default because that might cause existing working programs to produce warning messages next time they are reassembled, causing the build process to fail. Also, there are various design decisions made in the past in the Assembler which in retrospect should have been done differently (an obvious example is that substitution of SETA symbols into text does not insert a minus sign for a negative value), but we cannot change them now without risking breaking existing code. In certain cases, we can provide compatibility switches (as for HLASM's COMPAT options), but that adds even more complexity. Jonathan Scott HLASM, IBM Hursley, UK
