The company’s headquarters (certainly as far as software was concerned) was at Addlestone, Surrey, but I was based (I was told at interview) at Stoke Park. Stoke Park House, in Stoke Poges[90], just north of Slough in Buckinghamshire[91], was an old manor house surrounded by parkland, which formed the Stoke Poges Golf Club; the golf club had part of the house (the main bit) and Plessey leased “sealed off” office space at the side and on the top floor and in the basement. The club and clubhouse had been used for the James Bond film “Goldfinger” as the place where they played their golf match, and where Oddjob threw his hat at a film-prop statue. While I was working there, it was used for the UK PGA championship, and during the lunch-hour we would walk round the grounds and watch the golf, all for free!
I was assigned to a small team (four of us in all) working on the operating system for an Air Defence project, which on arrival I discovered to be the new main control centre based at the RAF station West Drayton (just north of Heathrow Airport), where it was adjacent to and shared data with the London Air Traffic Control centre (LATCC). Known as the Linesman project, the idea was to bring all UK military radar control under one roof was of long standing – it’s first design was a reed relay telephone exchange, and I guess that was when Plessey got involved (their Liverpool centre was one of the main UK manufacturers of telephone exchanges, supplying BT); when computers had advanced to valve systems, someone suggested that a computerised system would be sensible, so it was re-designed to use valve computers. We were now on the third major design, using transistorised computers, and someone at the MOD had sensibly realised that after three designs they still did not have a command centre, so perhaps instead of trying to keep up with technology (which advanced faster than the MOD could design and specify systems), perhaps it would be a good idea to actually build something – after all, perhaps some of the practical aspects might only be discovered by trying to actually make it work!
Anyway, having found a house in Farnham Common, only 1½ miles from Stoke Park, and having worked there for a week, we were all moved onto the West Drayton site, and I worked there for several years, travelling along the very busy M4 motorway (or through back-roads if time was on my side).
Operating systems were machine-specific in those days, before MS-DOS or UNIX had emerged to become international, cheap and more-or-less standard. The computers were paper-tape fed, but had “lots” of memory (16 or 24 kilobytes!), and had data highways to communicate with the specialist display or signal feed equipment. A separate off-line facility took our code and compiled it, and stored it; we were not really allowed in – and we got tapes back ready to load and run. The operating system consisted of a scheduler (to enable several programs to run “simultaneously” in the same machine), a set of interface programs (to enable the computers to take data on and off the highways, and thus “talk” to each other), diagnostics (to test if the computer itself was working correctly), and a set of on-line aids (to help the application programmers test their programs). I was generally involved with all parts, but specialised in the last component. My colleagues were Norman Bond[92], Peter West, and Barry Briggs.
It all seemed to go quite well. We got the operating system working in parallel with the application programmers developing their code, and while they found extra needs for on-line aids, I upgraded or modified the code to help them. So when it came to the stage where the whole system was being tested, and the operating system team disbanded, I found myself asked to be a sort of team leader for “support” of the testing programme. System testing, and then acceptance testing, was run in 8-hour shifts, but I needed to be in 2 hours ahead (to find out what changes had happened overnight, and plan the shift), and stay 2-3 hours after (to wrap-up, analyse any problems, and leave instructions for the evening/night shift to fix the software). This lasted for a few months, and was quite a drain on sleep, never mind normal family life; the best thing was that the overtime money was enough for us to afford a new piano (AND a washing machine!).
Two incidents remain firmly in my memory from these days, which were interesting and exciting and very busy. The first was technical – Mike Grimsey was one of the application programmers specialising in secondary radar, and his program was showing signs of a major bug; on ONE of the computers (only), it showed the first aircraft’s secondary radar details, and then refused to do anything else – on the other computer dedicated to this job, it ran fine. He had tried using my tools to find the problem, and failed – could I help him? Well, the first question was, had he run diagnostics on the failing machine – could it be a computer fault? Yes, he had, and there was no problem. So I checked over his program, and started doing instruction-by-instruction checking – after a few goes I saw something I just did not believe; after the first “correct” pass through the program, the program as stored in the computer had changed (so, as Mike said, no wonder it wasn’t working correctly). The most likely explanation was that Mike was somehow writing data to a part of the computer memory that held the program, so I wrote a refinement to the program to track that particular word of memory, only to find that the corruption happened when the program was run the first (correct) time. Long and (shall I say) pointed phone calls to the computer engineers in Liverpool resulted in them saying that yes, theoretically, this could happen, but they’d never seen it. So Barry worked out how to test for the problem, extended his computer diagnostics program, and we ran it in the faulty computer – sure enough, the problem was pinpointed at the memory address we’d seen and one other that no-one had guessed so far. And we found that four of the twelve or so computers had similar problems, unsuspected; so it was a very good thing to have got to the bottom of so quickly – left undetected, they might have had serious consequences.
The other incident was when the systems were being installed. Barry (a different Barry) had written software to keep track of planes on the radar, the idea being that his software would predict where each plane would be “next sweep of the radar” and put a ring around that point. If the planes were following a normal steady track, adjustments from the predicted position would be minor. The idea was that each RAF tracker would track 3-4 planes; the counter on the displays went up to 9, and the software could hold 99 per tracker. Barry had to test the “99” figure, so on his test display he lined up 99 simulated aircraft down the right of the screen, set them moving right-to-left, and started tracking them. What we didn’t know was that the live/sim(ulated) display sign in the main control room, being installed by engineers, was reverse-connected, nor that the Air-Vice-marshal in charge of the project was showing a “horde” (sorry, I don’t know the correct collective noun) of Air marshals[93] round the building; they were in the main control room, and he was explaining that if the Soviets ever invaded, the staff would see the invasion as a series of red hostile tracks approaching the UK from the Soviet Union. “What”, one of them said, “like that?” and pointed to the main screen, which was indicating LIVE and showed an invasion of a hundred hostile planes approaching Europe and headed our way. The Air-Vice-Marshal concerned was about to leap for the phone to call Strike Command, when I (I had been lounging in the doorway between the tracking room and the main control room) thought that perhaps I’d better explain that World War III was not really starting. There was a bit of embarrassment, but after a few moments the visitors all realised that by accident they’d seen a most convincing demonstration of the system capabilities!
Anyway, after all the tests and software fixes, the system was handed over on Christmas Eve. A letter from the Air-Vice-Marshal to Plessey, copied to all staff, was effusive in congratulations; it was the first ever major software project the MOD had had, that was handed over ahead of time (the contract period was Dec 31st so we were a week early) and under budget.
After handover, the system went to maintenance mode; all quirks, oddities and improvements noted in acceptance had been classified as either “fix before handover” or “leave till later”, so following handover we started on the second category, including changes that we in Plessey or the RAF thought of in the light of actual use of the system. I was appointed Software Manager, second in command in the Plessey team, and responsible for all the software in the system. I held what was called “Design Authority”, which meant that my job was to ensure the integrity of the overall design – no changes were to compromise the design, or take away from the value of the operational system. The Plessey team started with 27 programmers, and over two years reduced as the RAF programming team grew their expertise; eventually the RAF took all ongoing responsibility from Plessey, and we all moved on to other projects. During this period, I was used to liasing with the RAF officers, with whom I generally got on pretty well. I was invited to “dine in” on the station, which was an honour – we needed dinner jackets, and it was a formal meal from start to finish, ending with toasts. All in all, an excellent project, technically and in terms of my career.
I did a few “odd jobs” while waiting for the next major project to start – one involved commuting to Richmond, to work on a satellite project for the European Space Agency (International Ultraviolet Explorer, which I saw mentioned in an Astronomy book as having been a long-lived success story), but they were relatively small jobs.
My second major project with Plessey was “Wavell”, named after a former Army General. Someone in the MOD had thought that computer assistance would be as significant a benefit to the front-line troops as a couple of extra tanks (comparable cost!); this was, you can imagine, a revolutionary thought to the Army, and I was told that some very senior Army figures had opposed it tooth and nail, on the premise that computers were incapable of destroying the “enemy”. Our job was to ruggedise[94] computers, fit them in land-rovers, get them to communicate over the Army scrambled radio systems, and write software for decision support for the troops. There were three teams, one for hardware, one for the Application software, and myself in charge of the basic operating system and communications software. The computers were to be DEC PDP11-34’s – in the few years since Linesman, computers were now commercially available. We were to use the RSX-11M operating system, and we hoped to use the new DECnet software for communications.
Unfortunately, I could not get from DEC UK any details of this software, in terms of what it could do this release or next; so it was arranged for two of us to fly to the States, to DEC’s headquarters in Massachusetts, to find out more. This was my first transatlantic flight, and as such quite an eye-opener. On arriving at Boston’s Logan airport, we were to go to a particular counter to be met by someone from DEC – he turned out to be a helicopter pilot, and we were “helicoptered” from Logan to Maynard (my first such flight – wonderful views of the snow-covered countryside, but quite frightening when it turned corners[95]). The meetings were not successful – we saw “marketeers” rather than engineers, but we did ascertain that DECnet “Phase 1” only catered for two computers, being designed to have them connected back-to-back in a lab; also, the connection had to be permanent – the software would not cope with any break in the connection.
Back home, I started my most intense ever period of thinking and research. In the Army, there were a number of computers, only half of which would be in contact at once. The connections were intermittent, poor quality (because the radio masts needed to be concealed) and spasmodic. Could I design software that would administer such a system, dynamically reconfigure itself as computers joined and left the scheme, and transmit data from A to B via other computers C and D? Well, of course I did, working from a blank piece of paper, and using a routing scheme that I called “link state routing”[96]; on paper I had to “prove” the design, before we started to build it, and after some experimenting decided that the model that showed most clearly the problem was a figure-of-eight configuration, where the middle line kept switching in and out. Then I wrote the software, and we tested it – in doing so, I had to call on a DEC support engineer from the UK called George, and between us we spent many hours getting nowhere until I was able to prove to him that I’d found bugs in both DECnet phase 1 and the RSX operating system; listening to him report them to the States was an eye-opener. DEC managed to fix them in a matter of a week or two, and all was well.
The end of my part of the project involved a two-week visit to Blandford Camp to test the “foundation” system; computers in land-rovers, connected to the radio system, and mobile. The encryption devices used to scramble voice communication were massive, weighing a lot. Thankfully, it all worked in a very short space of time, and I spent the fortnight showing the army squaddies how to use it. To test contact and communication, I had written two utilities; one was a one-line-at-a-time message utility, where if you typed the line
HQ1 HOW ARE YOU TODAY?
It would send “HOW ARE YOU TODAY?” to computer HQ1, and the ID of the sending computer and that message would be printed that end; it was all upper-case at that time. The other utility printed out which computers were currently in contact. I need hardly say that the squaddies, hardened men that they were, thought this was phenomenal. They took to it like the proverbial ducks to water, though the messages transmitted (between “friends”) were often of a nature to bar reproduction here or anywhere else. This may have been one of the first forms of rudimentary email! They would drive off in the morning, hide amid the countryside, get as poor reception as they could, and then try communicating – and we did prove the theory (until then only a theory) that due to error detection and retransmission, computers could communicate in radio conditions too poor for human voice. We were staying at an inn near the camp, and the landlord after a day or two realised that he was onto a good thing, and looked after us well – even though we were off early in the day and back late; I remember one day he came in and with fingers to his lips asked if we fancied a bit of pheasant for dinner the next day, as he knew a “source”. We did.
My part in the project was complete, and I decided to leave Plessey[i] and join DEC as an employee; George had no doubt made sure that I would be welcomed. I did hear, a year or two later, that Wavell had gone on to be a most successful project. One of the four British Army divisions was equipped with it, and all four divisions underwent exercises – the Wavell-equipped division completed their exercises significantly faster than the others, and in complete radio silence (no voice traffic); as a result, all the divisions wanted it “now”, and the traditionalists at the Army centre were forced to eat their words.
As a postscript to my days at
Plessey, I have to say that I was involved in two MOD projects, both very
successful, both interesting and involving. Yet anyone not involved, seeing the
articles in the computing and national press, would have got the impression
that none of these projects was either well managed or a success. We were not
allowed to “answer back”, we just had to learn to live with uninformed, snide
press comments and ignore them.
In 2023 Katie and I called in at the Blandford “Royal Signals” museum, which I found interesting – but asked for comments, I mentioned that Wavell was conspicuous by its absence; I was then “pounced on” by their people who had heard about Wavell but had no idea what it was about. Eventually I wrote a brief summary for them … click here to read it … and do an audio interview which will feature in the Museum from 2024 onwards.
Digital Equipment Corporation (DEC)
A number of things struck me, while at Plessey Radar, about DEC as a company. One was how professional their contact, George, was – he was not defensive, he took a “let’s sort it out together” approach, and he certainly gave me the impression that he respected my designs and judgement. Another came from a Plessey colleague, who remarked one day that, whoever you met from DEC, you never heard anyone say anything bad about the company. And after I joined, I found it as refreshing as I expected. In these days, DEC was a strongly ethical company, derived from its President, Ken Olson, who was a staunch Quaker; he let all his managers know that if they did the “right thing” (right for the customer and the company) he would support us to the hilt, but if we did the opposite, woe betide us. I like to think that this trust factor helped cause the explosive growth of the company.
I joined Customer Special Systems (CSS), who did special customised software (and hardware) for any British Isles customer needing a somewhat different solution than the mainstream corporate products offered. Of course, what just one customer wanted this year, others might want in the future, and a number of CSS special products went on to be sold globally. My first project was for CIE, the Irish transport system (they ran buses, planes and rail transport, and maybe boats as well): based in Dublin Docks, and they too needed a large network of communicating computers, so I re-did the work previously done at Plessey, with a number of changes and improvements – mainly because, now I worked for a computer manufacturer, I had access to a number of sources of information, including better ways to use computer registers. The project involved a few trips to Dublin; the family has commented that my poor opinion of Dublin as a place to visit stems from my experiences then – rain, drunks being sick into the River Liffey, and a somewhat uncooperative customer (we’d spend all day waiting to get access to their computers, then be expected to work all night AND attend progress meetings in the day). On one particular day, with the two managers with us spending (or wasting) the day in unhelpful meetings, we got to 8pm, all of us totally fed up, and decided to find somewhere nice to eat, and “Mike” took us to the Mirabelle[97], which we discovered later was just about the best restaurant in Dublin; as we arrived, we were offered champagne (orange juice for me), and then as we waited in the ante-room a procession of waiters brought out the raw meat and fish on offer for the evening. After that, eating it seemed a shame – but we managed it.
The next project was a study for British Leyland – an automated paint-shop for their Cowley plant at Oxford. I remember we spent a visit or two to the plant, where we saw the “Ital” being built (this is before it had been shown to the press, so we were sworn to secrecy). We did a lot of study, produced a very big and detailed study, but didn’t get the job – we wondered if our plans were given to someone else to implement.
Project three was a remote control system for the Civil Aviation Authority. They operated air-traffic radars at a number of sites, and they wanted to have them unattended at night, and be controlled from their central site (LATCC) at West Drayton. We designed a telemetry system, and display systems trying to mimic control panels, with rectangles changing colours to represent on/off/standby states. One of the components I gave a lot of thought to was the display system, and how to colour and size the mimics; when I presented my conclusions to the customers it was a disaster – everyone thought that some different scheme would be better. To solve this, I designed an “instant swap” system, to change colour and size of mimics instantly – next time, I was able to show them what each rival suggestion would look like, and after only 30 minutes everyone agreed that my original scheme was best. But it taught me the principle of “universal expertise” – people will argue endlessly about things they think they are expert at; perhaps this explains why choosing colour schemes for kitchens and toilets at church always provoked considerable debate!
Shortly after completing that project, we were told that CSS as a group was to be disbanded – no longer needed (this it later turned out, was a false deduction – later on, CSS-like projects were being invented all over the UK, without the infrastructure to support projects and manage costs). So a lot of programmers were suddenly to find new jobs, hopefully inside DEC. All sorts of jobs were available, but most not programming; this made most of us nervous, because that was our “skill”; but we were encouraged to go and see – it’s you that is of value, they said, not your skill. And it turned out that many of the team said, later, that being forced to consider other types of job was the best thing that could have happened to us.
When we first moved to Farnham Common, Katie looked around for work, and after a while found a job with Wyeth Pharmaceuticals, just off the A4 southwest of Slough; she was to work in the library, cataloguing periodicals and articles as well as books. This she did until just before Adrian was born, when she became a full-time mum.
Link forward to next chronological or next on
this subject : link backwards to previous
chronological or previous on this subject, to
the Introduction, or to family
documents index.
[90] Famous as the setting for Gray’s poem, “Elegy in a country churchyard” – popularly known as “Gray’s Elegy”.
[91] It was at the time! Later, a Post Office reorganisation moved it to Berkshire – and our postal address became Farnham Common, Slough, Berks; which was silly, because Farnham Common remained in Bucks!
[92] Norman’s hobby was steam railways; he was I believe a member of the Tallyllyn railway in Wales, and spent his holidays doing track repair or whatever.
[93] An Air-Vice-Marshal is one rank below an Air Marshal, but they are always addressed as “Air Marshal”; presumably, when they rank “so close to God”, you treat them as god?
[94] Make them robust enough to withstand “normal military treatment” – such as being driven into ditches and hitting tree-stumps, and road angles of up to 50 or 60 degrees – not the way one normally treats a computer!
[95] For any of you who have never used a small helicopter, the machine hangs below the middle of the rotor blades, rather like a stone at the end of a piece of string; so when it turns right, the body of the helicopter is “thrown” left, and you see the ground through the right-hand window!!
[96] Later, when DEC in the USA designed the routing algorithms for DECnet, they used a different technique entirely; I found this puzzling, and asked them why? – but never got an answer. Then in DECnet phase 4 (I think) suddenly the DECnet algorithm changed to link state routing!
[97] Or, Mirabar or Mirabeau – memory is a bit dim now.
[i] During the project, as part of the management team, I had had to warn the applications team that if they designed their software one particular way they would run into problems later – but they knew better; as my part was completed, sure enough, the problems were happening, and I was aware that they were just waiting for me to say “I told you so” … which I didn’t do or want to do. But the “atmosphere” was soured.