The Editor of Centrist

     Dear Sir,

     The cautionary tale of IDMS makes sad reading; so much effort by a
large proportion of the database group for so long has yielded so little.
The conclusion - namely throw out EMAS and its 5000 mostly satisfied users
so that the handful of IDMS users can have a better service - does not
follow from the narrative.

     The IDMS project was a political project to extricate management from
commitments it had given based on (unbelievable) promises from ICL which
had not and could not be honoured. To move a large piece of software, very
operating system intimate, between two very different systems is immensely
difficult even at the source code level. When part of the package is only
available as object code the task is manifestly impossible. There were,
are and always have been more cost effective ways of providing such
facilities to the small number of users who require them.

     The decision on 2972 replacement with another EMAS machine (using the
same system - there is no intention of writing another!) is a different
question.  A manufacturer's maintenance procedures are rarely quick or
effective and a team is required to stand between the service and the
support organisation. Full documentary evidence is normally required,
often including dumps and panel status reports; this will involve
interrupting service for many minutes for faults which would not normally
crash the system. The corrections, when eventually received, are not
without side effects; remember the agonies of REP testing? All the ERCC
can do is to keep passing on the bugs. There is no cure when the
manufacturer "mends" the bug by changing the product specification, as has
happened frequently to Pascal, the only manufacturer maintained item in
EMAS service. This procedure is openly despised by Cookson et al when
applied to Kent products on EMAS, yet Kent are much more helpful than any
manufacturer's that I have dealt with; in particular Kent accept and cure
bugs from a verbal description over the telephone. The fact is that EMAS
support is so good that even good offsite support (Kent) looks third rate.
What evidence is there that any support is available that meet the
demanding standards of Cookson et al? How many manufacturer's maintenance
teams would even accept a user demand to write a one-off tape utility for
a minority user group and how quickly would they respond?

     The arguments against EMAS are being shouted from the roof tops; here
are some of the arguments for EMAS:

       1) EMAS is efficient. It takes about three times as much installed
       power to support 100 users on the best manufacturer's system (VMS)
       as it does on EMAS. Currently DEC hardware is about one third the
       price of ICL hardware but a further EMAS machine is conditional on
       ICL Fujitsu hardware that is competitive in price.

       2) There is a great volume of user software for EMAS.  I am sure
       that Cookson and Hinxman consider it a great and beneficial
       experience for users to have to rewrite their programs for another
       machine. The users themselves might think differently.

       3) EMAS requires minimal management.  One man runs the 2972 service
       since EMAS was designed for open shop, open network working. No
       other system at present is so designed; most operating systems
       require guidance from a human manager in a lot of situations that
       EMAS handles automatically;  archive and restores for instance. If
       EMAS was replaced by 20+ VAXs then all the EMAS team and others
       would be sucked remorselessly into machine management. There would
       be no "redeployment of expertise".

       4) Manufactures software maintenance would be much worse than
       current EMAS maintenance.

       5) With another system (Multics alone excepted) for many users
       working in the areas EMAS was designed to cover the service would
       be worse, for some much worse.  Others, such as IDMS users, would
       be better catered for.

       6) EMAS maintenance is minimal and cheap.  If one removes the
       service support persons from the EMAS team (since these would be
       required regardless of the authorship of the system), the
       maintenance staff are less than half as numerous as the database
       group yet the work is relevant to far more users. No one has yet
       suggested abolishing the database group to release persons to
       enrich the software environment; but note that the adverse effects
       of such a decision would affect far fewer users than anything
       suggested by Cookson & Hinxman. More staff would be available for
       redeployment also.

       7) There is a moral issue. Interactive computing is here to stay
       and the technology used to build EMAS can be used by somebody to
       build much more cost effective interactive systems. This should
       eventually be of importance to the national and international
       industry. Should the University abandon EMAS because of the cost
       which is miniscule in relation to the sums being spent
       nationally?  If so the lessons will doubtless be relearnt in
       time probably in Japan.

     However the decision will be made on purely political grounds and
hence Cookson and Hinxman are doubtless wise to throw mud. Even grossly
erroneous mud can be comprehended by the sort of committees that will
influence the decision. The technical reasons that make EMAS such a
fine operating system require study to appreciate. Since even the
computer experts at George Square do not seem to have read the EMAS
Papers and do not even seem to know that 2 of the Papers have won
prizes how can we reasoably expect busy non specialist committee
members to put in the necessary hard work?

                                        Yours,
                                           P.D. Stephens