Key software products of the 1900 Range were the George Operating Systems
The following is an extract from the talk that George Felton gave at the
The successful George systems were based on original ideas developed between 1959 and 1964 for the Ferranti Orion computer. I shall have to outline these to start with.
Thinking about the Orion system started late in 1958. From Jan 1959 intensive work in Ferranti on new computers led to Atlas and Orion. Development of the operating system (OMP) took place in parallel with that of the hardware (which was heavily oriented to users, i.e. programmers and operators). In March 1959, a presentation of both machines was made to Harwell. At this time much effort was still going into Pegasus and Mercury.
We designed simple but effective features in the Orion hardware to allow simultaneous running of independently written programs – we called this Time-Sharing but it would nowadays be called pre-emptive multi-tasking, with limited multi-threading. There were privileged instructions to allow efficient time sharing or multi-programming. There were hardware datum and limit registers to prevent any program from accessing any part of the core outside its own entitlement – this prevented accidental interference between jobs and was considered vital for sanitary time sharing (paging was introduced later and provided a different but equally effective way to prevent interference between jobs). There were also arrangements for a program to access only its own peripherals, referring to them by its own private set of addresses. Each program had its own set of registers (accumulators, modifier registers, etc). All these features seemed obvious at the time and they were cheap to include in the hardware. OMP didn't include any multi-access features – the idea was invented later at MIT as Project MAC.
On
In June 1962 we started shift work developing OMP and Nebula on the Orion prototype in West Gorton. We started running time-shared programs on the prototype Orion by May 1963, when the first (Turitz) Orion started acceptance tests.
In about Dec 64 (?) Peter Hunt was made responsible for
software development in ICT and a request was received from Chris Wilson
(responsible for selling the 1906/7) for an operating system on the lines of
OMP for the 1906/7. On
(Summary Description
by H. P. Goodman January 2004).
In December 1964 the company was reorganised so that all software development was moved into Programming Division managed by P.M. Hunt. A branch was set up (Operating Systems Branch) which would eventually design and build a major operating system for the 1906 and 1907, these being the top end of the 1900 range as originally announced. Initially the branch was staffed from those who were engaged in Orion built in software. The Orion work was nearly complete and the intention was that these staff would build the 1906/7 Operating system as they became free.
The initial outline specification of the system envisaged a batch processing system incorporating the time sharing features of Orion and the spooling features of Atlas; the core of the system would be a file store with a minimum requirement of a 512k word drum. After a few months the system was named George as a compliment to the Department manager, George E. Felton. The official explanations were that it stood for General Organisational Environment and that it was analogous to the autopilot on Second World War era aircraft, popularly known as George.
In July 1965 a major seminar was held at N.P.L. describing Project MAC at M.I.T . This was a system which had been developed on a highly unsuitable IBM computer to provide a primitive multi-access system "a 7090 in your office" which allowed up to 32 simultaneous users on teletypes to develop and run programs. This was obviously going to be a major way of using computers and ICL immediately decided that it needed a product in this area for the 1906/7. This was to be called MOP (Multiple Online Processing) and the project was added to the workload of the team developing George. In November 1965 I attended the Fall Joint Computer Conference in Las Vegas where the major topic was Multics, the new multi-access system being designed at M.I.T. I brought back a number of papers on Multics and many of its ideas were incorporated into George, particularly the tree-structured file store. Around this time it became clear that rather than produce two separate systems, George and MOP, it was preferable to build a combined system which provided both batch and multi-access facilities; MOP thus ceased to exist as a separate system but the term continued to be used to describe the parts of George dedicated to multi-access facilities.
Towards the end of 1965 it became clear that there was a large gap between the simple time-sharing facilities provided by Executive and the sophisticated facilities to be provided by George. Marketing therefore requested two simpler and earlier operating systems than George. It was decided to rename George as George 3 so that the simpler systems could be called George 1 and George 2 respectively. George 1 would run a single stream of programs with job control facilities to replace operator action. George 2 would add spooling facilities to George 1.
The main components of George 3 were:
(a) The command language which was used both for batch job descriptions and by on-line users at MOP terminals,
(b) The file store which is the heart of the system containing files of many types, including those read in from basic peripherals.
(c ) The various scheduling subsystems including facilities for swapping and off-lining.
(d) MOP and other remote access facilities
(e) Accounting and budgets
Unlike George 1 and 2 which were
built on top of a standard Executive, George 3 effectively controlled the whole
machine. There still had to be an Executive whose main functions were low level
control of various peripherals and concealing hardware differences between
various members of the 1900 range. This Executive had no user-visible
functions. The George team, in Putney (London), defined the interface between George
and Executive. the executive was implemented by programmers close to the
hardware manufacturers in West Gorton (
George 3 was written in an Assembly Language. It turned out that the standard 1900 Assembler (PLAN) could not be used since facilities to use extended mode programming, hardware only available on 1906/7 initially, would not be available in time for development of George 3. A cut down assembly language called GIN (George Input) was developed and this evolved into something particularly suitable for George 3 with the inclusion of sophisticated macro and conditional assembly features.
The George 3 command language consisted of a number of built-in commands of various types which was augmented by a powerful macro facility. Commands had a variable number of parameters, normally separated by commas, and there was considerable flexibility as to whether parameters appeared in fixed positions or were specified by keywords, in which case they could appear in any order. The macro facility could be nested to any number of levels and recursive macros were allowed and often used. The fact that the same command language could be used for both batch jobs and on line work with MOP proved to be very important; particularly for testing programs on-line which could then be run in batch mode with no change to the job description. It is interesting to note that this facility was not available on IBM machines until 1974. Many users built up complex libraries of macros which could call each other. In some cases this became almost a programming language which could be used to built up complex jobs from a sequence of simpler programs.
Each built in command had a 2 letter abbreviation. Over the years, as the number of commands increased, it became more and more difficult to find an appropriate name for a new command which yielded a plausible 2 letter abbreviation which had not already been used. Similar problems arose with command syntax as it got extended many times to meet new requirements. The development of later versions of George 3 was largely customer driven; the development team published a list of suggested enhancements periodically and a committee of users assigned priorities to these which thus determined what we would be added to the next mark of the system.
The original specification was for George 3 to work with a minimum backing store of 512k words, this being the size of a large drum available at the time of the original announcement. As the system developed this proved to be unrealistic as more and more uses were found for direct access devices and as larger and larger exchangeable and fixed disc systems became available.
The file store provided spooling (aka off-lining) facilities for all basic peripherals (e.g. paper tape and card readers and punches and line printers) so that input documents were read into the file store and then passed to the object program one line at a time; similar output for punches and printers went to the file store and were output later by George.
There was an "upwards compatibility" commitment which meant that George 3 had to be able to run any program written to run under Executives on smaller machines of the 1900 range. Such programs often addressed peripherals directly using, for example, slightly different PERI instructions to output to line printers, card punches and paper tape punches. In order to support such programs files in the file store had to have a file-type such as line printer or paper tape reader and, although the file was actually on backing store, it was read (or written to) using appropriate PERI instructions. George also allowed some flexibility here, e.g. allowing a file output to a line printer to be read by a program expecting card input. Programs written specifically to run under George 3 would refer to disc files rather than basic peripheral files.
The file store was hierarchical with a tree structure of directories of arbitrary depth. Each directory had an owner who also owned all the files in the directory. A subdirectory could either belong by default to the owner of the superior directory or could itself be assigned to a different owner. Each user had a home directory and file names could be given relative to the current directory, the current user's home directory or absolute, from the root directory. There was an elaborate system of user traps to allow users to read or write to files belonging to other users. There was an incremental dumper program called in at regular intervals which dumped copies of files which had been created or modified since the last dumper run to a dedicate magnetic tape known as a dump tape. This allowed restoration of individual files or the whole file store if this turned out to be necessary after a system crash.
There was also provision to handle disc files that were not part of the file store, known as exofiles; these were needed by programs which wished to handle the physical properties of large files, e.g. to minimise head movement. Thus large main files, especially indexed sequential and random files, were usually exofiles. File store files were mainly used to handle the mass of small files where the user did not need to know how they were organised.
The scheduling mechanisms within George 3 were on three levels:
(a ) The High Level Scheduler
(b ) The Low Level Scheduler
(c ) Executive Time sharer.
The function of the High Level Scheduler was to examine the queue of jobs waiting to be run at any one time and select which of those need to be made active; i.e. known to the Low Level Scheduler. The object was on the one hand to generate an efficient mix of jobs to optimise the use of the system's facilities and on the other hand to process jobs in accordance with the system manager's priorities. There were a number of installation parameters which could be set to define the installation's policy; also jobs were given different urgencies which the High Level Scheduler would take into account. The main part of the High Level Scheduler was written as a subject program; this was an object program with a slightly privileged interface to George 3. A standard High Level Scheduler (with parameters) was provided but an installation could enhance or completely rewrite it if the local policy required scheduling action not handled by the standard program.
The Low Level Scheduler ran the jobs passed to it by the High Level Scheduler with the object of optimising machine usage. It handled such issues as swapping programs in and out of main memory when they were waiting for something; this was particularly relevant in a MOP environment. A subset of the programs being run by jobs known to the Low Level Scheduler was handed over to Executive in numbered slots.
The Executive time sharer handled a number of programs known to Executive, all of which were in memory. Executive switched between them in accordance with their order in the Executive list and whether they were able to run or were waiting for some resource to become available.
Some later 1900 series processors had hardware paging, based on the concepts developed on the Ferranti Atlas in the early 1960s. These systems ran a modified version of George 3, called George 4. The main differences were in the operation of the low level scheduler which arranged for parts of various programs, according to quotas, being held in memory. George 4 had extra user facilities, especially to allow users to use non-contiguous addresses, this was useful for such scientific operations as inversion of sparse matrices.
The MOP (Multiple Online Processing) parts of George 3 handled many simultaneous users developing and running programs from teletype terminals (visual display units did not become widely available until the 1970s which is beyond the scope of this paper). Users logged in to the system and quoted passwords, this being an alternative to the JOB and RUNJOB commands used to run batch, or background, programs. MOP users had access to the same commands and macro facilities as background users. There was also a break in facility which allowed MOP users developing programs to interrupt the program currently running, examine its data or modify it, and then either continue running it or start again. MOP users could also start a background job and then disconnect from it and do something else or log out. They could, if they wished, reconnect to this job from time to time to examine its progress.
There were also facilities for handling remote peripherals via communications lines. A typical case would be a machine with a number of line printers at various locations the requirement being to print the output at a location convenient to the user. This was done by a PROPERTY command which was a general facility to ensure that specific peripherals were allocated to a job. Example properties could be geographic location, special stationery loaded or ability to print fast.
George 3 provided log analysis for each job. Each job had a monitor file and the log analysis program, which had many parameters and could be replaced by a user-written program, calculated the cost of the job. Each user had a budget, which contained a number of budget types such as money, CPU time and number of magnetic tapes. At the end of the job the amount of money and CPU time used was deducted from the user's account. If the user was overdrawn he was not allowed to start another job. Budgets were refreshed by period accounting which calculated the bills per user. CPU time was divided into a number of urgency levels allowing individual some say in deciding which of his jobs were urgent. The magnetic tape budget specified the maximum number of tapes the user could have assigned to his jobs at any one time.
George 1 ran as a single program under Executive with the privilege of being able to manage a PUC (Program Under Control). Basically it read in a job control tape (or cards) for one job at a time and ran it. This included handling of editing, compiling, monitoring while running and accounting at the end of the job. George 1 was memory resident.
George 2 essentially added a spooling facility. A number of job descriptions and data files were read in initially and stored either on magnetic tape or direct access backing store. George 2 had a number of overlays; there were various versions depending on whether spooling and overlays were on direct access devices or magnetic tapes or a combination of both.
Minimop was a simple controller of a number of online development jobs which ran under Executive. It could be run simultaneously with George 1 or 2 on machines with insufficient configuration to run George 3. This combination was also used before the release of George 3 in April 1969.