An interview with John Forbes conducted by Roger Emsley on 23 August 2019, as part of the LEO Computers Society Oral History Project.

Transcript :

P1
John Forbes (JF) interview   23rd August 2019

Interviewed by Roger Emsley (RE)



John Forbes - The Systems Programmer’s Story
“I’m just very, very thankful to Leo for giving me the start that I had in the data processing business”


RE
Good morning John, perhaps you’d like to introduce yourself and tell us a little bit about your earlier life?

Early Days

JF
My name is John Forbes.  I was born in Dundee, Scotland.  I was there for 10 days.  Evidently, I was being difficult at the time!  This was back in July 1936.  At the time, my family lived in Perth about 20 miles west of Dundee.  My father was a pharmacist.  He owned two pharmacies, one in Perth and one in Pitlochry.  My mother did not work.

RE
So, any earlier memories of that time?

JF
Well, I was sent off to a prep school at the age of eight and then on to public school, having won the top scholarship to get into there.  I was in the classics stream until the sixth form and then I moved, at my request, into the modern languages stream thinking that might be a little bit more useful to me in the future.  

One interesting day there was on the very last day when the head of the maths department came up to me and expressed his disappointment that I had not studied maths further. 
O-level was as far as I got.  It proved to be somewhat interesting for the future.  I then went to St Andrew’s University, where I got an MA in French and German and in 1958 through to 1960, I did national service.  I opted to go into the education corps as I thought that teaching was going to be my thing. I’d done some teaching in the summer vacations when the university ended earlier than the prep schools.  I went off to teach in prep schools for a couple of years.

RE
John, tell us, did you do national service?

JF
Yes, I did, from 1958 to 1960.  After basic training, I opted for the education corps.  I thought this would be useful as I thought teaching was going to be my thing.  In the later stages of national service, I was stationed Aldershot. They were very understanding people there who knew that national service people would be looking for a job.  I thought I should explore alternatives to teaching and in one book and in a paper, I believe, I found casual reference to Leo computers and so I applied.  I went for the aptitude test which was set of instructions that was explained followed by a coding exercise to see if we had understood them.  Then, there was an interview by John Smison who was, I believe, the training manager.  I didn’t think I’d done particularly well on the course, but nonetheless, an offer appeared, which I accepted.  So, I started my own training course at Hartree House on February 29th, 1960, and this lasted, I remember, until April 1st, 1960.

Leo Computers

RE
So maybe now take us through your Leo career, talking about the various jobs you did and dates, which computers you worked on and your role as the years passed.

JF
On the training course, my first job under the direction of Ernie Roberts, who was the manager of Leo III software, was to per time each instruction on Leo III from the microcode flowcharts, or whatever they were at the time.  It turned out that this was okay for simpler instructions such as add, but for editing instructions—and Leo III had a couple of very advanced editing instructions— it was almost impossible to come up with a meaningful formula owing to the number of potential different iterations that could be made. 

After that, I was asked to create an open file routine for Leo II which would fit onto one drum sector.  Well, I think I did that and the next thing I knew, I was giving the instruction part of the aptitude test!  So that was the very first days.  

Not long after this, I heard that there’s going to be an advanced programming course within Leo, so I gingerly asked if I could go on it.  The answer was, “No, you’ll be teaching part of it.”  Such was the speed progressing from no knowledge to a little knowledge in a short time at Leo in 1960!  

