The EEC ICL Story

CODIL (also known as DORIS) - the E.E.C. and I.C.L. Story
Looking towards the Next Generation of Computers
Draft Report[1] of my time working for English Electric Computers and International Computers Limited between1968 and 1970
Prepared for the Leo Computer Society Archives
Chris Reynolds, September 2018

1      Starting Work with English Electric Computers

In August 1967, after only 20 months working with computers with Shell-Mex & BP, Hemel Hempstead[2], I started working with English Electric Computers[3] on an exciting new job. My job title was Sales Consultant, but my job was to do market research into what big commercial customers would be expecting in the next generation of computers, some 5 years down the road. The team of two was headed by George Stern, a salesman who knew the company well, and also had many contacts with current and potential customers[4], while my job was to be looking at the likely changes in software and hardware technology. I started the job never thinking that my proposal for a sale contract language for Shell Mex & B.P. might prove relevant.
But before I started on the job proper I needed to learn about the current systems being markets by the company. The System 4 computer[5] (which had been turned down by Shell Mex & B P as a possible replacement to the Leo 326 computers[6]) was an IBM 360 look-alike system. The course I was on dealt with the various models but also involved programming in System 4 assembly code (identical to the IBM 360 assembly code). Up to this point in time the only computers I had known were the Leo 326 systems and I was interested in the very big differences in the instruction set, the way in which arithmetic was carried out, the use of registers, and the way memory as addressed.
What came next was interesting - because George was about to take his summer holiday. As the work was looking several years ahead there was little of immediate urgency and his idea of getting me into the job was unusual but effective. Each day several reports and other documents would arrive in his in-tray and my instructions were to read them and draft comments or a possible reply.  We would then discuss them, and take appropriate action, on his return.
One of these reports was of particularly relevance to what happened later. The software development team sent some outline proposals for what I considered was a rather simple library indexing program. This linked back to the work I had been doing at the Cooper Technical Bureau a couple of years earlier where one of my tasks was manually cataloging a complex variety of research and development documents[7]. I decided that it would be useful to give an example demonstrating the kinds of complexity I had to been dealing with, using the kinds of classification terms I had used. The original note has not survived but a typical entry might have been something like this:
Animal – Cattle; Parasite – Tick; Country – South Africa; Chemical – 23Z61; Test – Cattle dip; Document Ref – SA 63-171
Subconsciously I had taken indexing terms from a manual information retrieval system and written them out in a very similar format to the sales contract rules in my Shell-Mex & B P proposals. I don’t think I really spotted this as being significant at the time – but clearly the two applications were very different.
As soon as George returned work begun in earnest. This involved visiting several major computer users (both commercial and university) and discussing the problems they had with existing systems and applications and ask how they would like to see things improving in the future[8]. On the software side I was in touch with the company’s own software teams and I became involved with an external group, run by Urwick Diebold, concerned with identifying data base requirements within COBOL[9], In addition I was asked to write a report on the problems of safeguarding data collected via online terminals[10]. On the hardware side I was in touch with the team responsible for computer processor design in order to discover the kind of facilities the next generation of computers might offer[11].

2      An Idea is Born

Within little more than a month I realized that my Shell-Mex and B.P proposal[12]  could be generalized to cover a range of complex information processing problems which were hard to predefine precisely, and where a flexible human-computer interface was important. George suggested that I drew up a document outlining my ideas and in October 1967 I submitted the document to John Aris. The covering memo[13] included:
Attached is a draft of a preliminary report on a data processing scheme I have been working on. The basic approach is to design a system oriented towards human-computer communication (in the logic sense.) So far much more work needs to be done, both in filling in the holes and extending the idea further. However the further the idea is extended the simpler it becomes. I feel that this can be explained in that I am trying to emulate human thought by computer, while existing systems attempt to simulate it via a combination of analysis/programmer/computer.

