Ken Olsen’s VAX computer, and me

Following the death this week of Ken Olsen, founder of Digital Equipment Corp (DEC), here’s a personal look back at his creations (the PDP and VAX computers) and their impact on the computing scene.

The PDP-8 and PDP-11 were primarily engineers’ and scientists’ machines used in laboratories and in research environments. But with the VAX (Virtual Address eXtension) minicomputer, DEC created a general purpose machine which soon developed its way out of the lab and into the enterprise.

My first encounter with the VAX was on a brief study tour of US universities in the late 1970s, when I myself was working in University computing in London. Our US counterparts, of course, charged for their services and there were two models. A significant per-job charge could be allied to a small CPU rate, favouring large jobs. In this case, Departments with small-job workloads were buying their own VAXs to run this stuff. A small job charge with a large CPU rate was more friendly to small jobs: and guess what? The large jobs went to a departmental VAX. And it usually was a VAX. And the charging model had to adapt to the workload, so it got skewed even further in the same direction … It was relevant to us in the UK, because although we didn’t charge real money we did allocate resources to users and we did charge usage against these non-financial “budgets”.

When I moved into enterprise IT, with BP in the early 1980s, the VAX was just emerging from the scientists’ patch into the more general light of day. We ran databases. We developed a string of applications – mostly in Fortran. We supported the specific activities of our Division, though not yet the enterprise applications such as finance and HR: that came later.

And the range of machines made it possible to put larger machines in the centre, smaller ones in the overseas and outlying offices. You could be well assured that software developed on one would run on another – though I did get caught out on an overseas installation once, when the machine that “owned” the magnetic tape drive wasn’t the one intended to host the software on the tape I’d brought with me. And more important than portability of software was the portability of people that it facilitated. We could take a rig engineer or geophysicist from the Middle East, move them to a North Sea base, and they would be immediately in a familiar IT environment.

The VAX taught us a lot.

With networking came enterprise facilities such as shared information, online chat, and email: things we take for granted now (and Lotus Notes, which had such an enormous influence, was itself strongly influenced by these VAX applications). We could run programs, or access data, on remote machines. And, of course, we had terminal access. This was something I’d been well used to in the pioneering University centre I worked for, but which was by no means commonplace: cards and lineprinters still ruled, in many places.

Clustering, particularly, came in as a major step forward: the ability to share workload among a group of CPUs. But the software vendors scuppered it with per-CPU licensing rather than per-user: we had to restrict some software to specific machines in a cluster, which rather missed the point! Licensing lags behind developments in technology architectures, now as then.

Third: we had programmable terminals, so we could set up on-screen forms for a more friendly user interface (the VT100 and its successors). No open standards here, of course; highly proprietary.

And fourth, perhaps most important: we made the transition from a small specialist unit to an enterprise IT service running a general purpose workload. We changed from being a small group of close colleagues to a more structured, more formally managed function. We adopted standards and defined architectures. We created something approaching a data management strategy. So we were educated, fairly painlessly, in what was needed for the different scale of operation.

And the VAX coped with it. It ran scientific and enterprise workloads on the same machines. In VAX/VMS it had a good general purpose job control language which meant that you could offer users a largely protected environment for an application: properly done, there was relatively little that needed to be left around after the job had run (logical names, peripheral assignments and so on). Though not all my colleagues were as careful; I came to realise that I’d learnt many lessons the hard way in a University service where almost anything might legitimately be run on the machine.

In the end, though, VAX became a victim of its own success. It was so easy to extend the installation, particularly when networking and clustering arrived, that the senior executive would cry “Not another VAX ??” as the latest purchase request was tabled. In the end there were so many machines in so many offices, in and out of machine rooms, that the spend was out of control and the estate became unmanageable. So a lot of the local machines were withdrawn. Facilities were consolidated into a small number of larger centres, accessed over the increasingly capable DECnet. Then, of course, it was easy to ditch the lot and instal a different architecture. So began the decline.

Kenneth Harry Olsen, 20 February 1926 – 6 February 2011

• Ken Olsen obituary, Guardian, 9 Feb 2011
• Ken Olsen, Wikipedia (checked 10 Feb 2011)
• Ken Olsen, cofounder of Digital passes 2/6/2011, HP blog hum, 8 Feb 2011, with links
• PDP, VAX and other historical records from the William Bader museum website

For other links and information, use your favourinte search engine!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s