When I was told I was to work on the INTERCODE translator, initially, I was the only one to do this job, but what was INTERCODE?  What was a translator?  I received a short briefing on the perceived problems.  One INTERCODE instructions could become multiple machine instructions.  For example, hardware would provide three modification registers which could be included in the instructions, but another 17 to make the total 20 were to be provided by software.  Other features were that in the program listing that was produced, each entry point from a branch instruction was to show the source of the branch to that point.  Go-to had not yet been banned.  The translator, the INTERCODE translator, had to interface closely with the master routine which was another piece of Leo III software absolutely basic to the design.  This would be both in creating entries to the master routine. For example, I/O operations, and describing the requirements of the object program before it was loaded.  For example, how much memory did it require, which devices would it need, were there overlays in the programs.  At the end of this briefing, “Off you go, John,” and off John went! 

 It was a fascinating challenge.  Large collections of data from jumps both backward and forward were required.  Implementation of the 17 extra registers had to be designed and interface with the master routine. A means of describing any program requirements had to be created in conjunction with Adrian Rymell and his talented master routine programme.  It transpired that to do all this, three passes of the data were required, so I’ll explain this very briefly.  The first pass simply checked the data for accuracy like any normal suite of programs.  The second pass, was most of the work and the creation of the basic object code and the third pass simply added additional code necessary for the passing of information to the master routine.  During this process, we discovered that a further machine code instruction was needed to implement the extra modification registers and then a minor change was needed to the routine and it caused the program to enter the master routine.  Both of these changes were implemented remarkably quickly by changes to the microcode programs.  These were made by the responsible engineers, but the translator itself, a program that the master routine had to deal with.  At the outset, there was no master routine, so initially, all code was in machine code.  We had to put with this initially but gingerly, the two teams stepped forward and contact was made between the master routine and the translator and the programs it produced.  Then came the idea that we should add all the machine code instructions to the INTERCODE repertoire to translate…allow the translator to be translated into itself.  

Subsequently to that, the INTERCODE translator was written and maintained in INTERCODE.  We later added an inability to create dumps of various parts of a program without going through the whole retranslation process, and this was well-received by users.  

Can I go on to testing or do you want to have a gap there?

RE
No, let’s talk about testing.

JF
Okay.  One major challenge with the translator and all the other software programs at the time was testing.  Leo III/1 was not yet installed at Hartree House but was being commissioned at the Leo factory in Acton in West London.  Engineers needed to work on it during the day.  Fortunately, we needed lunch and had to go home in the evening.  The master routine programmers also needed to test their programs so I had to work closely with them on sharing the available time.  

In the latter stages, we could share testing time using the translator as test data for the master program or certain parts of it.  We were also fortunate at that time to have the help of a Leo staff member of South Africa, to which Leo III/2 had been sold. He provided great help in creating test data and checking results.  

From this experience, I think I learned that to take on a challenge which when first explained to me as a programmer with six months experience made very little sense!  

Then we go into CLEO

RE
Okay, tell us about CLEO, which stands for…?

JF
Clear Language for Expressing Orders.  

RE
Well done.

JF
After finishing the INTERCODE translator, the question of a CLEO compiler came up.  CLEO was a high-level language intended to compete with COBOL.  I was aware that within Leo, there was a vigorous debate between CLEO and COBOL and which compiler should be written.  I was not party to this debate.  I think it’s weird of me to say that at that time, there was no appreciation or need for computers to talk to each other, although by having common tape or other standards and formats we might have a chance of having programs capable of being run on more than one machine.  It was always, “My X is better than your Y,” kind of environment!  My instructions were to create a CLEO compiler. Rather than the three-person team I had for INTERCODE; I had a ten-person team for CLEO.  As far as I’m aware, this would be the first compiler in the UK to deal with both business, mathematical and scientific programs.  I divided the work into two sections; one to deal with the data definition, which was in many ways similar to that of COBOL, and the other with the actual instructions which ranged from, as I said, business to mathematical.  Because of this, we quickly became aware of the need to analyse carefully both the data definition and the coding using a reverse Polish technique which ensured that both mathematical functions, simple or complex, were performed in the correct sequence, and that the correct level of data was always addressed, whether being a simple single item or a larger collection of related data.  

The experience we had gained in the character-by-character analysis in writing the INTERCODE translator was obviously extremely valuable in this.  One of the main suggestions that was made from outside the group was that the output of the compiler should be an INTERCODE program rather than machine code, and that INTERCODE program could obviously be handled by the program INTERCODE translator.  This saved a lot of time in creating a work-in-progress for translating CLEO programs to machine code.  It did of course mean that each compilation of any program took longer and no study was ever made, to my knowledge, of the net benefits of either approach.  The CLEO compiler process was, as you can imagine, rather more complex than the INTERCODE translator.  I did write an article for the Computer Journal which appeared in July 1975 on explaining some of the methodology that was used in both these two systems. That’s available for those who would like to know about the working use of the two programs.  Sorry, I don’t have the precise reference.

