I have been idly looking into how System 370 works, though mostly at software and VM/370 OS. As a part of the system generation process, one needs to use DMKDDR utility and others. So I was curious how these work and get loaded.

The tape image I've found is in an AWS tape image format, and the file itself stored many 80 byte records, which are obviously punch card sized and even have a trailing labels for sorting them. Especially interesting are the first three cards that are used to store the IPL PSW and (in this case) two CCWs that load the next two card records into memory.

Either way, all those card records contain binary executable data, and practically all of it is not in a human-readable form. But how does that get punched onto the cards? A lot of things highlighting punch cards and EBCDIC do not seem to bother showing any extra mapping beyond the basic uppercase A-Z, 0-9 and (varied) symbols. But the bootloader and programs are specifically formatted like they were meant to go on a punch card. Is this a case of old format persisting in a different medium, or was it indeed possible to IPL off a stack of cards? Specifically using something like IBM 3505.

I've found a mapping between EBCDIC and punch card codes, but I am not sure if this is another case of IBM producing a highly specialized option for a limited amount of systems, or whether it's an actual mapping used in other things. The table in question is identical in its contents, if not exact formatting, and is present in a manual for IBM 1403 printer (GA24-3073-8, 1972), and a manual for IBM 2540 card punch (A21-9033-1, 1965).

EBCDIC _0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
0_ 2C03 2401 2201 2101 2021 2011 2009 2005 2003 2403 2203 2103 2023 2013 200B 2007
1_ 3403 1401 1201 1101 1021 1011 1009 1005 1003 1403 1203 1103 1023 1013 100B 1007
2_ 1C03 0C01 0A01 0901 0821 0811 0809 0805 0803 0C03 0A03 0903 0823 0813 080B 0807
3_ 3C03 0401 0201 0101 0021 0011 0009 0005 0003 0403 0203 0103 0023 0013 000B 0007
4_ 0000 2C01 2A01 2901 2821 2811 2809 2805 2803 2402 2202 2102 2022 2012 200A 2006
5_ 2000 3401 3201 3101 3021 3011 3009 3005 3003 1402 1202 1102 1022 1012 100A 1006
6_ 1000 0C00 1A01 1901 1821 1811 1809 1805 1803 0C02 3000 0902 0822 0812 080A 0806
7_ 3800 3C01 3A01 3901 3821 3811 3809 3805 3803 0402 0202 0102 0022 0012 000A 0006
8_ 2C02 2C00 2A00 2900 2820 2810 2808 2804 2802 2801 2A02 2902 2822 2812 280A 2806
9_ 3402 3400 3200 3100 3020 3010 3008 3004 3002 3001 3202 3102 3022 3012 300A 3006
A_ 1C02 1C00 1A00 1900 1820 1810 1808 1804 1802 1801 1A02 1902 1822 1812 180A 1806
B_ 3C02 3C00 3A00 3900 3820 3810 3808 3804 3802 3801 3A02 3902 3822 3812 380A 3806
C_ 2800 2400 2200 2100 2020 2010 2008 2004 2002 2001 2A03 2903 2823 2813 280B 2807
D_ 1800 1400 1200 1100 1020 1010 1008 1004 1002 1001 3203 3103 3023 3013 300B 3007
E_ 0A02 1C01 0A00 0900 0820 0810 0808 0804 0802 0801 1A03 1903 1823 1813 180B 1807
F_ 0800 0400 0200 0100 0020 0010 0008 0004 0002 0001 3A03 3903 3823 3813 380B 3807

The table that I've managed to find. Or rather conversion from how it was presented into being just a table of hex value of an EBCDIC byte to a punch card image value as per the manuals above (and IBM 2505 punch image reading mode, per manual). Though I might have the byte order wrong. First byte contains upper 6 hole states (two empty MSB, then rows 12, 11, 0, etc) and the second contains lower 6 hole states (in similar order).