This makes it quite clear that from the beginning I was “trying to emulate human thought by computer[14] and it is important to put this in context. In the 1960s all kinds of new applications were being computerized for the first time – and this was seen as applied technology rather than research. Very little published research had been done on interfacing ordinary users, rather than programmers, glass teletypes were still not commercially available, and the first big man-computer conference was not held until 1970. In effect there was no-one around to tell me what I was doing was supposed to be “very difficult”. As far as I was concerned all I was doing was a different (but very interesting) systems analysis job which could open up a new market for my employer.
The main text of the document included a brief statement of assumptions:
The idea is to design an information processing system for an unknown user with some data and access to an unspecified computer. Such a system should be of completely general application. It is assumed that the user wants to interrogate and amend the data. To allow him to do this efficiently he will want the data arranged in preferred orders (i.e. equivalent to conventional files and records) possibly coupled with some means of cross-referencing (for indexes) and duplication of all or part of the input statements in other parts of the system. It is also assumed that he will want the data in the system to be self-consistent and for this reason detailed facilities for comparing statements must be incorporated.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

This idea of designing “an information processing system for an unknown user” with an unknown application seemed natural to me, because I had previously worked in complex manual information systems and took uncertainty for granted. As far as I was concerned users would always understand the complexity of the task they were doing better than I would. There was no point in trying to explicitly predefine a system to meet all the possible fine details of their task. In such circumstances I considered my job was to provide them with a task-independent information tools which they could use.

My note concluded by saying:

The original approach to computers was “how can we use this new equipment?” I was found that they could be used to manipulate data in various ways, but serious problems have been encountered on trying to design very sophisticated systems. In this report the problem has been reversed by returning to first principles and asking the question “what are the features required for a data processing system?”  A great deal more work still needs to be done but it appears to be possible to build a system which offers great improvements in terms of flexibility and human-machine communications. This system could be run on existing computers and would show big advantages for many applications. However by modifying the hardware a saleable system would result.

A few days later my notes were forwarded to John Pinkerton[15], and in mid November John Meredith-Smith wrote a memo[16] assessing the idea. He made some comparisons with prototype systems analysis tool called “Spec” (which I had not heard of) and concluded:
Perhaps now is a suitable time to review the whole situation of system analysis languages. I do not believe that a compiler for SPEC would be valuable in its present form. It may well turn out to be ill defined , in terms of Backus, and does not seem to go far enough in specifying the system. However SPEC, DORIS and the standard data processing routines, which we are developing for System 4, do seem to constitute a useful base on which to develop a powerful system analysis tool.
Futhermore such a study could well reflect on the design of hardware. Mr. Reynolds’ work on DORIS implies the use of modified list processing techniques and it would suggest that the implementation of such a system would benefit considerably by the existence of an associative memory of some 64 words.
I believe that work of this type on data structures and the derivation of systems should be followed up in the company, Not many of Reynolds’ ideas are original, in fact none of them may be, but most of them are new so far as systems analysis in the company is concerned. Where effort can be found in the company I do not know. Mr Reynolds can only work on this part time, I gather less than a ¼ of his time; I do not believe we could provide any more than about a ¼ man. Mr. Gibson is enthusiastic and might provide some effort from Applied Programming; Trianing and S.P.D. development might also be able to give some support.

I did not see this memo at the time and was not aware of how far CODIL was begin backed as a systems designed tool for programmers and systems analysts to enable them to design conventional procedural programmes. Of course CODIL could be used in that way – by building a working model of the application task – but if you have a working model why convert it to a conventional COBOL program as the result be would loose the ability to tell the user what the system was doing. Such a step would mead moving from a transparent system to a black box system – and also loose the flexibility CODIL gives to change when the complexities of the real world application require thing to alter. However, to be fair, my own ideas were still pretty fluid at this early stage.

3      The First Detailed Specification