RE
Okay, so in your time at Leo, did you get the impression that you were making history in terms of the computer era?

JF
No, I don’t think I did.  I didn’t have proper recognition of how advanced some of the software was.  I mean as I said, I was thrown off the deep end and I was swimming like mad.  In hindsight, it obviously was groundbreaking, but I was in there doing my thing.  

One thing I should add before the end of my Leo III existence is that even before I had finished working on the compiler, I began to get requests from sales consultants to accompany them on visits to clients.  The sales process for Leo had moved on from its initial desire to see itself as business partners with clients to competing in an environment of “My computer is better than your computer because of A, B, and C.”  At first, this was purely on the hardware front.  How big is the memory, how fast are the mag tapes and so on.  Slowly, it became more like “Why is CLEO better than Nebula?  What does the master program do?  What is this multi-programming thing and is it really useful for me?  Why does the master program take so much memory?”  To a person who is not a natural salesman, this was, at first, a difficult experience, but soon, I learned and anticipated what the next question was going to be and how to handle it.  

Interestingly, there was no formal group created for this purpose and back on the CLEO team, I was fortunate I had two very proficient section leaders who were able to handle things in my absence.

RE
So, does that cover your full career with Leo?  When did you leave Leo?

JF
Well, can I go back to the IBM 360?  The Data Processing world, or should I say the IT world as it became, changed in April 1964 when IBM announced the System 360.  Copies of much IBM literature were obtained and we scrutinised them.  I was assigned to the team that was looking at their offerings and asked to look at, in particular, at their I/O (input/output) system, which I saw was a great step forward in that one instruction provided access rather to an open-ended I/O system that could appear to handle any device, present or future.  

By this time, Leo had become English Electric Leo Marconi. Within this group, work had already started to design a next generation range of computers.  Chris Date, who later went on to IBM and is well-known I think for his work on data structures, and I were charged with the task of designing a set of machine instructions.  The design we came up with incorporated the standard registered set of instructions plus instructions to handle indefinitely large stacks.  The project died on the vine when it was announced that English Electric Leo Marconi, EELM, had made an arrangement with RCA of the USA to use their Spectra series of computers as a basis of what was to be called System 4 with Leo, English Electric, and Marconi Factories each assigned a machine in the series.  

At that time, I was asked to join a team consisting of David Caminer who was the sales manager for LEO, and from English Electric, Dennis Blackhall, the head of their software department, and Phil Scall to visit RCA.  This was at a difficult time for me as I had got married in 1964 and the arrival of our first daughter was imminent.  Nevertheless, it was an interesting trip and my first visit to the USA.  Then back to UK, where a product planning team was formed and I became a member of that.  This was also charged with developing a launch programme for the new series.  Some of the initial software was to be taken straight from RCA and some was to be developed in the UK.  Probably because there was a more established group of software people in Kidsgrove than in the Leo facilities, it was determined that any new software should be created at Kidsgrove.  

The most important piece of software in Leo people’s mind, and the most important piece of software to be integrated from scratch was an operating environment known as 5J which was to be used for larger machines, with which of course legal people were more familiar.  This was also to be the first disk-based software environment for either Leo or English Electric.  I was in London and was the Leo liaison person with English Electric software team.  I found a good rapport with the 5J development manager.  But it seemed to me that unfortunately, insufficient resources were allocated to this project.  It seemed to be that more weight was being given to the KDF6 software, an older and smaller machine, rather to the new System 4 range which was surely more important to the future of English Electric Leo Marconi.  

Despite this, System 4s were installed and the sales force was thirsting for knowledge on where and why System 4 software were superior than that provided by IBM.  We set out to develop the software strengths of System 4 vis-à-vis comparable IBM models.  Then came the possibility of unhooking an IBM installation, i.e., replacing it with a compatible System 4 model which had exactly the same machine order code.  However much the hardware was deemed compatible, there was inevitably differences in the software, which although not necessarily major did call for some work converting the programs, especially in the I/O area, as well the operators job instructions were likely to be different.  

