2.3 Disks

only for RuBoard - do not distribute or recompile

Disks are called direct access storage devices (DASD). Although they can store sequential data just like tape, their claim to fame has always been direct access.

Records can be written anywhere on a disk and can be accessed directly from their disk location. There s no need to read hundreds or thousands of preceding data blocks. That means disk access is fast.

By the way, mainframe manufacturers experimented with drums and data cells as direct access storage methodologies, but they never gained any acceptance to speak of.

Disks drives weren t cheap, and a small mainframe shop might have four drives, each the size of a washing machine. By contrast, the shop might have eight tape drives. The disk drives were too expensive to hold data permanently, so the disk platters were mounted in removable, interchangeable disk packs . These looked a lot like blue plastic garbage can lids. Even though capacity was limited, access to the data was much faster because of the direct access method of data retrieval.

There were two things that governed DASD access speed:

The speed of rotation of the disks (referred to as latency)
The speed of movement of the access arms for the read/write heads (referred to as seek time)

The faster these two speeds, the faster data could be retrieved from a disk. For a while this became a static and accepted speed. No one was working on making these two speeds any faster. (Well, IBM 3330 drives were replaced with 3340s and 3344s, but we no longer have the slightest memory of what improvements these numbers represent.) And in a world of batch processing and highly segregated applications, this setup worked pretty well.

However, because databases began to grow larger and larger, the demand for more and faster storage devices grew. Interactive computing with terminals became the norm, and batch processing began to go the way of the dodo, the passenger pigeon , and the keypunch supervisor.

At the same time, computers were coming down in size and the large mainframe computer wasn t the only choice any longer. Small and midrange computer systems ( minicomputers ) were becoming more prolific. The smaller computers were also becoming just as fast as the mainframes.

The great-great-grandfather of the server may have been IBM s 3790. This mid-1970s machine ”the size of a deepfreeze ”not only had a local database, but could actually transmit a copy of daily transaction data to a central site to keep a centralized database current. The cabinet contained exactly one large, permanent, vertically hung disk platter (about 30 in diameter), offering the immense storage capacity of 10 MB. Optionally, you could build it out to 20 MB or 30 MB by hanging additional platters.

In the 1980s the Small Computer System Interface (SCSI) protocol and connectivity was developed and became very popular. It gave the smaller-than-mainframe computers the ability to attach larger numbers of storage peripherals. This in turn allowed the smaller computers to maintain larger databases.

Technology moved rapidly and the peripherals themselves got smaller. These new smaller devices ”tape and disk drives ”could operate just as fast as their larger predecessors.

For example, the speed of the rotation of the disk in a disk drive increased. The speed of the access arms for the read/write heads also increased. And with both of these speeds increasing, that meant that the speed of data access increased.

The peripherals were just as fast and as reliable on the smaller computers as on the mainframes. And as these smaller computers became more popular, they were being used more and more for database applications and other immediate data access.

At this time, more and more people needed access to the data in real time. Real-time data is data that is accessed and updated or changed immediately, right now. For example, airline reservations and ticketing is a real-time application. There are only so many seats on an airplane; therefore you can sell only that many tickets. Reservation agents need to see immediately how many seats are available to determine how many tickets can be sold.

In our example (Figure 2-5), the airline reservation ticket agent might need access to more than one airline s database. So the agent could be networked in to the different airlines computers, allowing access to that airline s ticketing information held in the database for that particular airline. This is where networking began to evolve .

Figure 2-5. Real-Time Access

only for RuBoard - do not distribute or recompile