Extended Binary Coded Decimal Interchange Code (EBCDIC; ) is an eight-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems. It descended from the code used with punched cards and the corresponding six-bit binary-coded decimal code used with most of IBM's computer peripherals of the late 1950s and early 1960s. It is supported by various non-IBM platforms, such as Fujitsu-Siemens' BS2000, BS2000/OSD, OS-IV, MSP, and MSP-EX, the SDS Sigma series, Unisys VS/9, Unisys MCP (Burroughs Large Systems), MCP and International Computers Limited, ICL ICL VME, VME.

History

Blue-punch-card-front-horiz top-char-contrast-stretched

EBCDIC was devised in 1963 and 1964 by IBM and was announced with the release of the IBM System/360 line of mainframe computers. It is an eight-bit character encoding, developed separately from the seven-bit ASCII encoding scheme. It was created to extend the existing binary-coded decimal#IBM, Binary-Coded Decimal (BCD) Interchange Code, or BCDIC, which itself was devised as an efficient means of encoding the two ''zone'' and ''number'' punches on punched cards into six bits. The distinct encoding of 's' and 'S' (using position 2 instead of 1) was maintained from punched cards where it was desirable not to have hole punches too close to each other to ensure the integrity of the physical card. While IBM was a chief proponent of the ASCII standardization committee, the company did not have time to prepare ASCII peripherals (such as card punch machines) to ship with its System/360 computers, so the company settled on EBCDIC. The System/360 became wildly successful, together with clones such as RCA Spectra 70, ICL System 4, and Fujitsu FACOM, thus so did EBCDIC. All IBM mainframe and Midrange computer, midrange operating systems use EBCDIC as their inherent encoding (with toleration for ASCII, for example, ISPF in z/OS can browse and edit both EBCDIC and ASCII encoded files). Software can translate to and from encodings, and modern mainframes (such as IBM Z) include processor instructions, at the hardware level, to accelerate translation between character sets. There is an EBCDIC-oriented Unicode Transformation Format called UTF-EBCDIC proposed by the Unicode Consortium, designed to allow easy updating of EBCDIC software to handle Unicode, but not intended to be used in open interchange environments. Even on systems with extensive EBCDIC support, it has not been popular. For example, z/OS supports Unicode (preferring UTF-16 specifically), but z/OS only has limited support for UTF-EBCDIC. Not all IBM products use EBCDIC; IBM AIX, Linux on IBM Z, and Linux on Power all use ASCII.

Compatibility with ASCII

There were numerous difficulties to writing software that would work in both ASCII and EBCDIC. * The gaps between letters made simple code that worked in ASCII fail on EBCDIC. For example would print the alphabet from A to Z if ASCII is used, but print 41 characters (including a number of unassigned ones) in EBCDIC. * Sorting EBCDIC put lowercase letters before uppercase letters and letters before numbers, exactly the opposite of ASCII. * Most programming languages and file formats and network protocols designed for ASCII used available punctuation marks (such as the curly braces and ) that did not exist in EBCDIC, making translation to EBCDIC systems difficult. Workarounds such as digraphs and trigraphs, trigraphs were used. Conversely EBCDIC had a few characters such as (Penny (United States coin), US cent) that got used on IBM systems and could not be translated to ASCII. * The most common newline convention used with EBCDIC is to use a Newline, NEL (NEXT LINE) code between lines. Converters to other encodings often replace NEL with Line feed, LF or CR/LF, even if there is a NEL in the target encoding. This causes the LF and NEL to translate to the same character and be unable to be distinguished. * If seven-bit ASCII was used, there was an "unused" high bit in 8-bit bytes, and many pieces of software stored other information there. Software would also pack the seven bits and discard the eighth, such as packing five seven-bit ASCII characters in a 36-bit word. On the PDP-11 bytes with the high bit set were treated as negative numbers, behavior that was copied to C (programming language), C, causing unexpected problems if the high bit was set. These all made it difficult to switch from ASCII to the 8-bit EBCDIC (and also made it difficult to switch to 8-bit extended ASCII encodings).

Code page layout

