COBOL-61(ID:3135/cob005)First revision of CODASYL COBOLRelated languages
References: The properties of data It is, of course. the available properties of the data which to a large extent determine the power of an automatic programming system, and distinguish commercial from mathematical languages. Consider the function of moving data within the internal store. In a mathematical language the problem is trivial because the unit which may be moved is very restricted, often to the contents of a single machine word. But in a commercial language this limitation is not acceptable. There, data units will occur in a variety of shapes and sizes. for example: i) Fixed Length Units (i.e. those which on each occurrence will always be of the same length) may vary widely in size and will tend not to fit comfortably into a given number of words or other physical unit of the machine. Generally the move will be performed by a simple loop. but there are some awkward points such as what to fill in the destination if the source is the smaller in size; ii) Static Variable Length Units (i.e. those whose length may vary when they are individually created but will not change subsequently) are more difficult to handle. Essentially the loop will have two controlling variables whose value will be determined at the moment of execution. There are again awkward points such as the detection of overflow in the destination (and deciding what to do when it occurs, since this will only be discovered at run time); iii) Dynamically Variable Length Units (i.e. those which expand and contract to fit the data placed in them) are even more difficult. They have all the problems of (ii), together with the need to find and allot space when they expand. It is clear, therefore, that a simple MOVE is less innocuous than it might seem at first. Actually the above remarks assumed that it was not possible to move data between different classes of units. The absence of this restriction, and the performance of editing functions during the process, can make the whole thing very complicated for the compiler indeed. The properties of data will have a similar influence on most of the other operators or verbs in the language. This has particular significance when the desired attribute is contrary to that pertaining on the actual machine. Thus arithmetic on decimal numbers having a fractional part is thoroughly unpleasant on fixed-word binary machines. Nevertheless, despite these difficulties considerable progress has been made toward giving the user the kind of data properties he requires. Unfortunately this progress has not been matched by an improvement in machine design so that few, if any, of the languages have achieved all of the following. (a) The arbitrary grouping of different classes of unit, allowing their occurrence to be optional or for the repetition in variable-length lists. (b) The input and output of arbitrary types of records, or other conglomerations of data units. having flexible formats. editing conventions and representations (c) The manipulation of individual characters, with the number and position of the characters being determined at run time. (d) The dynamic renaming or grouping of data units. Yet users do need these facilities. It is not always acknowledged that getting the main files on to the computer, before any processing is done, may constitute the largest single operation in many applications. Furthermore. these files will have a separate independent existence apart from the several programs which refer to them. Progress has also been made in declaring the data properties in such a way as to imply a number of necessary procedures to the compiler. For example, if one declares both the layout of some record to be printed, and the printed record, the compiler may deduce the necessary conversion and editing processes. It is here, in the area of input and output, that some languages have approached the aim of being problem-orientated. Extract: COBOL COBOL One must, of course, start with COBOL if for no other reason than because sooner or later, for good or ill, we are all going to be concerned with it. In view of all the publicity and argument I presume that everyone has heard of COBOL: how it was started the American Defense Department in conjunction with the majority of American manufacturers; how pressure was put on its acceptance by the Defense Department (the largest single user of computers in the world) through their insistence that they would not buy any computer which did not have a compiler for it. It was natural for the American manufacturers to press for the universal adoption of COBOL due to the large expenditure they were committed to by its implementation. It is true that some were a little cool towards it at but all now seem reconciled. The opposition to COBOL depended on the attitude of IBM. much in the same way as does the opposition to ALGOL. IBM announced that they will not implement their own system COMMERCIAL TRANSLATOR for any new machine. If this means they are going over entirely to COBOL then that will in my opinion be decisive, But up to now the of the language among American user groups, such as the SHARE organization, has not been as widespread as the originators have wished. As for COBOL itself, the language has made progress. The 1961 version is much tidier and better described than in 1960. A more realistic attitude has been taken to the degree of commonality across machines that can be obtained5 a definite attempt has been made to get everyone 10 implement the same language and so end the profusion of COBOL-like dialects that followed the 1960 publication. Yet a number of problems remain. The language is still not specified with a sufficient degree of precision. It lacks a means of defining new functions of adequate generality. Further. although the next report is not due until 1963, there is a very real difficulty in preventing new versions, in so far as they are a change rather than an extension to previous ones. from causing the kind of confusion the language was designed to prevent. Nevertheless COBOL, unlike ALGOL, is a complete programming system and in this, and the ideas it has introduced, it does represent a considerable achievement. Many of those in this country (myself included) who were engaged in designing a different language learnt a great deal from it. It is already available here, mostly in forms only approximately to the 1960 report, but the 1961 compilers will soon be available from across the Atlantic. in The Computer Journal 5(2) July 1962 view details in [ACM] CACM 5(05) May 1962 view details The paper contains some detailed description of the problems involved in data handling in commercial translators with emphasis on the need for more flexibility than presently available. The author, as have many before him, again questions the value of attempting to create languages "any fool can use" at the cost of efficiency and flexibility, when even these languages will not prevent the fool from having to debug his programs. On existing commercial translators, the author lists and compares briefly COBOL, FACT, COMTRAN and several English efforts which "are either not working, or not on a par with their American equivalents." The paper concludes with some not so new but nevertheless appropriate recommendations to computer manufacturers and standards committees, and the expectation of the universal acceptance of COBOL as He commercial language. in ACM Computing Reviews 4(01) January-February, 1963 view details DOI in [ACM] CACM 6(05) May 1963 "Proceedings of ACM Sort Symposium, November 29, 30, 1962" view details in [ACM] CACM 6(05) May 1963 "Proceedings of ACM Sort Symposium, November 29, 30, 1962" view details |