As a result it was suggested that I drafted a more detailed description of my ideas, and the project was officially given the codename DORIS (Data Oriented Information System). The following short reports were produced for a meeting held at Computer House, Euston, on 1st December, 1967,
1.      DORIS. A brief Introduction. This outlined the way the central decision making algorithm worked.
2.      DORIS. Data Structure. How information was stored in the system.
3.      DORIS, An Introduction to Scientific Data Retrieval. Used as an example chemical data from my Ph.D.
4.      DORIS. Problem Solving. Showed how a New Scientist “Tantalizer” puzzle could be coded as an example of heuristic problem solving.
5.      DORIS. Sales Accounting. Based on the type of application I had worked on at Shell-Mex & BP.
6.      DORIS. The Effect on Hardware.
At the meeting I presented my ideas to Stern, Lowe, Iggulden and Bye (all Marketing, Computer House), Hold (Marketing, Kidsgrove), Ball (Product Planning, Kidsgrove), Meredith Smith (Research, Minerva Road), Trott (Training, Radley House) and Hoare (Elliot Automation). At the end of the meeting the future of the idea was discussed[17]. Mr.Hoare suggested that a simple design exercise be undertake to see whether such a system could be designed in practical terms and also to see what problems would be involved. John Meredith-Smith noted[18] that “Mr. Reynolds is the best man to do this work.” He added “I do not see how he could work for Mr Stern who still does not understand the idea.”
As a result of this meeting I drafted two further documents, the first outlining how the preliminary investigation should be carried out, and the second relating CODIL to a data base design approach mentioned at the meeting.
·       DORIS. Pilot Program Project. Terms of Reference[19].
·       DORIS. A Comparison with the Relational Data File[20].

4      Seconded to Minerva Road

As a result of the above meeting[21] it was agreed that I should move to Minerva Road for 1 or 2 months, under the supervision of John Meredith-Smith with a view to answering the following questions
1.    What are the basic underlying objectives of the idea?
2.    How can these ideas be expressed in the clearest way?
3.    Are the ideas applicable and useful in any particular case?
4.    What are the prospective benefits in time, cost and convenience of organizing data and program in this special way?
5.    (later) What practical proposals can be made for implementing the ideas (perhaps by stages) and what are the likely costs and benefits of each stage?
After about 2 months I returned to Computer House[22], and the final version of may main report - A Description of DORIS. A Data Oriented Information System was issued from Advanced Systems, Marketing Division,under a “Highly Confidential” tag on 2nd April. The abstract reads as follows:
This report examines the problems of data processing and suggests that many of these arise from the limitations of existing programming techniques. To circumvent these difficulties a radically new approach is suggested. DORIS, a Data ORiented Information System, combines a decision making algorithm with a specially designed file structure" By incorporating a file control package and links to a library of standard subroutines it is possible to have a general purpose data processing program which could be permanently resident within the compufer system. As seen by the non-specialist user DORIS makes decisions in a way similar to a human clerk, using a series of easily understood statements to control its its work. The statements are held so as to give flexibility, comprehensibility and economy in file size There is no equivalent in the DORIS system to the conventional application program and a successful implementation of the system might eventually lead to the virtual demise of the commercial programmer. However conventional files and programs can be used within the system if required,
Because of the wide implications of the system it is inappropriate to try and describe all aspects of this subject in a single report. This report describes the basic decision making algorithm and the associated data file. It also describes the far reaching economic implications of the system and, in general terms, the work needed to implement it. A second report describes a number of applications which can be implemented using DORIS" These include scientific data retrieval, invoicing and problem solving. Housekeeping matters concerned with file organization and input/output are also considered" A brief note is included on the way in which DORIS should make large scale Integrated Management Information Systems a realistic proposition.
This report was followed by two further lengthy reports - An Some Examples of the Use of DORIS Outline Specification of the DORIS Pilot Program[23] and[24]. This last report included a section specifically on complex systems[25]:
When specifying conventional programs the systems analyst has to consider ail possible interactions between variables and hence define the "lowest common multiple" of the system. As the problem increases in size and complexity the difficulty in defining it increases at an even faster rate. As a result the system becomes logic bound and improvements are only made by increasing expenditure on specialist staff and equipment.
The approach when using DORIS is completely the opposite. His [The systems analyst] job is to provide a basic skeleton for the system (a highest common factor) and the flesh is added by the appropriate ‘specialist’ in the application being tackled. This suggests that for a given degree of systems effort the size of problem that can be tackled using DORIS should be very much bigger than would be the case if conventional coding is used.
This immediately suggests that  DORIS should be of great value in systems such as the much talked about Integrated Management Information System. Attempts to design such systems using existing techniques run into many troubles and there is no doubt that many data processing managers in this country believe that the IMIS is a fictional beast. Because of the interest in such situations. It is hoped to produce a full report on the subject later this year.

