|
| JohnMurison |
UserPreferences |
| Edinburgh Computer History | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents | moin.sf.net |
I joined the Edinburgh Regional Computing Centre (ERCC) in 1968, and the EMAS team in 1979, initially on secondment to write the EMAS 2900 User's Guide. However I remained in the team until I left the computing service (by then called EUCS) in January 1990. For nearly all of my time as a member of staff at Edinburgh University I was a user of EMAS, and for ten years was actively involved in the support of the system.
When the Editor asked me to write an obituary for EMAS I was honoured, but somewhat apprehensive of doing justice to the work of so many first rate predecessors and colleagues. My memories have been stirred by looking at the notes and papers relating to EMAS, and although (as Katherine Mansfield said) regret is a useless emotion, only fit for wallowing in, it is nonetheless difficult not to feel sad at the passing of so technically competent a piece of work.
It should be understood that with the closure of the EMAS-A service this summer, a system which goes back to the late 1960s and has had three implementations is being laid to rest. It would be wrong, therefore, merely to deal with the last few years. However, to go back further entails reference to what are now historical documents, written by a small group of people. Are they reliable? History has been described as a 'distillation of rumour', as 'fables that have been accepted'. Nevertheless, I feel that the best way to give the flavour of these years is to quote directly from the available sources.
'The Edinburgh Regional Computing Centre (ERCC) was set up as a result of the recommendations of the Flowers Report of 1966. The ERCC was intended to become 'a centre of excellence in multi-access computing'. Little guidance was given on how this desirable state of affairs was to be achieved, but since the Centre was to be equipped with an English Electric Leo Marconi 4-75 computer for which there was no multi-access (MAC) software, some sort of do-it-yourself scheme was necessary.' 1
'Between 1966 and 1970 a large University/Manufacturer team attempted to write a multi-access operating system for ... the System 4-75. This project, the Edinburgh Multi Access Project (EMAP), which was organised on conventional lines with managers, team leaders, designers and programmers, together with a selection of technical and coordinating committees, failed to implement a system. ... Thus in 1970 Edinburgh University was left with a lot of hard earned experience and a System 4-75, but no operating system. A small team varying between 3 and 7 set out to implement a system to the original specification (minus certain 'marketing' additions), salvaging anything relevant from EMAP and writing the rest. Within six months a pilot system was running and in a year it was the prime service vehicle. ... The lessons of the EMAP project had been learned.' 2
From the beginning the importance of efficiency within the operating system was stressed, and only facilities which could be implemented efficiently were offered: 'If good MAC performance is required, the system fundamentals must be adequate; piling attractive facilities on top of unsound foundations is likely to give a sluggish and unsatisfactory service.' 1
EMAP was led by Mr (now Professor) Harry Whitfield of the Department of Computer Science. The EMAP work started about a year after M.I.T.'s Project MAC, which led to Multics. Unix (the name is a pun on Multics) did not appear until the early 1970s. It is significant that all three operating systems were implemented in high-level languages: PL/1 for Multics, IMP for EMAS and C for Unix. From the beginning, the importance of the implementation language was appreciated:
'The EMAS general purpose time sharing system is notable for being coded entirely in IMP, a high level language, which was developed from Manchester University's Atlas Autocode specifically for system programming. In 1966 [Atlas Autocode] was widely used in Edinburgh University and a compiler (Bratley, Rees, Schofield and Whitfield, 1965) had been written for the University KDF9. This compiler ... was in advance of its time in that it was entirely written in Atlas Autocode. ... For System 4[-75], the compiler was bootstrapped from the KDF9 compiler via assembly language. ... This compiler was also bootstrapped onto the IBM 360/50 (Yarwood, 1970). The early EMAS components were compiled on the manufacturer's J level operating system and transferred to the EMAS system as binary magnetic tape. The Release 8 [IMP] compiler produces about half the amount of object code that Release 1 produced for the same program. Release 8 object code is rather more than twice as fast as Release 1 object code. Since the compiler is written in IMP, compiling speeds have increased similarly. These figures enable the four months spent hand coding analysis routines to be seen as the waste of effort it undoubtedly was.'
'All members of the EMAS project agree that working in a high level language was a great advantage. The volume of coding was greatly reduced - a listing of all the system source code will fit in an average briefcase and still leave room for sandwiches.' 3
Throughout the life of EMAS, anxieties about lack of marketing know-how surfaced from time to time:
'It remains the implementor's conviction that the language would have aroused wider interest if it had been christened Implementation ALGOL or ALGOL(I) rather than IMP. ' 3
It is easy to forget how innovative (in the late 1960's) EMAS was:
'... a paging system based on a thorough-going use of the working set model ... has been implemented for EMAS, a system developed ... by a team led by H. Whitfield at Edinburgh University. It is of interest in that it uses a local, as distinct from a global, paging policy. ... A consequence is that each process is able to operate within the number of page-frames allocated to it, and the misbehaving of one process cannot affect other processes.' 3
'The only method of file access allowed on EMAS is 'connection': when Director is asked to connect a file it associates it with a free area of virtual memory and reports its size and address. Accessing the addresses accesses the file directly - the file and address space are one and the same thing.' 1
'The command processor interprets each command as a call on an external routine with that name. The standard subsystem commands are implemented as a collection of external routines, to which a user may easily add.' 5
The development of EMAS continued after the system was formally handed over to ERCC and a service started in Autumn 1972. One notable piece of research was based on the Edinburgh Remote Terminal Emulator (ERTE), which measured various system parameters under carefully simulated user load conditions:
'For several years, the early hours of the morning would find EMAS and ERTE locked in near mortal combat, while the afternoons would find researchers and system designers puzzling over the results, and planning the next experiments. The outcome of this effort was both humbling and rewarding: humbling because it revealed how little system staff knew about what went on in a (relatively simple-minded) MAC system like EMAS; rewarding because it eventually became possible to isolate the few factors that were crucial to system performance from the many which might have been expected to be important but which were not.' 1
The ERTE work was started by one of the original EMAS designers, Alex Wight, of the Department of Computer Science. He was also responsible for another notable EMAS feature - the archiving system, which has proved to be so important in giving continuity of service for 20 years.
EMAS went into service in Autumn 1972. The 4-75 was capable of supporting 35-40 terminals with some batch work. By 1974 the system was overloaded and a second 4-75 was acquired; but it too became overloaded quite quickly.
The Regional Computer Organization (RCO), comprising the Universities of Edinburgh, Glasgow and Strathclyde, accepted a tender from ICL to provide an ICL 2980 running the operating system VME/B, on the understanding that the machine would pass a fairly demanding benchmark within about two years.
'When the time for the benchmark ran out, ICL announced that it was in default and proposed some reparations. ... Edinburgh emerged with a 2970 computer ... The only way to service more than 20 terminals on a one-megabyte computer would be to move the EMAS operating system from the 4-75 environment.' 1
Because the hardware was quite different, and because experience led the systems design staff to wish to improve on version one, a number of radical changes were made when EMAS 2900 was implemented.
' The EMAS re-implementation project has been informal in organization, small in size, and relatively short in duration. It commenced in October 1976 with the intent of demonstrating a system by June 1977, and generating a first release by April 1978. The project has had ten members.' 6
'The communications on EMAS [4-75] had been overtaken by events during the eight-year life of the system. The design used ICL's multiplexor (the Multi-Channel Communications Control Unit) ... Later the MCCCU was replaced by a Front End Processor but the essentials of the software design were the same. The design worked well when all terminals were operating at ten characters per second. What had not been foreseen was the great increase in terminal speed and hence I/O in a terminal session; a further surprise was the attraction of EMAS's secure file system. Programmers using machines in Newcastle, Cambridge, Harwell and Manchester kept their programs and data on EMAS and transmitted them daily. The amount of paging traffic on EMAS concerned with trivial buffer filling and emptying rapidly became insufferable. A radical rethink was required ...' 7
'The critical new [comms] feature in EMAS 2900 is that communications traffic is transferred directly between non-paged devices ... and files, rather than between these devices and real memory buffers.' 1
'The hard core of the implementors [of EMAS 2900] deserve special mention for their efforts. They were [D.J.Rees, P.D.Stephens,] J.K.Yarwood and N.H.Shelness, together with the able assistance of W.A.Laing, R.R.McLeod and F.Stacey.' 8
The following quotations are taken from the EMAS 2900 project newsletter:
'Sandy [Shaw] has been taking an interest in developing better MAIL facilities. He went to a seminar given by a speaker from Xerox PARC. He has now written a brief paper proposing an experimental MAIL handling scheme, with a view to implementing it initially on the two Edinburgh EMAS systems.' (9/6/80)
This was the beginning of the superb EMAS mail facilities.
'[Dr Thomas, ERCC Director] was keen that EMAS should adopt FTP. The code necessary was to be added to SPOOLR [EMAS executive process]. The implementation was to be done by JH [John Henshall].' (6/3/81)
Concerning the amount of traffic which John's FTP implementation eventually supported, see the quote from 10 at the end of this article.
The ICL 2980 located at Bush estate switched to EMAS 2900 on 1st January 1980. This was the same date as the University of Kent at Canterbury decided to switch its ICL 2960 computer to EMAS 2900 from VME/K.
'Around the Sites: [17/6/80]
2970: The hardware has continued to be unreliable ...
2980: The 2980 has received the System 4 users without any noticeable increase in hardware faults, but is groaning under the strain. The batch queue typically has 100 entries by 1200 [hrs] and 150 by 1700 hrs. The main problem is on-line file space - there are about 1500 users, each allowed at least 3Mb of space - about 100 users have been allowed much more space - up to 32Mb each! To provide this space requires 5000Mb of disc on-line yet the configuration allows us only 2200Mb. The crunch will come in the next 3 weeks!
2960 [University of Kent at Canterbury]: Bob Eager has got supervisor 26C and all related software into service.'
The occasional appreciation from users was always welcome:
'I'm off to the States this weekend after 3 years in Edinburgh. I've used the 2970 and 2980 services a lot ... and have grown very fond of the system. So this is just a thanks to all the people behind the terminal who have helped out. Best wishes to you all and success with the dual 72 systems.' [26/9/80]
'Peter [Stephens] reported that [Dr Thomas] considers it worthwhile to pursue the EMAS-IBM work; time is available on the NUMAC 370/168, on the Amdahl at Leeds University and on a 4331 at Falkirk. Peter himself was working on an IBM IMP80 compiler.' [EMAS 2900 Project Newsletter, 9/9/81]
'By 1984, it was clear that ICL would not provide a suitable 2900 hardware base which could host EMAS on their future range of products. Hence the EMAS-3 development was undertaken, to re-implement EMAS on hardware which would have long-term availability and not depend on a single manufacturer. The architecture chosen was IBM XA.' ^9
'The [EMAS-3] software was written by the EMAS Support Group involving, over the period, Tony Gibbons, Susan Harrower, Stephen Hayes, John Henshall, Colin McArthur, John Maddock, John Murison , Graham Rule, Sandy Shaw, Peter Stephens, John Wexler and Keith Yarwood. Front End communications software was written by Brian Gilmore and Peter Kirkby.' ^9
'When I handed over responsibility for the Subsystem to John Wexler I retained an interest in the special version for undergraduates. As an aside I realise that I have been involved in special features for undergraduates since 1969. In that year Peter Schofield introduced the quaintly named routine 'FIDDLE MY RANDOMS'! [Roderick McLeod, EMAS 2900 Project Newsletter, 9/9/81 ]
Roderick McLeod played an important part in the support of EMAS, particularly the Subsystem. His final task at ERCC, before departing for the Orkneys in 1986, was to write the preliminary edition of the EMAS-3 User's Guide.
A feeling had been growing throughout the 1980s that Edinburgh's computing facilities, once at the forefront, were now being held back by the retention of a one-off system which had been designed to squeeze the maximum work out of scarce resources. These resources (primarily CPU power, main memory and on-line backing storage) were no longer so scarce, and the EMAS design aims were no longer relevant. Furthermore, the EMAS user interface was based on a command line dialogue approach, and assumed a relatively low bandwidth between the user's terminal (screen) and the CPU driving the system. A good graphical user interface requires a lot of CPU power to sustain it, and this is best provided locally.
I don't entirely go along with all this, but it is significant that when I asked Sandy Shaw, Bob Eager and Peter Stephens (May 1992) what they thought the main shortcomings in EMAS now were, they all mentioned the user interface, which could and probably should have been given more attention at the EMAS-3 stage.
However, in the mid-eighties a number of arguments of doubtful technical validity were being tossed around, and a fair amount of heat was generated. I will not attempt to rehearse these arguments (which so infuriated Keith Yarwood in particular), because there is now little purpose in so doing. However, in the Computing Strategy report (June 1989), one of whose purposes was to explain how the University would manage without EMAS, a handsome bouquet was presented to the service:
'The consultations carried out over a two year period prior to the definition of the strategy were the most extensive ever in Edinburgh. ... The aim is a more integrated distributed environment, based on a high speed network. This will involve the adoption of standards which will mean the end of the EMAS service ...
'The EMAS service has been running on the NAS [EX/40] system since the middle of 1988, having replaced the Amdahl 470 series equipment which in turn replaced the ICL 2900 machines . .. EMAS has been the main provider of large scale, general purpose computing in the University of Edinburgh for over fifteen years and it is not surprising, therefore, that its use is widespread in all of the main departmental groupings and faculties. The strengths of the service continue to be its exceptionally effective use of system resources ... Despite the growth in distributed and departmental computing, the demand for the EMAS service has remained high with new undergraduate courses replacing those which have moved to departmental or faculty funded micro laboratories.
'Overall, EMAS ... supports peak simultaneous user loads of over 200 from an accredited population of 6500 users. Over 4000 interactive sessions are supported per day in peak term-time conditions with 1100 individual users active in a day. In addition some 400-500 batch jobs are processed each day. ... [A] major growth area ... has been in network-related services: some 2200 mail messages are delivered to EMAS users daily, requiring 1600 transfers with other hosts; in all, 2000 file transfers are performed daily involving 30 Megabytes of data; device spooling accounts for the dispatch of 2200 documents per day to 120 remote printers totalling 50 Megabytes of data.' 6
Bob Eager, whom I have mentioned before, currently has a project - admittedly at home - to put EMAS on a 386-based machine (8 Mbyte, 3 Mips). As he pointed out, this is a vastly more powerful machine than the Kent 2960 with its 0.3 Mips, which nevertheless could support 40 users. ('Oper would be on the screen, comms through the parallel port.')
More significantly, even in this time of incredibly powerful workstations, there are many lessons to be remembered from the EMAS experience. Developing a system and providing a service to users at the same time may seem administratively untidy - but each activity benefits from the other, and it works. Perhaps one needs people like Roderick McLeod and Andrew McKendrick around to keep the users' needs uppermost, but we were fortunate enough to have such people.
Finally, it is still well to remember Peter Stephens' remark about piling attractive features on unsound foundations. Economy and elegance are always worth striving for. The designers of EMAS knew that, and it is a lesson that all programmers should remember.
