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

Question

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.

Answer 1

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:

(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:

(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.

(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 :))

Answer 2

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.