5      Work on the Pilot Program

As the above mentioned reports started to appear in their final form things were starting to happen at a high level in the company. On 21 March 1968 George Stern wrote[26] to John Pinkerton, Research Director of EEC, about “Patent Cover for DORIS.” Interestingly the letter was signed by David Caminer , Marketing Director of EEC, so must have had his approval.
As you know, DORIS, if fully successful, could give a saving to the computing community of the world measurable in hundreds of millions sterling p.a. For this reason we have to give thoughts to protecting the rights of E.E.C. …
If I remember correctly the figure was a back of an envelope calculation along the following lines.
1.    The potential market for large commercial computers in 5 years time (1973) could well be approaching a billion pounds a year.
2.    One of the big problems in using such systems using conventional software is that they tend to be inflexible and unfriendly.
3.    DORIS is being designed to provide a flexible and human-friendly interface.
4.    If it works it is not unreasonable to think it could help the company capture 10 or 20% of the market.
5.    The calculation did not explicitly consider the possibility of many online terminals (there were virtually none in 1968 commercial systems) and the fact that a user-friendly language could be very important as a terminal interface.
While the basis of the calculation was quite crude, it was not unreasonable, and with the benefit of hindsight might be considered quite conservative. After all if the work had not been dropped by ICL, the early 1980 personal computers might have ended up with a user-friendly CODIL-like operating system, rather than MS-DOS.
I don’t know when the decision was actually taken (presumably at Board level) to make DORIS a properly supported project with a budget of, I think, £50,000, but on 3rd May 1968 John Aris, Manager, Applied Systems, circulated senior managers within E.E.C. telling them about DORIS[27], and pointing out that it should not be discussed outside the company. He described it as follows:
DORIS, a 'Data Oriented Information System', is an original and radically new approach to the systems/programming of computers, devised by Dr. C. Reynolds, of this Department. It involves holding a large proportion of the decision-making logic, normally built into user programs, as part of the data files, and analysing it not with a variety of special application programs, but with one general purpose decision making routine. If this proves viable it could result in the virtual demise of the conventional application program in many fields, replacing it by the said general purpose routine and groups of calculation routines. Its data structure, being closer to the ordinary modes of human thought than computer files generally are, could allow the ultimate user far greater freedom to use the computer as an information handler in a familiar way, and without the need for expensive commercial programmers. This would, among other advantages, ease the implementation of management information systems. A further important consequence could be a new approach to CPU design.
In June a meeting[28] was held to discuss DORIS and Caminer was convinced there was something worth following up. In August there was a meeting[29] at Stevenage to discuss possible links between CODIL and the work of J K Iliffe on the Basic Language Machine[30].
Two shorter reports followed later in the year. They were A Comparison between DORIS and Conventional Techniques and The Limitations of Existing Computer Techniques[31]
There was a management change on the 8th September, when the project officially became part of the Research and Advanced Development Organisation. Effectively I moved from Marketing, under George Stern, and reported to John Meredith Smith, who was based at Minerva Road. In addition I gave a presentation to Basil de Ferranti. The programming of the project was well underway and by the end of the year Stage 1 of the implementation had been completed – which involved setting up the file handling software and producing some example files.[32]
For various reasons the name DORIS was considered unsuitable and from the 1st January 1969 the project became CODIL – for COntext Dependent Information Language. Later in the month a report briefly describing the project was issues, and revised versions, with updates, were produce later in the year[33]. To back up the October reissue a demonstration run was prepared simulating an online session[34] in which a series of very different CODIL test applications were demonstrated[35]. This was followed in November 1969 by a computer produced “An Introduction to CODIL”[36] which included small demonstration application relating to Houses for Sale, Railway Timetable, The Forsyte Family Tree, Scientific Data Retrieval and other data retrieval problems, problem solving (a New Scientist Tantalizer), Simple Calculations, Pricing Orders, and Systems Control.

6      The Project within ICL closes down