Then came a career-changing event for me.  Richard Beckinsale, an experienced Leo programmer and I were to go to RCA in the USA and look at the advances RCA were making in software. I was to meet with the RCA sales force to see how they handled dealing with IBM in various situations.  My wife, Jane, also ex-Leo, and I by now had two children.  I was told I was doing an excellent job, I seemed to have a decent salary, but at the end of the month, there was little or nothing of it left. Commuting took two hours a day and there were the frequent trips to Kidsgrove as well as potential clients.  Then the takeover by ICL took place. 

Rural Bank Of Canada

At the end of this trip, I visited Jane’s relatives in Ottawa and resulting from previous correspondence with them, I was shown an ad for a manager software support at Rural Bank of Canada, Canada’s largest bank.  I went to Montreal for the interview and was offered the job shortly after returning to UK.  I started work in Montreal in April ’69.  

The job was a mixture of supporting the six data centres across the country, developing programs to enhance the working of IBM software and the promise of a major role in the bank’s new computer setup which would surely include any branch banking and many other features.  On looking at the daily operation of the data centres, it was quickly apparent to me that dollars were being spent in the wrong area.  The person responsible for the hardware configurations had little knowledge of systems and, for example, using my Leo experiences, I saw that speed on the tape drives would hardly ever be used given the amount of processing and data movement that had to be carried out on each record.  So, exit many unnecessarily over-speeded tape drives and one IBM salesman! 

At the bank, there was the first working online system I had encountered.  It was called COLA standing for Chargex Online Authorisation with merchants phoning into the bank and to a team of initially six terminal operators entering the card number, merchant amount, and so on.  One of the very first attempts to fraud, credit card fraud, one of these tunnels didn’t work and two more were brought up in order to cope with increasing volume, so one wag determined that the system should now be referred to as Seven Up.  (Laughs) The disappointing thing about my stay at the side at the bank was any substantial move towards a sophisticated online system. That simply did not take place despite the fact that the other major Canadian banks were rumoured to be moving quickly down that road.  

In my job there, I had visited the other data centres across the country, including Vancouver, and was immediately attracted by it.  Montreal’s climate at that time, both political and meteorological, was not ideal.

Vancouver Stock Exchange

Fortunately, I was able to obtain a position as data processing manager at the stock exchange in Vancouver in November, 1972.  There, the installation was small, the DP staff numbers were small, but with talented individuals. 

A year after I arrived, we replaced an aging UNIVAC machine with an IBM 370/125.  The exchange was small, and was subject to wild fluctuations in the volume of trading, giving rise at times to too much being spent on computing etc. Obviously, we were trading and the system got behind its reporting of market prices trades.  The exchange staff grew.  The DP became the ICF staff and expanded.  We introduced a new trade clearing system and became the first stock depository in Canada.  Later, the exchange took over the broker’s accounting system.  

Gradually, I was asked to take on other responsibilities.  I loved the challenges of IT but was finally directed to find an IT manager so I could spend time on other aspects of the exchange business.  The exchange was to become the first Canadian exchange to introduce fully computerised trading.  By 1999, the long-standing movement to unify all Canadian exchanges into one body was realised.  

Retirement

I retired on December 31st, 1999, so I can truly say that I have not worked this millennium.  I can truly say I love computers and I enjoy writing programs myself, so the story does not quite end there.  

I have some skill with C Sharp which has helped me write my account management system, my securities holding while they still exist, and my dictionary.  Why dictionary?  I actually followed my father’s footsteps in having our growing attachment to crypto-crosswords.  First, solving them, and then creating them.  When I started my student days, I was fortunate enough to have a cryptic puzzle accepted and published by The Listener.  Two more followed.  When I joined Leo, I did not have time for such things.  In North America, it was hard to find cryptics.  I did join an organisation called the National Puzzlers’ League which published cryptics from time to time and I was able to contribute some to them.  Now that I’m retired, I have a little more time and I compose regularly for a puzzle club in UK to the Magpie Monthly.  I most recently have had a puzzle published in the New York Times.  Sorry, I must rush now, I have a golf game scheduled.  (Laughs)

RE
So just before you rush off to your golf game, maybe reflect a little bit on your life experience with Leo.  What remains with you of that experience?

