TL;DR:
No, these were normal cylinders and tracks. They were simply reserved to hold alternate tracks. They were assigned during formatting by control of the OS (or better the formatting utility). Reason was to guarantee that every (successful formatted) drive always contains 2000 usable tracks.
During normal operation of a formatted disk the replacement process is handled by the microprogrammed 2841 SBU in real time. Formatting and Initialisation of a disk is entirely defined by host software.
CKD and other oddities
Understanding the details about how DASD drives in general and the 2841 SCU (Storage Control Unit) with its IBM 2311 DSD (Disk Storage Drive) (*1)in particular work requires taking a step back and forget about today's canon of tracks and sectors. Best way to imagine it is a cluster of 2000 tape drives plus 30 spare drive, each having a short tape mounted. On a primitive level each of these 'tapes' is a single file.
Weird, isn't it?
Today we're only looking at disks with almost fixed structure or solid state drives with fixed structure. But IBM's DSAD design was intended to unify such different storage devices as
The only common feature here is really a track, so a track is what was managed on device and controller level. The resulting idea was variable length, high level data format called Count Key Data.
But lets first look at the hardware:
The 2311 Drive
They physical 2311 drive is an improved 1311. The roughly 5-fold in capacity was gained by halving track width (doubling the number of cylinders from 100 to 200) and increasing the write clock, which brought the storage up from ~1.5 Million Bytes (8-bit) to more than 7. All while using the same IBM 1316 Disk Pack (*2)
The 2841 Controller
The 2841 was a stand alone unit able to control up to eight drives and two host channels, allowing either redundant operation on a single host or concurrent use by two mainframes. It was itself a mico-programmed unit, able to handle rather high level tasks, like searching for a certain record or even index key, relieving the host by reducing otherwise complex operations to very basic I/O commands. The 2841 is the original base for DASD with CKD storage.
Count Key Data (CKD)
Count Key Data was IBM's answer to unify three very different methods of data storage (Disk, Drum, Cells) into a single interface, while at the same time offloading basic tasks to hardware.
To understand this it's helpful to keep in mind that disks where incredible fast compared to what a CPU could do. At the same time, data transfer did put much load on memory, as data needed temporary storage to be searched. The solution to this was to enabling search while reading out on the disk. All controlled by the way channel command could be chained to form a meta program. Detail (*3) are past the topic of this question so let's focus on the track replacement part. This is based on the format structure of a track. A structure independent of it's media, present on all three types of drives.
CKD Structure
The name CKD is simply the sequence of blocks that build a record within a track (file), a Count Area (block), an optional Key Area and a Data Area. So let's look inside a Track.
A Track consists of
- an Index Point, marking the start of a track
- a Gap and
- and Track Data
Track Data in turn is build from
- the Home Address
- a Track Descriptor Record (R0)
- and zero or more Data Records (R1..Rn)
The Home Address is where all starts. It holds
- a Flag Byte holding only two bits noting
- Track being operational or not
- Track being the original one or an alternative (reassigned) one
- its address, noted as
- and a CRC
For further understanding it's important to note that the home address could only be written by a special, dedicated I/O command word, usually only issued by the formatting utility (or real tricky user software :)). Thus the decision if a track is original or alternate always comes from the mainframe software, not the 2841 controller.
The home address is followed (*5) by the Records stored in this track. Each record consists of
- a Count Area (block)
- an optional Key Area
- a Data Area
For the track replacement magic only the very first record, R0 or Track Description Record, is relevant and thereof only content of the Count Area, thus I'll spare going into further details past this.
The Count Area is an 11 byte field with various markings and information containing
- a Flag Byte which is a copy of the flag byte of the Home Address.
- a repetition of the track address as
- a Record Number of '00' identifying the record as R0,
- length of a following Key Area (0..255),
- length of a following Data Area (0..64 Ki),
- and a CRC
The host view of this is an 8 byte field as the Flag Byte and CRC are only visible to the 2841. The flag byte is a direct copy taken from the Home Address, while CRC is calculated (and checked) local.
We'll spare the remaining records, as all replacement happens on the level of Home Address and the Count Area of R0.
Replacement Indication
Interesting for track replacement is the copied Flag Byte and the Track Address. Tracks that got replace are marked by a bit. When set, the track address contains the location of the spare track to be used.
Replacement Interpretation
When the 2841 executes a seek command to position at a certain track, it checks the Home Address to verify positioning (*6). If correct, it checks the Flag Byte if the track has been relocated. If yes, it continues to read the R0 record, extracts cylinder and head and restarts positioning to the new address.
Here the position will be again checked against the Home Address, holding the 'real' track number. In contrast, all following records, including R0, will hold the Track Address of the original track. I.E. except for the Home address, and the repeated Flag byte, all track content, including addresses will look exactly like it would be without being relocated.
This makes the relocation essentially invisible to all host (normal) host software. It can only be detected by issuing a dedicated _Read Home Address command (*7).
Replacement Initialisation
While the interpretation of reassignment is done by the 2841 SCU, invisible to all host software, its instalment is done purely by host software. When a defective track is detected during formatting, a replacement track is selected and checked for not being defective.
If one is found to be usable, it's written with its genuine Home Address but with a Flag Byte marking it as a replacement track and an R0 record holding the track address. Only if this is successful the replaced track is (re)written with a Flag Byte noting it as replaced and a R0 record with the address of the assigned replacement track is written.
If
- the replacement track can not be formatted, and
- no further replacement track is available (all used up), or
- the original track can not be overwritten with the needed redirection,
then the whole disk will be rejected.
All of this is done under direct host software control. The SBU does neither interfere nor act on its own.
BUT WHY?
There are eventually two questions:
Why Fixed to 200 Cylinders?
Why not using all 203 for storage and just mark defective tracks. After all, in most cases it would make a bit more space available, as rarely all 30 reserve tracks are needed. In addition even 'lower' quality disk would be still usable, wouldn't they?
The answer may be manyfold:
First of all, it's important to keep in mind that the system /360 is designed to replace all prior IBM equipment. This includes foremost all accounting machinery, as that's were the money was - and still is. In production nothing is more important than reliability. NOTHING. Guaranteeing that there are always 2000 tracks available does straighten provision planing.
Second, and that's equally important, those machines were slow in comparison with disk drives (*8) and memory was scarce. Any architecture that can avoid reading intermediate data before reading the needed ones will speed up execution more than anything else. There is no room for highly abstract systems that do need much management which leads directly to the third point here:
Last there is low level user access. These machines had to run with no or just minimal OS layers. There was neither room (memory) nor power (CPU speed) to handle what we know today(*9). Application software had to be as close to hardware as possible, which meant in turn the functions we see today as software had to be done in hardware (*10)
Still, Why Not Sectors?
Beside the fact that it wasn't a sector based file system? Beside the fact, that the file system offered high level function like indexed search (modern buzzword: relational access, associative memory) without any host software?
Well, there is still performance and resources. Remapping single sectors across a disk slows down access a lot. In real world application, reads are seldom single sector random access, but more often sequential reads. Meaning that the sector before a faulty one, it's replacement and the following are likely read together. There are essentially two remapping strategies:
Remapping into an overflow region
Here every defective sector is replaced by one of an overflow region, maybe at the outer end. Whenever a defective sector is accessed, the head(s) need to be moved all across the disk to access it's replacement and move back again. I can't think of any way better to slow down disk access (*11).
While track remapping also means moving to a new track, there is no need to move back - at least not for the whole content of that track.
Using a virtual remapping
Here a table of all sectors is kept, assigning logical sector numbers to physical and leaving out inaccessible in turn (*12). A great idea removing all need for head movement, just capacity between head movements gets reduced.
It just carries two major drawbacks: It needs a fixed storage location there this table can be found by the controller (something the track method doesn't need) and, even more important, it needs a huge amount of memory. One word per sector. If a 2311 would have been formatted with 2 KiB sectors, there would have been ~3700 sectors, thus a table of at 12 bits per entry to be held in controller memory. That's ~6 KiB of RAM per drive. That's 48 KiB for 8 drives. All to be stacked within the controller. At a time when 48 KiB was the maximum memory for a Model 30 (base memory was 16 KiB).
Doing it within CPU Memory would slow execution further down and add another software layer, killing performance even further. Similar if that table is not kept in memory but read wehnever needed.
Long story short: What's canon today would bomb the business back then.
The Future (of 1965)
Of course, when the world turned toward fixed sized blocks and storage management based on such simple units, IBM did as well and CKD became for many applications turned in a system much like we know from smaller systems, one based on Cylinder, Head and Sector instead of Track and Record. Already in the 1970s, for many applications, data block and key block turned into a fixed length units, making it work mostly like known in other places, virtualizing parts of the original structure.
By 1980 IBM introduced Fixed-Block Architecture as well on user level with the introduction of 3310/3370 drives.
While DSAD is still integral part for next to everything in zOS, features became emulated on top of fixed size disk structures. By now all (new) disk devices on IBM mainframes are sectorized with the header noting an address and single fixed size data block following.
*1 - For this topic the /360 Model 25 integrated Disk Attachment Control (DAC) can be ignored, as it did for most parts emulate what a channel controller and a 2841 SCU did for the larger models.
*2 - As others have pointed out, this hardware has been used by many other manufacturers (like DEC). After all, the 2311 was the first IBM drive used over a wide variety of machines, making it a prime target for plug compatible manufacturers. But that's only the drive. Format and capacity did vary between different companies.
The 2311 is what made CDC a big name in business. While we now remember CDC mostly for their Cyber machines, building IBM compatible drives, tapes and printers was what brought in the money to fund all their computer development.
*3 - If you thought modern Command Queuing is a marvel, think again, this was already standard for mainframes 55+ years ago. Even better, modern NCQ isn't much past buffering and asynchronous operations, while channel programs allowed to put steps into context and conditional about prior results - like seeking to a certain track, searching for a key, then searching for a sub key or a data item or ship a block and finally read and transfer a series of records, unconditional or according to further selection. All of this done by the controller in hardware and real time, so even complex search orders could be finished in a single disk rotation.
*4 - Both values as 16 Bit, so in theory 4 Gi or tracks could be managed on a single drive. IBM didn't try fall victim to premature saving :))
*5 - The 2841 does insert Gaps between home address and following records as well as between records. More gaps are between elements of a record (C,K,D) are (may be) inserted. Length and position depend on each device type. They are not part of the logical structure as seen by the host system.
*6 - In case of a mismatch the seek is repeated 3 times until a not found is reported.
*7 - Well one could always try to check timing and guess, but that's not really a method for serious operation.
*8 - In some way it's like a decade later with micro processors and main memory. Micro CPUs were so slow, that it (almost) didn't matter if an ISA featured almost no registers on chip (like a 6502), handling all data of chip or one having a comparable lot (like a Z80 or even 68k), able to hold core data on-chip. Effective speed was almost entirely related to memory bandwidth.
*9 - A bit like with the IBM-PC again - although I'd rather put that on too many hobbyist programmers going ahead with preliminary optimizion.
*10 - I always like the irony of time, as after eliminating all 'intelligent' hardware to employ as primitive as possible devices and move everything over to software, we now try very hard to outsource it again - applauding advancements that are still dwarfed by what was done 50+ years ago.
*11 - It can be reduced a bit by spreading out the spare sectors across the whole disk.
*12 - A bit like MS-DOS' FAT structure. Except that's a linked list holding the file sequence as well.
