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