Computing in the 1970s

The purpose of this page is to paint a picture of what at least one part of the computing world felt like to a typical computer user in the mid-1970s, well after the initial pioneering days, but before the days when access to computers had become commonplace.

Access to an IBM Mainframe, by Post

The Hampshire County Council (HCC) education authority had set up a scheme, around 1972, to run Fortran-IV programs (using WATFOR) submitted by the schools of its area, to be run on its IBM-370 during any slack periods. The teachers collected the hand-written coding forms from their pupils, and posted them off to the centre at Winchester. About a week later, the printouts and listings were returned by post, for distribution back to the pupils. The number of program bugs, and punch-card errors, was generally so high that it would take several weeks to get even the simplest of programs up and running.

Closer Access to the Computer

The IBM-360/65 at University College London, too, was programmed in Fortran-IV under WATFOR. In 1975, the engineering students punched out their own decks of punch cards at one of the numerous IBM punch machines dotted around, in odd corners of the department. The deck, complete with an orange job-control card, was then handed over to the operator behind the desk at the local peripheral station within the department (which was the interface to the mainframe itself on the other side of the college). The operator would add the deck to the queue of jobs to be loaded in the punch-card reader, and the student would go off to get on with other productive work. Later, the student could return to pick up the deck of cards again, and hopefully also the printout from the run itself.

In 1976, the college was investing in visual display units (VDUs), mainly Newbury terminals. Logging in to the Gothenburg University Terminal System (GUTS) with the same user account as had previously been used on the job-control card, the student could type the program into a file, to be stored remotely on hard disk. This could then be submitted electronically to the distant mainframe's batch queue. It was also possible to write script programs in the GUTS job control language. The directory space was completely flat, though, with one space used by the whole college. Choosing unique file names was something that involved some care (either to avoid collisions with other users, or else expressly to engineer it, to give them access to "useful" script programs).

