Disk read operations are much more complex than reading cards or tape. For cards or tape, a simple "read" command reads the next available record and sends it to the processor. Disk read operations require access arm positioning, head selection, a search for the correct record on the track, and then--finally--transfer of data to the processor.
It is not much of a surprise that older systems did not support Initial Program Load from disk. IPL from disk would have required fairly complex hardware logic to set up the needed commands, and additional logic would be needed to enable IPL from a selected disk among several.
The card reader was the only IPL device, although the 1130 relied heavily on its disk monitor system for job-to-job transition. The monitor was started by IPL'ing a three-card (later one-card) boot program that retrieved the boot block from the disk drive. The 1130 was available without a disk drive (models 1A and 1B), but all of the 1130's I worked on had exactly one disk drive.
This family of systems could only IPL from tape or cards, and the systems could be purchased and operated without disk. Disk-based versions of the various languages existed, and a scheme existed to put all of the languages on a single pack. But IPL was still from cards or tape.
The IBM 1620 did not support magnetic tape, according to available documentation. IPL was accomplished by typing in character-coded instructions on the console, or by keying those instructions on a card, loading the card into the 1622 card reader, and pressing Load on the card reader.
A disk monitor system was available and made extensive use of disk storage for programs and, it would seem, data. The disk monitor system was started by typing in a short program--or reading a card with the short program--that retrieved the boot block of the disk monitor system.
A Read Select command (RDS), which includes the boot device address, was set up in console switches, and the operator pressed the Load key. The processor then executed the RDS command, followed by a Reset and Load Channel A command (RCHA) using a channel command with maximum length and storage address 1000, which read some amount of data from the device identified in the RDS command. The processor then began instruction execution at location 1001.
Disk devices could not be attached to Channel A, the only channel that could be used to IPL the 7040.
The IBM System/360 departed from past practice and allowed for IPL from any card reader, tape, or disk. IPL read 24 bytes from the selected device.
And even more interesting, the 24 bytes were not intended to be processor instructions. Rather, the first eight were a channel command, a continuation of the I/O channel program started by IPL. The second eight often were another channel command, but such was not required. The third eight were the Program Status Word to be loaded at the completion of the IPL operation.
So the IPL paradigm of "read in some machine instructions and execute them" was replaced with "read in some I/O instructions, execute them to get the rest of the system startup program, and then execute the startup program."
While the disk IPL solution included in the System/360 architecture was simple, easy to understand, and ultimately worked well, it really just moved all of the complexity to the disk control unit by creating a "Read IPL" command. This command, CCW code X'02', was perhaps not coincidentally the same X'02' code used to read the next card or next tape record.
Read IPL was defined as reading cylinder zero, track zero, record 1, leaving it to the disk control unit and drive to figure out how to make that happen. But that wasn't entirely a bad thing, because when IBM started designing Fixed Block Architecture disks, they could define "Read IPL" as they wished at the disk controller level, as long at it returned 24 bytes from a known disk location to the processor.
When an operating system is booted from disk, disk storage becomes a basic component of the operating system's design, and can be exploited by the operating system design for whatever purpose deemed appropriate by the designers.
Prior to DOS/360, IBM system designers had to make disk an optional component, and system software had to be designed such that there might be disks available, but disks could not be taken for granted in DOS/360.