|Home > LEO Computers > LEOPEDIA > Other Memoirs, Reminiscences > Ray Smith: Reminiscen ... Intercode Programmer|
Ray Smith: Reminiscences of a LEO III Operator and Intercode Programmer
Ray started as a trainee operator on the LEO III/4 in Greenwich for the London Boroughs' Joint Computer Committee (LBJCC) in 1966. He progressed to a senior operator before joining the London Boroughs' Management Services Unit (LBMSU) in 1968 as a trainee Intercode programmer. The LBMSU provided the programmers for the LBJCC. After his training course, he was posted to the North London satellite unit which looked after three, later four, North London boroughs with LEO III/94. He was not very happy about being posted to the sticks as he regarded it at the time. However, not long afterward the North London boroughs severed their relationship and his unit became independent. This put him into a fairly senior position overnight. Now he was happy. A couple of years later this unit became the London On-Line Local Authorities, moved to Enfield and installed an IBM machine. Ray was then sent on an IBM PL/1 course.
In due course, he rose to the Principal Programmer position. Around 1977 he moved to work for Lloyd's of London where he stayed until 1998 becoming the General Manager of the Systems Development group and finally in charge of development, operations, networking and telecommunications. He retired in 2002 after spending a few years as a consultant mainly for JP Morgan.
My view is that for its time the LEO architecture was brilliant and Intercode was a very significant step forward over its rather elegant (in my opinion) Machine code. It also stood the test of time lasting into the late 70s.
As an operator, I found the machine itself a very rewarding challenge to get the best out of it, but get the best out of it we did (well some of us). For instance: understanding how the Master allocated valuable core storage. If the operator loaded programs in a non-optimum way that would limit the number of programs that could be running concurrently at any time; forward planning to have tapes ready from the tape store ahead of time that they were needed to be loaded; having the correct stationery loaded in the printer ahead of time if possible; many etceteras.
My chief operator (who didn't operate) would go through the computer log daily to check how efficiently the console operator had performed the day/night before. Indeed, he worked out roughly how much every minute of machine time cost. In pound note terms, it did bring to life how much say, a twenty-minute rerun cost due to an operator error or a five-minute delay finding and loading a correct tape cost. Those that did the least well would find themselves more often than not, decollating 2- or 3-part stationary, chopping and packing payslips and other non-standard items. Those were jobs to be detested and a useful sanction. It certainly spurred me on to become a good operator (sorry to boast, but it is true).
Also, it was also remarkably reliable for its time (LEO III). You couldn't always say that about the quality of some of the programs though. Here I mean user programs.
As a programmer, Intercode, which at first seemed difficult, soon became easy once you managed to come to grips with its structures and operators. Like operating the LEO, the real challenge was efficiency, but here it was in terms of how to write programs as small and reliably as possible so as to utilize best the limited resources of the machine and to minimize run times whilst leaving intelligible code behind for some future programmer to understand and amend. Oh, and I nearly forgot, accurately to perform the functions from the users' specifications. This was fun!
I had little experience of CLEO, but it seemed bloated compared with Intercode at a time when computer storage and machine cycles were at a premium and verbose to work with. I bet there were some heated discussions at the time about whether to go via the Intercode route or directly into computer code. I expect expediency won. Anyone know out there?
It did lead to having to have twelve overlays to compile; six for CLEO and six for the Intercode. Fascinating to watch as an operator the tapes doing merry dances going forward, rewinding, searching, running back etc. Had there been disk storage available though ...
My view (not original) is that high-level languages could not have their time until main storage, disk storage and machine cycles were virtually unlimited compared to the time of the LEOs. What a shame they could not have been developed further once those things became available. The CLEO would have been more in its element.Date : Unknown
This exhibit has a reference ID of CH56469. Please quote this reference ID in any communication with the Centre for Computing History.
Click on the Images For Detail