---

The IBM RAMAC 350 was the world's first disk drive storage device. Although primitive by today's standards, it was a game changer. The two most common storage media at the time—punched cards and magnetic tape—were both sequential. To find an item in storage, you needed to read through all the preceding cards in the stack, or you needed to read over all the preceding tape on the tape drive. The RAMAC 350 allowed you to find any piece of data stored on it in less than a second. In CS50 week 3 terms, the RAMAC 350 began to shift the computing world from sequential search to random access search, from O(n) to O(1).

That may seem hyperbole, at least at the level of coding. Even today we need to search arrays and other data structures, and efficiency can be important. But in the 1960s, the shift in storage approach began a shift in how users interacted with computers. In the sequential world, the common approach was batch processing. Given the size and expense of computers, there would be but one computer, and it would be shared by queuing up jobs and running them sequentially. If you had a payroll to process, you would sort all the relevant cards into order, mount the appropriate magnetic tapes on their drives, and process everything on the computer in sequence. Employee by employee, the computer would print out checks and either punch cards or record on tape the information needed for taxes, business records and the like. After that job was finished, the computer could be used for another batch job, perhaps updating inventory or a sales report. It wasn't until later in the 1960s that computers could be used by multiple users simultaneously running their own programs.

The RAMAC 350 was not a computer; it was a storage device, often sold with the IBM 305, an early vacuum tube computer. However, the RAMAC itself was afforded a degree of control using plug boards which were "programmed" in a limited sense by running jumper wires between sockets. These plug boards were part of punched card technology and had been used for many years to control card punches, card sorters, and card-based accounting machines.

---

The ALWAC III-E

The ALWAC III-E was usually found in universities and research facilities. It was one of a number of early stored-program computers that were replacing punched card machines, machines that could be "programmed" only in a limited sense using plug boards. While the ALWAC III-E usually lacked the input/output capabilities of commercial machines, it emphasized computational sophistication and speed. It could only be programmed using its own machine code, and thus required a fair knowledge of how the machine worked, how data was stored, how to work with hexadecimal numbers, and so on. Here is an example from one of the several manuals that came with the machine, giving a general idea of how the code worked.

The programming process would start out, as it still does, with a definition of the problem and an approach to it, the algorithm. Then, unless it was an extremely simple solution, would come the flowchart, a diagram showing the logic of the program: decision points, conditional branches, loops and loop bounds, program flow, etc. The flowchart would be translated into a kind of symbolic representation of machine code that would include numeric or alphabetic instruction codes mixed with symbolic representations of storage locations, essentially variable names. Then that semi-symbolic code would be rendered into numerical machine instructions and hard-coded addresses. At the same time, the programmer would be attempting to maximize limited storage by reusing memory locations when possible and to optimize speed and efficiency by the deft use of arithmetic registers and instruction packing tricks. Virtually every computer sold came with its own preprinted forms for this step. The forms would reflect the word length for the computer (32 bits, or four bytes, for the ALWAC III-E) as well as how words were subdivided into instruction codes, addresses, and data storage.

---

The IBM 7094

The IBM 7094 is a prime example of computing's days of "Big Iron," large mainframes that weighed tons and occupied large air-conditioned rooms. The 7094 provided the computing power for NASA's Mercury and Gemini missions and for the beginning stages of the Apollo program. The U.S. Air Force used it for its Early Warning System into the 1980s. It was the platform for the first time-sharing system, developed by MIT, which allowed multiple users to run programs on a mainframe simultaneously. And it was the first computer to sing, providing a distinctly robotic version of "Daisy Bell" which was the inspiration for the scene in Stanley Kubrick's 2001: A Space Odyssey where the HAL 9000 sings "Daisy Bell" as it gradually devolves into a non-threatening simpleton. Coincidentally, an IBM 7090, a slightly less powerful version of the 7094 provided background and a telling plot point in Kubrick's earlier Dr. Strangelove. The 7094 also makes an appearance in the 2016 film about NASA's human computers, Hidden Figures.

The 7094 was one of a new generation of computers that did not require you to know machine code to use it. It came with an assembler, a COBOL compiler (for business oriented programming), and a FORTRAN compiler (for scientific and engineering programming). The 7094 was large and expensive, and thus became the queen bee and central focus of a complex of auxiliary machines. In a university environment, there would usually be a separate room with several card punches, perhaps some verifiers (used to double-check the punched cards), perhaps a card sorter and a printer that could provide a printout of the cards for proofing data and code. The 7094 would occupy its own air-conditioned space and usually ran 24/7 attended by a group of technicians and operators. Computational time was expensive (about $15 per minute in 2024 dollars), too expensive to waste waiting on slower input and output machinery. So the 7094 was usually accompanied by an IBM 1401, a smaller computer that would transfer information from cards onto faster magnetic tape, queuing up a series of jobs. The tape would be transferred to the 7094, which would process the jobs and send output back to tape. The output tape would then be used by the 1401 to create printed or punched card output.

If you were a student, there would be a "job desk" where you would submit your rubber-banded card stack to be processed. Usually within 24 hours you would get your cards and any printed output back. (Sometimes, by cleverly scheduling when you turned in your cards, say around midnight or 1 a.m., you might be able to get in two runs in a day.) If you were submitting a FORTRAN program for its first run, you could count on getting back a compiler printout full of syntax errors, some of which were real and some which were simply the result of an earlier error cascading through the code. You would fix those problems and make another run, and possibly another, until the program finally ran. Then would come addressing any logic errors and more runs. Sometimes your code might produce an infinite loop, which would earn you a stern look from the computer operator because the only way to detect an infinite loop was for the operator to notice reduced input/output activity or the console lights flickering in a repeating pattern. The only defensive programming lay in the operating system's loading all memory with STR machine code instructions before your program was loaded. Thus any memory not occupied by code or data would contain an STR code: store location and trap. If the computer encountered an STR as an operation, it would go to the second storage location in computer memory, where it would find a routine that made note of the offending location in your program, ended the job, and went on to the next job in the queue. You would get back a printout telling you your program had jumped bounds somewhere and it was up to you to figure out where. The only debugging tools available to you were a computer memory map and liberal use of the print statement.