According to my limited experience with IBM clone mainframes, and as far as I can remember, at least in one OS the permanent storage disk space was allocated to users (and the scratch space — to processes) by cylinder range, and the process was allowed to access the allocated cylinder range almost as if it was a section of an IBM tape, i. e. to write blocks of arbitrary sizes, limited only by the track capacity.

I'm not sure if it was the OS which decided how many blocks would fit on one track, or it was the user's responsibility to specify in the JCL Data Definition statement, it's hard to tell from the example.

How widespread was that practice among the mainframe manufacturers? When was it abandoned?


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.

Volume format

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:

  • Sequential
  • 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.

Sector format

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

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

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.

  • UNIX had hierarchical file systems with linear searches within directories for a very long time with little problems. I wonder when the practice of allowing arbitrarily-sized blocks was abandoned? When removable disk packs went out of fashion, or earlier? – Leo B. Mar 16 '17 at 7:23
  • @LeoB. The use of zoning, where outer tracks hold more data than inner tracks probably influenced this move. It would be very difficult to calculate sector locations with variable-length sectors. I'll try to update my answer. I think that it is going to need several revisions. I'll have a look at my copy of Deital (Operating Systems) and see what he says. – Mick Mar 16 '17 at 7:34
  • Having sectors which change during the lifetime of a volume could make things massively complicated. On the other hand, I could see some benefits to having a drive which includes a mixture of large and small sectors and uses small sectors primarily to hold the last portions of files, in cases where they would waste more than a small sector's worth of space if written using a large sector. A system which used e.g. a 50/50 mix of 4K and 1K sectors would need to keep track of fewer allocation units than one which used exclusively 2K sectors, but would likely waste... – supercat Mar 16 '17 at 16:33
  • ...a smaller amount of storage in partially-filled sectors. Further, the amount of data that could be stored on a track using two different sector sizes might be greater than the amount that could be stored using either size alone (e.g. a track might be able to hold 10K of data as 4Kx2 + 1Kx2, using 4 sector headers, even if it couldn't hold 10K of data as 2Kx8, using 5 sector headers). – supercat Mar 16 '17 at 16:39
  • 1
    @supercat I have yet to hear about a system that used a mix of power-of-2 (in bytes or words) block sizes to maximize the capacity of a track. – Leo B. Mar 16 '17 at 17:55

Don't know how widespread it was - but IBM introduced variable record size on hard discs in 1961 and didn't create hard disks with fixed block size until 1979. (Dates from Wikipedia, see below.)

Lots of their software was written to make use of this optimally - in fact, it was the design point around which IBM's ISAM - Indexed Sequential Access Mode - was developed, and that was the primary database access mechanism of the time. (In fact, you may as well call it the primary database of the time, not simply an access method.)


Fixed Block vs Variable Record size on Wikipedia

IBM Indexed Sequential Access Mode on Wikipedia

Your Answer