Bold are the characters that have a footnote within the table provided in manuals, differing in their pattern from what is prescribed by the table.

I am wondering if this is the primary mapping between binary EBCDIC and punched cards, or merely one that is used on a few machines, and has many variations? I do know that other countries and various S360 derivatives used either a modification of this or an entirely different encoding.

  • 4
    The card reader had separate modes, EBCDIC and card image. The latter is 'just bits'. I imagine the table you reference is how to type binary data on a keyboard-operated punch if you have to do that. However, a real binary deck would likely be written on a card punch peripheral, not keyed in.
    – dave
    Nov 26, 2023 at 21:39
  • 1
    See also retrocomputing.stackexchange.com/questions/14082/…
    – dave
    Nov 26, 2023 at 21:40
  • 2
    @raffzahn's answer here retrocomputing.stackexchange.com/questions/18102/… describes column binary
    – dave
    Nov 26, 2023 at 22:04
  • 1
    @another-dave Oh, had already forgotten about that one:)) Also, true, cards could be read in Mode 1 (character) or mode 2 (column binary) form a reader, but during IPL EBCDICC translation of a controller is used. That way it's still a punch card code with redundancies, nit flat binary.
    – Raffzahn
    Nov 26, 2023 at 22:17
  • The question is a bit confusing It might be helpful to weed it out a bit (tried to answer what I could see).
    – Raffzahn
    Nov 26, 2023 at 22:21

2 Answers 2


TL;DR: Yes, a /360 (*1) can boot from any device connected to a channel.

A /360 can boot from any device able to answer to a basic read command. Whatever is delivered will be executed. There is no 'boot' sequence or hierarchie. The read will always go to the one device selected at the console.

To my knowledge even the latest zSeries iteration will happily IPL from a punch card reader. The main issue to do so, beside finding a working reader, is finding and chaining the necessary channel converters to bridge multiple generations and connect a basic slow byte-mux all the way to a fiber channel or whatever is en vogue today(*2).

We Do Not Boot - We IPL

When IPL is initiated the micro program will issue an IO operation to read one record from the selected device.

It uses a 'virtual' CCW located at address 000000 consisting of (*3)

  • Channel Command Read (02)
  • Memory Address 000000
  • Flags CC, SLI (Continue Chaining and Ignore Length Issues)
  • Length 0000 (=64 KiB)

With such a CCW the IO-System will read the first record of a device. In case of a disk that would be cylinder 0, head 0, record 1 (*4), for a tape the first block found after rewind and a card reader simply the first card in stacker 1.

Of course those blocks can be rather different. A disk might (usually) deliver 24 bytes, a tape something else and a punch card reader our beloved 80 bytes. Anything up to 64 KiB is fine. And there will be no error as SLI specifies that the operation will be continued even when the required length could not be read.

If the read date the CPU expects the PSW in the first 8 bytes, setting up the basic machine operation.

When that first record is read, the IOC will continue with the next one as instructed by the CC bit- which it expects to be at 000008. A disk loader will have a positioning CCW at8 and another read at 16 (hence a 24 byte record).

How a punch card continues is up to the card, like reading a series of cards with more code or whatever (*5).

What's EBCDCC or How To Binary Punch Cards

Extended Binary Coded Decimal Card Code is punching scheme used to store 8 bit values on punch cards while keeping compatibility with existing character based encoding. Or in simple words: adding unique combinations for all 8 bit values not already covered by heritage encoding. Nicely shown here:

enter image description here

(Taken from the 1969 2821 Manual p.10 A24-3312-7)

I would think it's the same encoding as provided by the question, except not as some 'binary' notation but listing of punch holes. This is important as that 12 bit 'binary' is nothing the Mainframe (normally sees) or handles. it's only present between Card Reader (like a 2540) and its control unit (2821 in this case).

