Cafeteria Style Computing

The Red Room, previously in the Mathematics and Computing building, was surrounded by lecture and study halls. The room itself could not be accessed by students, giving it a ‘temple’ like existence, housing computer operating priests. The Red Room existed to provide students and staff at the university with the chance to work with computers and learn how to program. Although, with the influx of student programs, the standard IBM compilers were unable to keep up with the amount of computing jobs demanded each day. 

In 1967 Waterloo installed the IBM System/360 75 to increase the job capacity for education, research, and University administration. At the time the System/360 75 was the most powerful computer in Canada and was bought under the pretense of being ‘furniture’ to subsidize the cost.  WATFOR, originally written for the IBM 7040, was re-written for the System/360 75.  Called WATFOR 360 and, later, WATFIV this was now the compiler used for Fortran programs.

Currently the IBM System/360 75 Operator Panel exists in the Computer Museum. 

The solution to the job-handling problem, was a dedicated terminal system. The system was enacted in a cafeteria-style service where students would line up to input their codes and wait for the output from compilers in the Red Room. 

The System/360 75 memory was linked to an express terminal, consisting of a 1000 punch cards per minute reader and a 1100 line per minute printer. In addition to the WATFOR and WATFIV compilers, the system could process jobs at 20,000 program statements per minute. The Computing Centre was able to process around 5000 to 7000 jobs per day with the Cafeteria Style Computing method.  

Students had access to systems, like the System/360 75, that could compile, read, and interpret their work in seconds. A student would begin a job by submitting their Fortran source code on a deck of punch cards. A standard Fortran compiler, would process the source code line by line, translating it into a machine-readable object code file. The object code and additional software would be combined through a linker, a system program that combines many files into an executable file. Finally, with this file made of the data from the original source deck, the system would execute the program. Once finished, the computer would continue to the next job, an error in code causing the job to end immediately.  

A former Red Room operator provided a description of how WATFOR/WATFIV worked in contrast:
This is a description of how the standard IBM compilers worked, using three distinct steps (compile, link, execute), and storing the intermediate files on disk. Once the executable file was produced, it could be run as often as required without having to repeat the compile and link steps. This was exactly what was needed in a business environment where a production program would be run many times without changes. Student programs, on the other hand, involved several iterations of compile, debug and execute, but once the program worked it would almost never be run again. This is exactly the opposite of what the standard compile/link/execute paradigm was designed to handle. WATFOR and WATFIV leveraged the fact that student programs would only be run once, and combined all three steps into one, thus omitting the intermediate disk files altogether. When a source program was read from cards, the compiler would create the executable code directly in memory, and if no compile time errors were detected it would be immediately executed. Once a program finished running the executable code in memory was simply discarded. At this point the compiler would immediately loop back to process the next program. With the standard three step process, each program (compiler, linker, executable) would be brought into memory one at a time to perform its part of the processing. If you had two Fortran programs to compile and execute, after the first program was done, all three steps had to be repeated for the second. WATFOR and WATFIV obtained their speed in two ways. First the "load and go" methodology (compile the source code directly to executable code in memory) eliminated the overhead of the three distinct steps. Second, once the compiler had finished processing the first program, it would simply branch back to the beginning to read and execute the next program. In this way the time to read the compiler into memory was eliminated for the second and subsequent programs.