Return to Answer

To my knowledge it's still possible with the latest zSeries iteration. The main issue to do so, beside finding a working reader is finding and chaining the necessary channel converters to bridge multiple generations (*2).

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

*2 - In fact, 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 :)

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

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

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

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

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

*5 - A service engineer I met ca. 1980 had written his own disk adjustment utility o 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 EBCDICC to EBCDIC conversion :))

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

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.

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

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

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 (*3), for a tape the first block found after rewind and a card reader simply the first card in stacker 1.

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

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 (*5).

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

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

*4 - A service engineer I met ca. 1980 had written his own disk adjustment utility o 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 :)

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

To my knowledge it's still possible with the latest zSeries iteration. The main issue to do so, beside finding a working reader is finding and chaining the necessary channel converters to bridge multiple generations (*2).

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

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.

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

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

*2 - In fact, 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 o 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 EBCDICC to EBCDIC conversion :))