What follows is a little trick of compatibility. The 'virtual' IPL CCW uses a basic IO-READ command of X'02', which the 2821 interprets as reading from the first stacker in mode 1 (Character). Except the controller will always operate the reader in mode 2:

enter image description here

(Taken from Page 8 of the 2540 Manual)

Doing so disables all conversion and checking of the reader and let the controller convert those 12 holes to 8 bit EBCDIC using above table (*6).

A result of this compatibility measure is that a basic read command issued by the micro program is able to deliver arbitrary 8 bit binary data form an accordingly punched card.

Punch Me If You Can

Punching EBCDCC cards is no dark art, just work. For one, a Port-a-Punch can do it.

IBM Port-A-Punch

(Taken from Wikipedia)

Ok, a bit tortuous, but the same can be done with any keypunch. They all offer a mode where one can punch arbitrary combinations. Some late (none IBM) models even offered binary punching according to EBCDCC.

Then again, all that are tools for special situations and to tinker. Any developer needing to create a 'binary' stack would write an according (Assembly) program and have it simply output the binary records to a punch ... whose controller would nicely convert 8 bit (EBCDIC) binary into EBCDCC.

*1 - /370, XS, ESA, /390, Z and so on are still /360 at heart - family naming with them is more of a marketing thing than related to technology.

*2 - Not long ago, a good friend working at a Linux company, told me, that there is a lady at IBM Germany who still keeps such a setup in storage and a set of IPL cards at her desk. Nerds everywhere :)

*3 - So far that's just 3 out of 88 bits set to 1, funny, how nice that works out.

*4 - Note, it reads a record, not a sector.

*5 - A service engineer I met ca. 1980 had written his own disk adjustment utility to a single punch card. When loaded it issued a series of seek commands in specific order which produced a notable sweeping sound which helped him to identify drives with bad alignment :)

*6 - More exact it'll use of course an inverse version made for EBCDCC to EBCDIC conversion :))

  • 5
    The Port-a-Punch was how I wrote FORTRAN IV programs for IBSYS (which was 24 or 48 hrs away by Post Office mail). Kids today and their "IDEs", bah!
    – dave
    Nov 26, 2023 at 23:04
  • 1
    Ah, missed the part about the punch card devices controller. Yeah okay that does make sense then!
    – Saphire
    Nov 27, 2023 at 2:58

Sorry for the narrative here, but it answers the OP's question directly by personal experience. The text is too long for a comment.

"Was bootloading from punch cards possible on System/370 machines?"

Yes it was indeed. I personally did it back in 1973. I was a computer operator on that system at a major US airline. We had two identical 370s, one online running reservations and one offline as standby. Working graveyards, we had many hours in the middle of the night to experiment with the offline machine. I learned BAL (IBM Basic Assembly Language) and figured out how to IPL (boot) the machine using channel commands encoded in a program on punched cards. I would place the cards in the reader, ready it, dial in the device address on the main panel, and IPL from that device. The cards would read and the machine would run the program.

The ultimate program I wrote saved the machine's core memory out to tape. I eventually used that program to demonstrate that the PARS operating system (Programmed Airlines Operating System) could be swapped between two machines simply by hitting "Stop" then "Reset" on machine #1, running the program to write memory to tape, take the tape over to machine #2, then boot or IPL a similar punched card program that read the tape and copied its contents to machine #2's memory. "Reset" was then hit, then "Start", and the first hardware interrupt that occurred on machine #2 set it in motion just as if it had been freshly IPLed in the usual sense.

The switchover from machine #1 to machine #2 and subsequent IPLing of these large networked 370's with many, many disk storage units took quite a long time, 20 or 30 minutes as I remember. That little program I wrote reduced it to about 5 minutes. Practically, it was never used because it was considered too dangerous and non-standard.

  • 3
    Everyone's afraid of having their brain transplanted while they take a nap, even if it's perfectly safe.
    – hobbs
    Nov 28, 2023 at 18:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .