The Honeywell Series 60 Level 62, and its successor, the Honeywell Bull DPS4, certainly used variable-length sectors. It is worthwhile pointing out that these products were designed as IBM System/360 and System/3 knock-outs.
The disk drives themselves did not care what size the sectors were, and you could create sectors of various sizes on a track, or you could create a single sector with a size up to the maximum capacity of the track. This was (approximately) 7kB for Level 62 disk drives, and 19kB for DPS4 drives. However, the operating systems (on which I worked) only allowed sectors of the same size on each track.
The disk volumes were organised using the Volume Table of Contents (VTOC) architecture. The first cylinder of each volume contained a single directory (the VTOC) that described all of the files on the volume. This severely limited the number of files that any disk volume could contain, but in practice, this wasn't a serious problem due to the limited capacity of the disk drives and the availability of "queued" files (libraries) to store program files.
The file types available to customers using high-level languages were as follows:
- Relative (random access)
- Indexed (ISAM)
All of these file types used fixed-length records (and blocks).
File types also available to system programmers using Assembler were:
- Queued Linked (chained blocks containing variable-length records)
- Queued Partitioned (contiguous blocks containing fixed-length records)
These queued files were used to store source code and object code, and had their own internal directories that could be of any size. System utilities were provided to allow users to manipulate these files.
Why use VTOCs (and queued files), rather than hierarchical directories? The main reason was that efficient algorithms for balancing the b-trees used in hierarchical directories were not known at the time that the systems were designed. Although inserting entries could be done efficiently, deleting entries and rebalancing the b-tree could not. When efficient algorithms were developed, manufacturers quickly switched to hierarchical directories. UNIX is, perhaps, the operating system that did more than any other to introduce hierarchical directories to users and programmers.
The actual sectors on the disks were organised on the count/key/data principle. Each field (count, key, or data) was effectively a mini-sector with its own inter-block gap and synchronisation bytes.
The count field contained the address of a block in cylinder/track/sector format. It allowed the controller firmware to access data by physical location, and to verify that the correct cylinder and track was being accessed.
The key field (if present) contained searchable data that could be used by the controller firmware to locate a particular sector on a track without needing to know the physical address of the sector. It was only used on tracks containing indexes and directories. Searches could be multi-track, with the controller firmware performing automatic track switching. This meant that an entire cylinder could be searched using a single command.
The data field contained the actual data of each sector. User programs could only access data fields, whilst system programs could also access count and key fields using specialised channel programs. The data fields were referred to as blocks by programmers.
On IBM systems, the key field was used to record the size of the data field, and this system is still used today on a lot of computer hardware, including floppy disks.
Why was the key field used to contain index keys rather than sector sizes? In reality, there was no good reason. Although allowing disk controller firmware to search for index and directory entries seemed like a good idea, in practice it was highly inefficient since the disk controller remained in use throughout the entire I/O operation, and other I/O commands had to wait for the current command to finish before they could be started. This meant that data transfers could not take place while searches were being executed. This was bad news if you made heavy use of indexed files.
Why switch to fixed-length sectors?
The main problem with variable-length sectors is that it makes it very difficult to predict when required sectors would pass under the read-write heads. If the controller can predict when this will happen, it can disconnect the disk drive and send a command to another disk connected to it. When the original disk locates the required sector, it sends a reconnect request to the controller so that data transfer can occur. If the controller is busy, the disk must wait for another revolution and issue the reconnect request again.
On large mainframe systems, it was common to connect disk drives to more than one controller. When the disk drive issued a reconnect request, if one controller was busy, another controller could service the reconnect and perform the data transfer.
Using the key field to perform sector searches was highly inefficient since the controller had to remain connected to disk drive to perform the search. Controllers performed the searches since disk drives of the time did not have enough intelligence to do this.
Using the key field to store the length of sectors allowed tracks to contain sectors of different sizes, but this caused other inefficiencies as already described. Also, it made it very difficult to calculate which cylinder and track a desired sector was located on without using a higher-level index, which itself would need to be accessed by the operating system for each physical I/O operation.
The count/key/data system allowed operating systems to off-load a lot of processing to the disk controllers, and this was very useful when CPUs were rather slow (the Level 62 and DPS4's speeds were measured in kilo-operations per second). With the advent of faster processors, it made more sense to abandon variable-length sectors and allow the CPU to perform all the necessary calculations. The disk controllers could also be made less intelligent, and this helped with integrating device electronics with the actual disk drives.
Finally, when drive capacities (and track capacities) became large enough to make zoning a good idea (storing more data on outer tracks), the use of variable-length sectors became infeasible, since it would be almost impossible to calculate which zone any sector was in. However, it made little difference since variable-length sectors had already fallen out of favour.
The end-result of this convoluted process is the Integrated Device Electronics (IDE) drives that we all know and love today.
Honeywell Series 60 Level 62
Working from the bottom in a clockwise direction, we have:
Three disk drives with removable 30MB disk packs (and operator). The drives were top-loading and had a glass window so that you could see the read/write heads going in and out. Very nice!
The central processing unit. This contained the CPU, memory and all peripheral controllers.
The operator console. This used a 30cps TermiNet band printer. A data cassette unit was also provided, but this is not visible.
A 600lpm drum printer. Faster printers were available.
An 80-column card punch/interpreter.
An 80-column card reader.
Other peripherals were available, such as half-inch magnetic tape, paper tape, 96-column card reader and 96-colum multi-function unit. Lower capacity disk drives were also available.
Honeywell Bull DPS4
Working from left to right (foreground), we have:
600lpm band printer.
Two disk drives with 80MB disk packs.
Central processing unit with integral 8-inch floppy-disk drive.
Operator console (120cps dot-matrix printer and keyboard).
Other peripherals were available, such as half-inch magnetic tape, 80-column table-top card reader, and 300MB disk drives. The older type of disk drive could be connected for data-transfer purposes.
FEB-patrimoine: From GCOS 62 to GCOS 4
Wikipedia: Volume Table of Contents
Wikipedia: Count Key Data
The Wikipedia articles relate to IBM products. However, they are broadly applicable to the Honeywell products described here.
The FEB-patrimoine article contains minor inaccuracies, possibly because it is based on planning documents rather than engineering documents.