Even from 1975, though, some of us were able to use the PDP-11/10 mini-computers in Department of Computer Science, and these took over, for us, as our almost-personal computers by 1978, for computing, text-processing, and computer mail. Notably, in 1976, rather than spending the evenings watching TV in the hall of residence common room, a group of us would sneak back into the basement of the Computer Science lab (with the lecturer's permission) and power up the PDP11, and play computer games all evening (Lunar Lander, Spacewar, etc).

Life with a GEC-2050 Minicomputer

In 1975, I also had access to a GEC-2050 mini-computer, while I was working and studying with Marconi Space and Defence Systems, in Portsmouth. This was the smaller model of the GEC-4080 from the GEC Computers company. The experience with this machine taught me, amongst other lessons, that computers were not that exotic, and were just as capable of growing to be taken for granted as any other machine.

Firstly, I rarely had any problem in finding the machine free, of an evening after work; I could just wander in, and start using it. Secondly, the machine was powered from a conventional mains plug in an ordinary 13amp mains socket, just like any other mundane bit of electrical equipment. Thirdly, the poor machine had been shoved into what had originally been designed as a largish broom-cupboard.

The next paragraphs describe a typical work session on this computer. The programmer might typically arrive, carrying a teletype paper listing, annotated with the changes to be made, and the punch tape source code of a Fortran-II program that he had already started writing, from the previous session. He would first need to turn the computer on at the conventional mains switch at the socket on the wall, and then at the front-panel on/off switch. Since the magnetic core memory, which is non-volatile memory, would generally still contain the previous user's program, it might first be necessary to load the punched tape called "Minisystem" (which was a small, memory monitor program). This tape, stored in a small cardboard box on a shelf near the computer, would be entered from the left of the tape-reader. The tape-reader was an integral part of the front panel of the computer, and would spill out the tape that it had read, on to the floor, on the right-hand side.

Once read, the Minisystem could be started by flicking the "Run" switch on the front panel. The text editor program could then be called from the teletype keyboard, at the Minisystem's prompt. The programmer's source tape could be loaded into the reader, and while this, too, was being read in, and spilled out all over the floor, the programmer could be busy winding up the Minisystem tape, into a tidy reel again, using a hand-turned winch.

Eventually, once the source tape had finished being read, the text editor program would prompt for a new command, which was the invitation to edit the program. Though having changed little in effect over the decades, editing has changed enormously in feeling: the editor displayed only one line of the program at a time; it had a non-erasing rubout key on the teletype printout; it had very rudimentary search and string-substitute facilities; and the teletype worked at 110 baud (making an enormous clunking and whirring racket as it did so).

At the end of the edit session, the new version of the source program would be ready for output: both a typed listing, and a new punched tape. Whilst the paper-tape punch was doing this, again spilling out its product (albeit not so fast as the reader, and off to the left of the machine) from its front panel mounting, the programmer could be winding up the old version of the source tape, to be kept as a backup. The free end of the new tape, which was still being punched out, could be labelled in pencil with its program name, version number, and date of punching.

Unfortunately, with only 16 KiBytes of core store, the Minisystem and Fortran compiler would not both fit in memory together, so the next stage would be to load the Fortran compiler tape (stored in another cardboard box on the shelf in the computer room). Whilst this was being read in, and spilling out the other side, the newly punched source tape could be torn off from the free end protruding out of the punch, and wound up on the hand winch. It would be loaded into the tape reader once the compiler had finished being read in, and the compiler tape would be wound back into a tidy reel. The first pass of the source tape through the tape reader was generally used just for checking for syntax errors in the program, so the generation of the object tape from the tape punch would be "suppressed". If any errors or warnings were detected, it would be necessary to load the Minisystem tape again, and to run the editor to make the corrections, and to generate a new version of the source tape. Otherwise, the source tape could be wound up again, and loaded back into the tape reader for a second pass. This time, it would be read in, haltingly, whilst the paper tape punch worked flat-out to produce the corresponding object tape (usually two or three times longer in length than the Fortran source tape).

At the end, with two tapes all over the floor, the Minisystem would have to be read back once again, whilst the object and source tapes were being wound up. The linking-loader program could then be called from the keyboard, at the Minisystem's prompt, and the object tape fed through the reader. The linking-loader also required the library tape, containing the Fortran library functions, to be loaded into the reader. Both tapes would eventually need to be wound up, but this tended not to be done immediately, because of the programmer's eagerness at finally being in a position to run the program. The user's program (called "main") could be called at the Minisystem's prompt. Depending on what happened during the program execution, the programmer might need to read the newest source tape back in to the editor program, yet again, ready to go round the software development cycle once more.

So a major part of my memory of programming on the GEC-2050 is one of endlessly winding up paper tapes from their half-tangled mess on the floor. A major challenge became one of seeing how fast one could turn the winch handle. Because the tape was generally being buried under the subsequent one, and because the heap of paper was so scattered, this aim of winding as fast as possible often ended in some sort of disaster: a part of the tape would become creased, tangled, ripped, or completely severed, and the so-called "puncture repair kit" would be fetched, so as to splice the tape, fixing it back together with a black self-adhesive patch, and with the rows of holes repunched, one at a time, by hand.

Another irritation was when the punch ran out of paper tape. Not only did this involve the minor chore of finding and loading the new tape, but of starting the punch job again from the beginning. One minor challenge became to find a different colour tape each time (the choice was usually between pink, pale yellow and white) so that different colour layers of confetti built up in the waste hopper (which, too, needed emptying from time to time).

Constants of computing

Since those days, computer access has become ubiquitous. At first, in the 1980s, every desk ended up with a computer terminal (a computer screen and keyboard) connected to a distant mainframe computer in a central computer room; then, in the 1990s, this was replaced by the networked workstation.

In all of this, computer processing power has increased by a huge number of orders of magnitude, but surprisingly large amounts of the nature of our computing has remained constant. For a start, Parkinson's law has ensured that all those many orders of computer power get used up (much of it squandered in ineffective thrashing activity), so that the user today ends up wasting just as much time, waiting for utility programs to respond, and becoming totally irritated when it occurs at the worst possible moments, as the user back in the 1980s.

One small detail, too, has surprising resonnances with computing dating right back to the 1960s. As a technical writer, I often find myself taking the reviewer's markup of a document (on paper, or on an annotated electronic version), and working through the changes in reverse order, from the end towards the beginning of the document. Even on the other occassions of working through in the forward direction, I often end up making the multiple changes to a given paragraph in reverse order. The reason is that, in this way, it is easier to find the changes as they appear on the marked-up copy, undisturbed in position on the page, by the previously implemented changes. Back in the 1960s, editing of files stored on magnetic tape involved typing in the line number of the line that needed to be changed next, followed by the details of the change to be made; by working from the end of the file towards the beginning meant that earlier line numbers (in the file) were not disturbed by earlier implemented insertions and deletions of lines, later in the file.