JF
The knowledge that I can take any program or any challenge or any program language because they’re all basically the same, and we have to address the same problems and delve into any problem.  I mean I do it only for myself now.  I haven’t tried to sell any of the programs I have written, so they may not follow all the sound principles that we learnt in the early days of Leo, but they do have the ability to work.  I also learnt a little of management in a very technical environment which, as I found out, in Vancouver, was not necessarily the same as managing in a non-technical environment though obviously some of the same problems did arise.  I mean I’m just very, very thankful to Leo for giving me the start that I had in the data processing business or the IT business and I think I enjoyed every aspect of it and it gave me a very good foundation for work that I was to do later on. 

RE
Have you attended any of the Leo functions?


JF
No, I haven’t.  I have been in contact with Peter Byford from time-to-time.  We do still visit UK occasionally.  I have a sister who lives in the outskirts of Manchester, so our visits there are more likely to head in that direction rather than to be near or in London which is where I understand all the reunions are held.

RE
Okay, so to conclude the interview, this interview with John Forbes has been recorded by the Leo Computers Society and the society would like to thank him very much for his time and reminiscences.  The interview and the transcript form part of an oral history project to document the early use of electronic computers in business and other applications, but particularly in business.  Any opinions expressed are those of the interviewee, that is, John Forbes, and not of the society.  The copyright of this interview is in recorded form and in transcript remains the property of the Leo Computers Society.  

That ends our interview with John Forbes on August 23, 2019 in Vancouver, British Columbia, Canada.






 

Suggested Footnotes:-


Page 2
INTERCODE: is the low-level programming language that lies close to the LEO physical architecture and it’s machine code. It is interpreted or translated into machine code at run time. INTERCODE enables the programmer to closely control programs down to the bytes and bit level. INTERCODE can be considered as roughly equivalent to IBM’s ASSEMBLER language.

Page 3
CLEO (Clear Language for Expressing Orders):  is the high-level programming language developed by LEO specifically to run on LEO computers. It is a compiled language that is pre-run time translated into machine code from the source code.  CLEO can be considered as roughly equivalent to COBOL or PL/1.

Page 4
Reverse Polish notation (RPN), also known as Polish postfix notation or simply postfix notation, is a mathematical notation in which operators follow their operands, in contrast to Polish Notation (PN), in which operators precede their operands. It does not need any parentheses as long as each operator has a fixed number of operands. The description "Polish" refers to the nationality of Jan Lucasiewicz who invented Polish Notation in 1924.  

Multi-program running, or more accurately asynchronous multi-tasking, time sharing was a LEO III innovation. Unlike LEO II that ran a single programme with operations occurring in a controlled sequence, LEO III introduced multi-tasking that enabled many programs to run concurrently. This was achieved with a Master Routine controlling operations via   "Interrupt " orders from the different individual programs demanding priority access to memory etc.  Although each individual program still ran according to its defined sequence, the overall sequence of operations across all the programs concurrently running, or time-sharing, was not repeatable or predictable. The programs thus ran asynchronously.

Page 5
David Caminer OBE: (1915 2008) had a long career with J. Lyons, LEO and English Electric from the 1930s through to the establishment of LEO and beyond to the formation of ICL. He became known as the world’s first Business Applications Programmer.
IBM System 360:   is a family of mainframe computer systems that was announced by IBM on April 7, 1964, and delivered between 1965 and 1978. It was designed to cover the complete range of applications, from small to large, both commercial and scientific. 

IBM System 360:   is a family of mainframe computer systems that was announced by IBM on April 7, 1964, and delivered between 1965 and 1978. It was designed to cover the complete range of applications, from small to large, both commercial and scientific. 

RCA Spectra: computers were manufactured by the Radio Corporation of America’s. The RCA Spectra 70 line was developed by RCA’s computer division beginning in April 1965 and included several CPU models, various configurations of core memory, mass-storage devices, terminal equipment, and a variety of specialized interface equipment.[1]


 



  

Provenance :
Transferred from Frank Land's Dropbox to Lisa McGerty

Copyright
The video above may be subject to copyright of the original author and is present only on this website for non-profit educational purposes only. If you are the original copyright owner and wish to have the media removed from this website please contact us using the relevant contact email address listed on our contact page.