There are hundreds of EBCDIC code pages based on the original EBCDIC character encoding; there are a variety of EBCDIC code pages intended for use in different parts of the world, including code pages for non-Latin scripts such as Chinese, Japanese (e.g., EBCDIC 930, JEF, and KEIS), Korean, and Greek (EBCDIC 875). There is also a huge number of variations with the letters swapped around for no discernible reason. The table below shows the "invariant subset" of EBCDIC, which are characters that ''should'' have the same assignments on all EBCDIC code pages that use the Latin alphabet. (This includes most of the ISO/IEC 646 invariant repertoire, except the exclamation mark.) It also shows (in gray) missing ASCII and EBCDIC punctuation, located where they are in Code Page 37 (one of the code page variants of EBCDIC). The blank cells are filled with region-specific characters in the variants, but the characters in gray are often swapped around or replaced as well. Like ASCII, the invariant subset works only for English, excluding loan words.

Definitions of non-ASCII EBCDIC controls

Following are the definitions of EBCDIC control characters which either do not map onto the C0 and C1 control codes#C0 controls, ASCII control characters, or have additional uses. When mapped to Unicode, these are mostly mapped to C1 control character codepoints in a manner specified by IBM's Character Data Representation Architecture (CDRA). Although the default mapping of New Line (NL) corresponds to the ISO/IEC 6429 Next Line (NEL) character (the behaviour of which is also specified, but not required, in Unicode Annex 14), most of these C1-mapped controls match neither those in the C0 and C1 control codes#C1 control codes for general use, ISO/IEC 6429 C1 set, nor those in other registered C1 control sets such as ISO 6630. Although this effectively makes the non-ASCII EBCDIC controls a unique C1 control set, they are not among the C1 control sets registered in the ISO-IR registry, meaning that they do not have an assigned control set designation sequence (as specified by ISO/IEC 2022, and optionally permitted in ISO/IEC 10646 (Unicode)). Besides U+0085 (Next Line), the Unicode Standard does not prescribe an interpretation of C1 control characters, leaving their interpretation to higher level protocols (it suggests, but does not require, their ISO/IEC 6429 interpretations in the absence of use for other purposes), so this mapping is permissible in, but not specified by, Unicode.

Code pages with Latin-1 character sets

The following code pages have the full ISO 8859-1, Latin-1 character set (ISO/IEC 8859-1). The first column gives the original code page number. The second column gives the number of the code page updated with the euro sign (€) replacing the universal currency sign (typography), currency sign (¤) (or in the case of EBCDIC 924, with the set changed to match ISO 8859-15)

Criticism and humor

Open-source software advocate and software developer Eric S. Raymond writes in his ''Jargon File'' that EBCDIC was loathed by hackers, by which he meant members of a subculture of enthusiastic programmers. The Jargon File 4.4.7 gives the following definition: EBCDIC design was also the source of many jokes. One such joke, found in the Unix fortune (Unix), fortune file of 4.3BSD Reno (1990) went: References to the EBCDIC character set are made in the 1979 computer game series ''Zork''. In the "Machine Room" in ''Zork II'', EBCDIC is used to imply an incomprehensible language: In 2021, it became public that a Belgian bank was still using EBCDIC internally in 2019. This came to attention because a customer insisted that the correct spelling of his surname included an Germanic umlaut, umlaut, which the bank omitted. The customer filed a complaint citing the guarantee in the General Data Protection Regulation of the right to timely "rectification of inaccurate personal data." The bank argued in part that it could not comply because its computer system was only compatible with EBCDIC, which does not support umlauted letters. The appeals court ruled in favor of the customer.

Notes

References

External links

* IBM-related: ** . Contains IBM's official information on code pages and character sets. *** [ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.pdf Code page 37] *** [ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP01047.pdf Code page 1047] *
Host Code Page Reference
from IBM, shows code charts for several single-byte IBM EBCDIC pages. *
ICU Converter Explorer
Contains more information about EBCDIC derived from IBM's CDRA, including DBCS EBCDIC (Double Byte Character Set EBCDIC) *
ICU Charset Mapping Tables
Contains computer readable Unicode mapping tables for EBCDIC and many other character sets ** from
XHCS V2.0 manual
shows code charts for several single-byte Siemens/Fujitsu (as opposed to IBM) EBCDIC pages used on the BS2000. * * * {{Character encodings IBM mainframe operating systems EBCDIC code pages,