Early-to-mid 1960s. The Data Cell was IBM's first direct-access mass storage device. It was designed by IBM's Alan F. Shugart, who also designed the first modern hard disk drive with air-bearing heads and later went on to found Shugart Associates in 1973 (which pioneered the floppy diskette) and Seagate Technology in 1979. (Contrary to the rumor that the Data Cell was designed as a thesis project by an MIT engineering student whose object was a storage system using every known technology... hydraulics, pneumatics, magnetics, springs, optics, ....) The 2321 housed up to ten removable and interchangeable data cells. Each data cell contained 200 magnetic strips, which were the basic recording media. The total storage capacity was 400 million bytes or 800 million decimal digits. Up to eight 2321s could be attached to the IBM 2841 control unit, allowing an overall capacity of over 3GB. Reportedly the Data Cell required 23 liters of motor oil.
Average access times for selection of a strip range from 175 to 600 milliseconds; average rotational delay one a strip is on the drum is 25 milliseconds; access time to another cylinder averages 95 milliseconds.
A Data Cell cartridge (foreground); the Data Cell cartridge carousel (background). Columbia's Data Cell was retired after relatively brief service, due to dependability problems; the weak point was reinsertion of the tape strip into its clip in the Data Cell cartridge after use.
Photos: IBM [32].
Illustration of Data Cell, subcell, and strip hierarchy.
Photo: Introduction to IBM Data Processing Systems, IBM Textbook C20-1684, 1968. The following is from Peter Kaiser, who was in the Computer Center's Systems Group during the Data Cell's tenure:
I feel you've given rather short shrift to the description of the 2321 Data Cell drive, which made such a distinct contribution to the ambient noise of the ASP-era machine room. The machine room was noisy, though after working there for a while you'd become used to it, like the ticking of a clock. The waterflow regulator and gauges were swishing, printers would be clacking and hammering, tape drives whirring and clicking, disk drives humming and making head movement sounds, and in the background (literally -- it was at the back of the room) was the distinctive THUM-SLAM-KERCHUNK-WHISH of the data cell as the cells rotated into position and were locked home, and a magnetic strip was selected and flew around the read-write drum. All of this noise contributes to one of my most cherished memories.One day I was in the machine room when all this noise suddenly stopped except for the sound of a 1403 printer spewing fanfold paper at high speed (remember the 1403 command "high-speed slew"?). I was sure the runaway printer had something to do with the sudden silence, and the usual thing to do with runaway printers was to stop them with the red button, which I tried to do; but the printer didn't stop, and I had to power it off. The system didn't come to life after that, however, and the silence remained total. We tried to do a warm restart, but that didn't work, and finally we had to do a cold restart, losing all the queued jobs; we weren't even able to determine which jobs had been lost. The ultimate diagnosis was that several things had happened with just the timing to cause this:
- An application program -- probably written in Fortran -- had spooled a line that caused the system to issue that printer the command "Skip to channel 12", which caused the printer to slew paper until it would sense a hole punched in channel 12 of the printer control tape.
- The system had serviced all device interrupts and was waiting in a tight loop on the only one remaining, which happened to be the one from the printer indicating it had fulfilled the command to skip to channel 12.
- However, the printer control tape in that printer HAD NO HOLE PUNCHED in channel 12, so that interrupt could never be serviced.
- Since servicing interrupts was the highest priority action for the system, and since that interrupt could never happen, the system could do nothing.
Voila: a frozen system. Meetings were called as the center's high command tried to decide what to do about the bug, but they never came to any conclusion. As I recall, IBM acknowledged the bug but said that since it was so rare, they weren't going to fix it. More meetings. In the meantime I solved the particular problem (yes, this is a pat on my own back): I went to the operators' office and borrowed the master copy of every different printer control tape, and made sure that each of them had at least one punch in every channel. I replaced all the old tapes with the new ones.
But what I remember clearest is the sudden silence, not even the data cell, except for the swish of paper leaping from the printer.