Initially I was not aware of the danger that the CODIL project was in as a result of the merger to form ICL, possibly because I had remained working in Computer House, Euston, after I had officially become part of the Programming Research group based at Minerva Road.  What was happening at the top of the newly formed company was a dispute about the way forward. At the time of the merger English Electric Computers had a full order book and International Computers & Tabulators (ICT) was struggling.  The new board decided that the ICT 1900 series of computers should be phased out in favour of the EEC System 4 computer – but reversed their decision, possibly as a result of government pressure, and most of the original EEC board, which had supported CODIL, resigned. While the new director of research was Basil de Ferranti  he had been managing director of ICT and, in retrospect, the downgrade of his status was a strong hint that he should take his services elsewhere, and he ceased being a director sometime after I had left ICL.
I was initially reassured that the project would continue in some form, but the danger signs were there to see. One important event was a formal presentation that Basil de Ferranti asked me to give to the other directors on the company board. This was prepared – but the only director to turn up was Basil himself. One director had someone to represent his division and at least some of them had the decency to send their apologies. Clearly this was a very clear thumbs down from the ICL Board and almost certainly was intended as a sign to Basil that “his bright ideas were not wanted.” I am sure that this rejection had nothing to do with the merits or demerits of CODIL, but was more to do with company internal politics and the decision to throw everything behind the 2900 series of computers.
In September 1969 Basil wrote to P D. Hall and L. Lightfoot[37] saying:
One of the significant projects which was under way at Minerva Road, and which came to the Research Department originally from the EE Sales side, was based on a new approach to modularizing customer software.
Called CODIL the technique has a number of supporters and would appear to be not only a useful product in certain well defined areas, such as oil product distribution centres, but also to carry an underlying principle which could be applied in many areas, The key figure in the development of CODIL was Dr. Reynolds and the question really is whether or not we wish to retain his service. Clearly if there is merit in CODIL we would wish to but if the company doesn’t wish to take it up I think it improbable that he would wish to stay.
I have seen nothing to suggest that anything was done at the time to follow this up but in February 1970 two very short reviews (both on the same side of a single page of A4) assessing CODIL were written – but which I did not see at the time. Both were by people who I had never heard of and who had not contacted me for further information (I would have only been an internal phone call away). I have no idea what CODIL documentation had been passed to them, but it is obvious they had not seen the report “A Comparison between DORIS and Conventional Techniques”. Neither of them seemed to have understood that CODIL was set up as a research project and not a “nearly ready for the market” package..
The first report[38] , by G. C. Sibthorpe, starts “Although I am not very familiar with CODIL …” and then inappropriately compares it with a system specification language called SPECOL, because he failed to realize that CODIL was aimed at users, rather than systems analysts and programmers. The second review[39], by A. F. Besley, also compares it with what I assume was a systems development aid – and again failed to recognize the nature of the users for which it was designed, or to understand the complex problems it had been designed to tackle. However he recommended publication as “The CODIL project has achieved some practical results and I am sure we would loose nothing by airing these in an article.” As far as I can see these two superficial reviews were the final nail in CODIL’s coffin, as far as continuing the research at ICL.
Up till about this time my position was difficult, especially as the research group at Minerva Road had been disbanded and staff (including my programmers) were leaving the company or moving to other duties. Basil de Feranti had said he wanted the research to continue, and John Pinkerton (now no longer a director) clearly considered it would be a great shame if the reseach was abandoned. If a new home could be found within ICL I would have been very happy.
While I realized the research was interesting, I had only worked with very large commercial computer systems and was not really able to assess the importance of the project on a wider industry basis, or its relevance to academic studies relating to the theories underlying computer science. In addition details of the project was supposed to be confidential, at least until the patent had been finalized, and if I tried to move the research elsewhere there could be real difficulties as to who owned the rights. These factors made it difficult for me to just up sticks and continue the research elsewhere. The fact that publication would be possible clearly eased the situation
When John Pinkerton suggests that I write up a paper for publication, and it might be possible to move the project (unfunded) to a university (but not a rival computer manufacturer) I was very interested[40] and happily went along with the publication plan. Work started immediately and it was arranged that I should give a talk to the British Computer Society Advanced Programming Group on 14th May 1970, and the handout I prepared was reprinted in the Computer Bulletin[41]. 
A more detailed paper[42] was prepared for submission to the Computer Journal, concentrating on CODIL as a programing language and how it was implemented. Detailed discussion about the factors underlying the design of the human interface or references to the original design study at Shell-Mex and BP was ruled out for commercial reasons. The reasons for there being a hardware patent were also played down. Basically the paper was written in a way that did not make claims that could embarrass ICL’s decision to close the project down.
Over the last few months at ICL I made sure that I had computer listings of all the relevant programs and test applications, while technically reporting to a manager at Stevenage who, I think, I never actually met. However there was one very significant incident during my last month. I got an invitation to give a talk on CODIL to an internal seminar on research on unusual computer processor research, the other presentation being by J K Iliffe on the Basic[43] Language Computer research at Stevenage. The meeting was in a Ferranti research laboratory at Bracknell on the day before I was due to leave ICL so I agreed to go.
The seminar was very interesting and my talk caused a lot of interest as it was the first time anyone had actually made proposals for modifying a central processor to make it easier for normal human users, as in the past all processors had been designed to make them easier to write procedural language programs. There was also surprise as to how and why the CODIL project had been abandoned why their research division had not been told it was under threat. I was also very interested in hearing about the Basic Language Computer research, as while the approach was very different, some of the hardware solutions could also be relevant to CODIL, and I left the meeting full of ideas about how the CODIL patent could be made very much stronger.

