The IBM 2311 was a modern multiplatter multi-head removable disk. Unlike the IBM 350, which had a single arm that moved up and down alongside a stack of platters, dashing in to read a track from a selected platter, the 2311 had a head assembly that could read any track in a cylinder without moving the head assembly.
Ten platter surfaces were divided into 200 tracks each, for a total of 2,000 tracks for data storage. The ten tracks at the same position on each of the platter surfaces could be accessed without moving the head assembly and were known as a cylinder. Ten tracks per cylinder, 200 track positions per platter, 2,000 tracks across 200 cylinders.
But it had limited capacity. How limited? About 3.6K per track, for a total disk capacity of about 6.9MB. Not GB, MB. The disk pack is too small to hold a complete DOS/360 distribution system. Indeed, it's too small to hold a typical smartphone application, but that's another story.
It was enough, though, to hold about 45 boxes of punched 80-column cards (9 cases), and at the time that was the measure that counted.
The structure of the 2311 distribution volumes leads to a requirement for a fourth work file volume, assembler output to tape or punched cards, and multiple IPL's to assemble and link a supervisor and related system phases. The core image libraries are also nearly full, so it's difficult to update the libraries with a new supervisor and related modules.
When doing this for real for a paying customer--or employer--the first task for the intrepid Systems Programmer was the deletion of anything not needed for the planned system. The System Generation manual Appendices provide much detail on the phases, modules, and source books associated with given bits of functionality to aid in this process. QTAM was likely the first thing to go. At least it was when I did it on a 360/40, and I had 2314 disks and distribution tapes. One could then condense libraries and have a system sufficient for a proper system generation.
And a system generation is definitely needed to replace the distribution system's pre-generated supervisor. The distribution system supervisor was intended not for production workloads, but rather to generate a workable system capable of running production workloads.
That supervisor was designed to run on a mimimal 360/30 configuration (16k of core) and consists of a 6K supervisor and a limit of ten devices. Given that four of the ten are the console, printer, card reader, and card punch, one is left with six to divide between disk and tape drives.
The split of the relocatable and source libraries across two IPL'able system residence volumes means that a compile-link-execute of, say, a FORTRAN or COBOL program will require multiple IPLs and transfer of the object output from the compiler using cards or tape. Likewise multiple IPLs are required to assemble and link a supervisor. The distribution system supervisor is too small to do anything interesting without requiring one to do many things that are not interesting.
Because the goal here is a system for experimentation and fun, all of that stuff I would have deleted in real life to make a workable system should stay on the system. So a 2311-based system is not, as it were, in the cards.
A 2314 disk volume has about twice the track capacity of a 2311, and it also has twice the number of tracks. So a single 2314 volume matches up to four 2311 volumes more or less. Full 2311 volumes (6.9MB each) turn into 2314 volumes (27.8MB each) with lots of space left over for work files, POWER spooling space, work files for multiple partitions, and--perish the thought--application data. Still smaller than a smartphone app, but big enough that doing "real" work doesn't require multiple IPLs.
So we'll use the distribution system only to create a starter system on a 2314 volume. The starter system will be used to generate an adequate supervisor, install POWER, and other fun stuff. Seems simple enough...
Here's the trouble: CORGZ, the DOS/360 program used to create and copy libraries from one disk to another, will only copy between libraries on the same disk type. A copy from 2311 to 2314 (or vise versa) is not supported, I believe because the folks that wrote CORGZ did not code what's needed to convert a 2311 core image library, with its 1728 block size, to a 2314 library with a 1688 block size.
The block sizes differ to optimize space utilization on the respective device types. A 2311 will store two 1728-byte blocks per track, while a 2314 will store only three of these blocks per track. Decreasing the block size to 1688 enables storage of four blocks per 2314 track, a 33% improvement in capacity. Why not make the 2311 block size 1688? Because the 2311 came along long before the 2314 arrived, and IBM was not going to force--or write code for--a core image library block size change for its 2311 users.
One may reasonably suppose that if the 2314 had come first, the core image library block size would have been 1688 on both the 2311 and the 2314, with some loss of storage efficiency on the 2311. And CORGZ would have been written to support transfers between libraries resident on different device types.
Source and relocatable libraries have the same block size on 2311 and 2314 and therefore are much simpler. But CORGZ does not copy source or relocatable libraries between different device types either. Probably because if one could not copy core image libraries between different device types, there was no reason to support relocatable or source library copies between different device types.
IBM addressed this problem by creating a single tape DOS/360 26.2 2314 distribution that restored to 2314 volumes. That doesn't help us because we don't have that distribution.
While the CORGZ developers did not develop conversion code, someone (it's not clear who) developed CONV2314, a utility that builds a small 2314 system residence volume from a working 2311 system residence, converting the core image block size in the process. The utility copies only the core image library, but that's enough. DOS/360 has utilities to transfer source and relocatable modules across device types, and you'll see them soon.
And while CONV2314 worked well enough and could certainly be used to build a working DOS 26.2 system, I decided to have some fun and transformed it into CVT11RES, a program that creates a complete system residence on 2314 using the core image and relocatable libraries on RES11A and the source statement library on RES11B.
Read about The Starter Systems you are building by following this procedure.