Mainframers could be said to live by a code if their culture of scrupulousness were to be described as such.

It could also be said that mainframers live by code, particularly if they write COBOL, REXX, HLASM, Python, or any number of other languages — even JCL.

But we also live by a coded code: The extended binary-coded decimal interchange code (EBCDIC). Although this particular code page has never been the only one available on the mainframe — the original System/360 hardware was already compatible with an early version of ASCII (the American Standard Code for Information Interchange, a precursor to ANSI, the American National Standards Institute designated elaboration, and finally Unicode), it has become foundational to the reliable, established processing that runs the world economy. But like many kinds of code, it derives from earlier sets of circumstances.

Encoding data in a manner that could be processed is an essential origin of data processing, and while people such as Joseph Marie Jacquard (1804), Charles Babbage (1820s), and Herman Hollerith (1890) were pioneers on the journey of encoding data into punch cards, there were other ways that grew up parallel to this. Two of the most important and influential were Braille and Morse code.

According to Wikipedia, “Braille is named after its creator, Louis Braille, a Frenchman who lost his sight as a result of a childhood accident. In 1824, at the age of fifteen, he developed the braille code based on the French alphabet as an improvement on night writing. He published his system, which subsequently included musical notation, in 1829. The second revision, published in 1837, was the first binary form of writing developed in the modern era.”

Wikipedia also tells us that Morse code was developed around 1837 by American artist Samuel Morse, after he, American physicist Joseph Henry, and mechanical engineer Alfred Vail developed an electrical telegraph system for sending messages using pulses of electricity and silence.

Punch cards had ones and zeroes implicit in the presence or absence of punched holes in fixed locations. “Braille characters are formed using a combination of six raised dots arranged in a 3 × 2 matrix, called the braille cell” (per Wikipedia). Morse code had dots and dashes as the binary elements of communication, separated by silence rather than being in fixed locations. In some ways, this illustrates the contrast between random access and sequential data, with Morse code being essentially sequential, Braille being very much random access, and punch cards being configured for random access, but processed one-at-a-time in a sequential manner despite the structured random-access nature of the data on any given card.

Here's where it gets wild: all three of these exist in a vast space of communication using simple signals throughout history. From smoke signals to optical telegraphs and semaphores, people have been communicating long distances using electromagnetic transmission media (i.e. visible light) for a very long time. These methods informed the design and elaboration of all three systems, and ASCII was especially beholden to telegraphic encodings of data – particularly Morse Code – as it gradually developed. Consequently, even the IBM System/360 mainframe was configured to be able to use an early version of ASCII, which was emerging as a standard with historical precedent.

ASCII continued to develop. Various standards for it became available in 1961, 1963, and 1967, and the final ASCII standard was published in 1986. Immediately subsequent to this, in the late 1980’s, people from XEROX and Apple got together to develop an elaborated approach they named Unicode, which allowed for the inclusion of many different code pages of character sets.

Meanwhile, as Braille had its fixed character definitions, and ASCII emerged from the various telegraph systems to become an essentially 7-bit, 128-value system, and then be elaborated into ANSI and Unicode, EBCDIC grew up from the journey of representing increasingly complex business data on punch cards. And one big hint about that is the redundant use of the word “code” in its full name.

That is because the need to have consistent numerical encoding on punch cards begat the idea of BCD (Binary-Coded Decimal), which resulted in the Binary-Coded Decimal Interchange Code that consistently represented the data in the context of each vendor’s machines (though varying between different vendors such as IBM).

Then along came visionaries who insisted on using more than just digits and uppercase letters for their data. This was a challenge that took about two decades to resolve. At the end of World War II, IBM had surplus punched card machines left over from the war effort that were only capable of handling numeric data, even though the BCD encoding would allow for upper case letters. Within two decades, this got extended into a full 8-bit, 256-character set, with that great “E” that IBM loves to slap onto their mainframe products, only at the beginning of the name rather than as a “/E” at the end as became common in subsequent decades.

Key figures such as Fr. Dr. Roberto Busa, Rear Admiral Dr. Grace Murray Hopper, and Thomas J. Watson Sr. and Jr., contributed to this journey in ways that are described in greater depth elsewhere. At the end of it, and the beginning of the mainframe System/360 journey, Extended BCDIC, or EBCDIC, was born as the code page of preference, with a full character set, even if we took a few more decades to start regularly using things like lowercase letters.

Today, code page generations of ASCII, ANSI, and UNICODE have become the basis for most consumer and internet character data exchange. Yet, EBCDIC and its decimal and functional legacy continue to power the business financial and related data of the world economy. And while the journey from Morse and other telegraph codes to present day was more than a dash to the finish, the dots of our mainframe data have resolved into the underlying bits of the world’s economic information.