Just over a week later I was free of ICL and presenting a paper on CODIL[44] at the Conference on Man-Computer Interaction at Teddington.

A follow up document is being prepared about the transfer of the project to a University environment

[1] The report (dated 30th September 2018) has been written as a first draft for the Archives of the LEO Computer Society. The source (in addition to memory) are the folders of published reports which I hold, supplemented by correspondence relating to the establishment of the CODIL project in the ICL Archives held in the Science Library, Swindon. If appropriate, information from other bulky correspondence files, working notes, and original program listings can be added, with further links to digitized copies of the original documents.
[2] An account of my activities, The SMBP Story, at Shell-Mex & BP, including details of the work that triggered the ideas behind CODIL, has been prepared for the archives of the LEO Computer Society.
[3] At the time I joined English Electric Computers in 1967  it was a merger of a number of different computer companies, as English Electric Leo Marconi, and in 1968 it merged with International Computers and Tabulators (ICT) to become International Computers Limited (ICL).
[4] George Stern has never understood CODIL (or DORIS as it was first called) but was very important in the early days of the project as I am not  particularly good at networking – and if I had a problem he knew exactly who within EEC I should contact. This help ceased once the two companies merged and I officially reported to John Meredith Smith, at Minerva Road, while I was still based in Computer House.
[5] The System 4 computers had the same instruction set as the IBM 360 computer series.
[6] The Leo 326 was the top of the range Leo computer, the Leo I being recognised as the first prupose-built commercial computer.
[7] One of my tasks related to filing and indexing internal company documents relating to possible chemical agents for use in veterinary practice throughout the world. This was potentially very complex as it was not clear how files would develop. Each project started off as a small folder which expanded until it was considered non-commercial (usually very quickly) or could become very larger. In one case where a project went to market world wide I estimated the number of documents would occupy several filing cabinets. I spent some time looking at how this might be handled
[8] What was interesting was how little data processing managers had thought about the future. It was clear that they were all struggling to get the best out of the present batch systems and that was their priority. The stock answers were all bigger and more powerful computers, with better high level languages and operating systems. Some recognised that computer terminals and online operations might become possible but had not thought about it in any detail. The most noticeable exception was Wesley M. Davies, of the Steel Company of Wales, Ltd., who was concerned with interfacing complex real world problems with computers (in their case payroll and complex “who does what” trade union contracts)
[9]  I was part of the IMIS subcommittee of the Diebold Research Program and my files showed that I contributed the data dictionary subsection to the Common Data Base Report which was published in the later part of 1969. The work was linked to some of the work of the CODASYL committees in the United States.
[10]  Real Time Data Logging and the Security of Information. Systems Techniques Notes No 2, by Dr C Reynolds, English Electric Computers, 9th January 1968.
[11] Some questions on a visit to the Engineering side at Kidsgrove about the System 4 processor hardware made me realise that associative addressing – rather than addressing by numerical position – was possible. This lead to further questions about how the instruction set was implemented.
[13] Memo: Reynolds to Aris, Doris (Data Oriented Information System), 19th October 1967
[14] The last thing in my mind when I wrote this would have been brain science, artificial intelligence, or psychology. I was simply being a systems analyst faced with a problem - Humans appear to do things this way, so if you want to build a system that works with people build a system in a way that they will  find it easy to interact with.
[15] Memo: Stern to Pinkerton, DORIS, 25th October 1967
[16] Memo: Meredith-Smith to Pinkerton, DORIS, 14th November, 1967
[17][17] Diary Note: By d. Loewe, Notes of a meeting at Computer House on 1st December, 1967, 6th December, 1967
[18] Memo: Meredith to Pinkerton, DORIS, 4th December, 1967
[19]DORIS. Pilot Program Project. Terms of Reference 13 December, 1967 – a one page summary outlining how the material in the reports written for the 1st December meeting could be implemented.
[20]DORIS. A Comparison with the Relational Data File” 12 December, 1967 – This commented on the paper “A Computer System for Inference Execution and Data Retrieval” by R. E Levin and M E Maron, Comm. ACM Volume 10 pp 715-721, November 1967. The note points out  The R.D.F. is used for storing information in retrievable form, and unlike DORIS uses conventional programs to read it.”  It should be noted that there was no similarity between the R.D.F> and Codd’s Relational Data Base.
[21] Memo: Stern to Pinkerton “Terms of Reference for Study of DORIS”, 4th January 1968 (misdated 1967)
[22] There is no doubt that I found it very difficult to commute to Minerva Road, and the fact that I did not return there when I was finally transferred full time to Research was because a decision had been made to close down the site.
[23]An Outline Specification of the DORIS Pilot Program” 22 May, 1968. This contained a specification for a program to test that the ideas underlying CODIL actually worked, and a 4 stage implementation program. By the time the project was finally  closed down all stages in the implementation program had been completed satisfactorily.
[24]Some Examples of the Use of DORIS”  28th June, 1968. The report included examples of scientific information retrieval, commercial data processing and problem solving. It also discussed t he internal management and input/output of data.
[25] It is relevant to note that I was employed by English Electric Computers to do market research on future requirements of very large commercial customers, and this work involved talking to senior management in large existing installations so I was well aware that the problems I had seen at Shell-Mex & BP were not unique.
[26] Memo: Stern to Pinkerton, Patent Cover for DORIS, 21st March, 1967.
[27] Memo: John Aris to long circulation list: DORIS, 3rd May, 1968
[28] Memo: Stern to Pinkerton, DORIS, 14th June, 1968
[29] Memo: Stern to circulation list, Meeting at Stevenage to discuss DORIS, 13th August, 1968
[30] See J K Iliffe, Elements of BLM, The Computer Journal, Volume 12, Issue 3, 251-258, August 1969
[32] Progress Report on Work of the Programming Research Group, Acton Laboratories: Report on CODIL. January 1969
[33] CODIL. A Language for Handling Complex Data Processing Problems. Initially issues 30the January 1969, 3rd issue 6th October 1969.
[34] I had no access to computer terminals of any kind, and simulation runs assumed a teletype terminal.
[35] Photocopy of computer listing headed CODIL Job: Simulated Run using Printer and Card Reader, dated 26th September.
[36] Photocopy of computer listing headed An Introduction to CODIL, dated 9th November, 1911
[37] Memo: de Ferranti to Hall & Lightstone, [re CODIL], 8th September, 1969
[38] Short note by Sibthorpe, CODIL, 4th February, 1970
[39] Short note by Besley, CODIL, 6th February, 1970
[40] It is planned to write a follow up memoir dealing with the move to a University.
[41]CODIL,” The Computer Bulletin Volume 14, pp 244-245, July 1970.
[42] Published (with some amendments) as “CODIL: Part 2: The CODIL Language and its Interpreter”, Computer Journal Volume 14,pp 327-332, November 1971.
[43] Not to be confused with the programming language BASIC.
[44] CODIL,” Conference on Man-Computer Interactio Teddington, 2-4 September, 1970. In proceedings, “IEE Conference Publication No 68, pp 211-216. 1970

No comments:

Post a Comment