It is now close on two years since Ferranti came to the conclusion that implementation of NEBULA should proceed, and that COBOL should be ignored, at least for the time being. The NEBULA compiler for Orion is nearing completion and good progress has been made with NEBULA for Atlas. It therefore seems an opportune moment to go back and examine the reasons for reaching this decision, and to see how far the situation has changed in this period. The first report of the CODASYL Committee was made available in mid-1960. At about this time it was necessary to decide first whether Orion business users should be provided with an autocode, secondly to what extent an autocode should remove the need for using conventional machine orders, and lastly the extent to which object-program efficiency was important. In view of the magnitude of the programming effort which the early Orion customers were expected to expend on the very large applications planned for their machines, it was considered essential that a good comprehensive autocode should be provided. It was further considered that the aim should be to eliminate completely the need for machine orders, or at least to reduce their use to an absolute minimum. COBOL 60 was examined with this object in view, but it was found to lack a number of facilities required by Orion users. It could, nevertheless, have been implemented together with additional facilities defined by the manufacturer, and this is in fact what has happened in some cases. Ferranti's view, however, was that the object of a common language was to some extent defeated by such an approach, and we preferred to implement a language, which, although similar in many respects to COBOL, was in no way bound by decisions taken in the light of business requirements in the U.S.A., requirements which do not in many cases reflect the state of data processing in this country. It was in our view essential that, if customers were to have any confidence in the ability of the language to meet their requirements, the specification should be as near as possible to completion before programming started. There appeared to be little or no chance of achieving this object owing to the delay which inevitably must arise when decisions depend on a committee sitting many thousands of miles away. It seemed far more useful to get on with the task of specifying the language and writing the compiler. To return to COBOL as specified at that time, it was fairly obvious after only a cursory study that it was orientated towards a character rather than a binary machine. It is of course perfectly feasible to write a COBOL compiler for a binary machine, but it is extremely difficult to make the compiler really efficient. Since the Ferranti machines for which a business language is required are binary machines, it seemed unreasonable to penalize users for the sake of conformity with a language over which we have little influence. The chief difficulties for the user arise when the physical appearance of data on external media such as cards or paper tape is considered. COBOL starts at the point where data is read from magnetic tape and ends with the writing of an updated magnetic-tape file and results file. This is a perfectly feasible proposition for those installations which handle input and output on off-line equipment, or use small pup computers for these operations, but it is hardly satisfactory when the complete application is carried out on one large machine. Manufacturers' additions to COBOL have overcome this difficulty in some cases, but a complete plainlanguage program is still only possible if rather rigid rules are adhered to. NEBULA attempts to give not only a complete freedom of choice of data media, but also freedom of format on the chosen media.
Read full abstract
Mar 1, 1988
Pj Layzell + 1
Open Access