DETAB-X(ID:3038/det007)Decision table-aware dialect of COBOLFor Decision Table, Experimental SDC Dialect of COBOL to act as a decision table based programing language Places Structures: Related languages
Samples: References: DETAB-X (Decision Tables, Experimental) was introduced to the data processing world on September 20, 1962 at a Decision-Table Symposium in New York sponsored by the Systems Group of the CODASYL Development Committee and by the Joint Users' Group (JUG) of ACM. DETAB-X is thus a recent product of activities set in motion some time ago by CODASYL (The Conference on Data Systems Languages). In its early days (1959) CODASYL was comprised of three committees reporting to an Executive Committee: a Short Range, Intermediate Range, and Long-Range Committee. After the Short Range Committee produced COBOL, the CODASYL organization evolved into that shown in Fig. 1. The Development Committee's broad charter was to "consider the next generation of computer languages and to augment the Short Range Committee's undertakings."1 To do this the Committee created two groups. The Language Structures Group concentrated on the development of business language structures; the Systems Group set out to develop a machine-independent, systems-oriented language. The Systems Group investigated several techniques for describing business problems, and in early 1960 focused its attention on decision tables2 as a possible foundation for a business language. The Systems Group was fortunate in being able to draw heavily on the experience of two of its members, Orren Y. Evans and Burton Grad, who had done extensive pioneering work in applying decision tables to operational business situations. Decision tables in general are set up in a tabular format containing a set of decision rules based on a given set of conditions; each decision rule describes the sets of conditions that must be satisfied in order for a given sequence of actions to be taken. The language used within the table to state the conditions can be "pure English," FORTRAN, COBOL, or modified versions of any one of these or other languages. The CODASYL Systems Group developed specifications for DETAB-X ? a decision-table structure using modified COBOL-61 for business-problem description. They chose modified COBOL-61 because most computers for business data processing were expected to have COBOL-61 compilers by the end of 1962. DETAB-X was labeled experimental in order to encourage data processing specialists to experiment with it and to provide feedback to the Systems Group by answering the following questions: 1. Is the decision-table format useful as an additional form to the Procedure Division of COBOL? 2. Can the decision-table format be useful for problem analysis? 3. Within what range of complexity are decision tables effective? 4. Do decision tables sprve as an effective tool in the area of documentation and man-to-man communications? It is important to note that the modifications to COBOL in DETAB-X enable people or computers to readily translate the decision rules contained within each decision table to official COBOL-61 sections, paragraphs, and statements. The modifications were considered necessary for efficiently describing decision rules within the decision-table format. As an illustration of a DETAB-X decision table, the following COBOL-61 PROCEDURE DIVISION statement3 is shown in DETAB-X form in Fig. 2. IF STOCK-ON-HAND IS LESS THAN CURRENT-ORDER THEN IF CURRENT-ORDER IS GREATER THAN SECONDARY-SUPPLY GO TO EMERGENCY-ORDER-ROUTINE; OTHERWISE PERFORM SECONDARY-SUPPLY ROUTINE: OTHERWISE SUBTRACT CURRENT-ORDER FROM STOCK-ON-HAND. In addition to its presentation before an audience of over 450 data system designers and computer programmers at the aforementioned Decision-Table Symposium, DETAB-X was presented to over 500 members of Guide at its Philadelphia meeting in November, 1962. Both audiences were encouraged to experiment with DETAB-X and provide feedback to the CODASYL Systems Group; those interested in doing so were provided with the DETAB-X Specifications Manual and Decision Table Tutorial Manual. The CODASYL Systems Group is just beginning to receive some feedback from users; their remarks indicate that DETAB-X is a significant development in data proces- sing and would be a valuable addition to COBOL. The following are two examples of the many comments received : "DETAB-X certainly aids the problem of man-to-man communication. We believe that continuity of documentation is extremely important for program maintenance and programmer replacement purposes." "DETAB-X would be a very valuable addition to the Procedures Division of COBOL. We hope that it would be a 'required' versus an 'elective' addition to COBOL. As an elective we would be afraid to use it due to the potential lack of compatibility between various manufacturers." The Systems Group had originally planned to evaluate all feedbacks from the experimental use of DETAB-X with a view towards making a recommendation on decision tables to the CODASYL Executive Committee. If the feedback continues in the same vein as above, it is reasonable to expect that the CODASYL Systems Group will probably propose to the CODASYL Executive Committee, probably by mid-1963, that DETAB-X be adopted as an addition to COBOL. in Datamation 9(2) Feb. 1963 view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details COBOL was developed by the COBOL Committee. which is a subcommittee of a layer committee called the "Conference on Data System Languages" which has an Executive Committee and, in addition to the COBOL Committee, a Development Committee. Within the Development Committee are two working groups called the Language Structure Group (whose members are Roy Goldfinger of IBM, Robert Bosak of SDC, Carey Dobbs of Spcrry Rand, Renee Jasper of Navy Management Office, William Keating of National Cash Register, George Kendrick of General Electric, and Jack Porter of Mitre Corporation). and the Systems Group. Both of these groups are interested in going beyond COBOL to further simplify the work of problem preparation. The Systems Group has concentrated on an approach which represents a generalization of TABSOL in GE's GECOM. The driving force behind this effort is Burt Grad. The Language Structure Group has taken a different approach. It notes that FACT, COBOL, and other current data-processing compilers are "procedure-oriented," that is, they require a solution to the dataprocessing problem to be worked out in detail, and they are geared to the magnetic-tape computer and assume that information is available in files on magnetic tape. sorted according to some keys. The Language Structure Group felt that an information algebra could be defined which would permit the definition of a data-processing problem without postulating a solution. It felt that if this point were reached. then certain classes of problems could be handled by compilers that would, in effect, invent the necessary procedures for the problem solution. One sees a trend in this direction in FLOW-MATIC, COBOL, Commercial Translator, and FACT, if one notes that a sort can be specified in terms of the ipnput file and the output file, with no discussion of the technique required to create strings of ordered items and merge these strings. Similarly, a report writer specifies where the information is to come from and how it is to be arranged on the printed page, and the compiler generates a program which accomplishes the purpose without the programmer having to supply the details. The FACT update verb specifies a couple of input files and criteria for matching, and FACT generates a program which does the housekeeping of reading records from both files, matching them and going to appropriate routines depending on where there is a match, an extra item, a missing item, etc. A careful study of existing compilers will reveal many areas where the compiler supplies a substantial program as a result of having been given some information about data and interrelationships between the data. The Language Structure Group has, by no means, provided a technique of solving problems once they are stated in abstract form. Indeed, it is clear that this problem is not soluble in this much generality. All the Language Structure Group claims is to provide an information algebra which may serve as a stimulus to the development of compilers with somewhat larger abilities to invent solutions in restricted cases. The work of the Language Structure Group will be described in detail in a paper which will appcar shortly in the Coinnnmications offhe ACM. Extract: Basic concepts Basic concepts The algebra is built on three undefined concepts: ENTITY, PROPERTY and VALUE. These concepts are related by the following two rules which are used as the basis of two specific postulates: (a) Each PROPERTY has a set of VALUES associated with it. (b) There is one and only one VALUE associated with each PROPERTY of each ENTITY. The data of data processing are collections of VALUES of certain selected PROPERTIES of certain selected ENTITIES. For example, in a payroll application. one class of ENTITIES are the employees. Some of the PROPERTIES which may be selected for inclusion are EMPLOYEE NUMBER, NAME, SEX, PAY RATE, and a payroll file which contain a set of VALUES of these PROPERTIES for each ENTITY. Extract: Property spaces Property spaces Following the practice of modern algebra, the Information Algebra deals with sets of points in a space. The set of VALUES is assigned to a PROPERTY that is called the PROPERTY VALUE SET. Each PROPERTY VALUE SET contains at least two VALUES U (undefined, not releUant) and II (missing, relevant, but not known). For example, the draft status of a female employee would be undefined and not relevant, whereas if its value were missing for a male employee it would be relevant but not known. Several definitions are introduced : (1) A co-ordinate set (Q) is a finite set of distinct properties. (2) The null co-ordinate set contains no properties. (3) Two co-ordinate sets are equivalent if they contain exactly the same properties. (4) The property space (P) of a co-ordinate set (Q) is the cartesian product P = V, X V, x Vj X . . . X V,, where V, is the property value set assigned to the ith property of Q. Each point (p) of the property space will be represented by an n-tuple p = (a,, a,, a,, . . ., a,), where a, is some value from C',. The ordering of properties in the set is for convenience only. If n -= 1, then P = V,. If n = 0, then P is the Null Space. (5) The datum point (d) of an entity (e) in a property space (P) is a point of P such that if (1 -= (a,, al. a,. . . ., a,,), then a, is the value assigned to e from the ith property value set of P for i -I 1. 2, 3, . . ., n. ((l) is the representation of (e) in (P). Thus, only a small subset of the points in a property space are datum points. Every entity has exactly one datum point in a given property space. Extract: Lines and functions of lines Lines and functions of lines A line (L) is an ordered set of points chosen from P. The span (n) of the line is the number of points comprising the line. A line L of span n is written as: L = (p,, p2. . . ., p,,) The term line is introduced to provide a generic term for a set of points which are related. In a payroll application the datum points might be individual records for each person for five working days of the week. These live records plotted in the property space would represent a line of span five. A function of lines (FOL) is a mapping that assigns one and only one value to each line in P. The set of distinct values assigned by an FOL is the value set of the FOL. It is convenient to write an FOL in the functional form , f ' ( X ) , where f is the FOL and X is the line. In the example of the five points representing work records for five days work, a FOL for such a line might be the weekly gross pay of an individual, which would be the hours worked times payrate summed over the five days of the week. An Ordinal FOL (OFOL) is an FOL whose value set is contained within some defining set for which there exists a relational operator R which is irreflexive, asymetric, and transitive. Such an operator is "less than" on the set of real numbers. Extract: Areas and functions of areas Areas and functions of areas An area is any subset of the property space P; thus the representation of a file in the property space is an area. A function of an area (FOA) is a mapping that assigns one and only one value to each area. The set of distinct values assigned by an FOA is defined to be the value set of the FOA. It is convenient to write an FOA in the functional form f'(X), where f is the FOA and X is the area. Extract: Bundles and functions of bundles Bundles and functions of bundles In data-processing applications, related data from several sources must be grouped. Various types of functions can be applied to these data to define new information. For example, files are merged to create a new file. An area set /A of order n is an ordered n-tuple of areas (A,, A,. . . ., A, = /A). Area set is a generic term for a collection of areas in which the order is significant. It consists of one or more areas which are considered simultaneously; for example. a transaction file and master file from an area set of order 2. Definition: The Bundle B -: B(b, /A) of an area set /A for a selection OFOL h is the set of all lines L such that if (a) /A = (A,, .Az. . . ., A,,) and (0) L = ( p , . p*, . . .,p,,). where p, is a point of A, for i = 1,2 , . . . , n, then b( L) = True. A bundle thus consists of a set of lines each of order n where 11 is the order of the area set. Each line in the bundle contains one. and only one. point from each area. The concept of bundles gives us a method of conceptually linking points from different areas so that they may be considered jointly. As an example, consider two areas whose names are "Master File" and "Transaction File," each containing points with the property Part Number. The bundling function is the Part Number. The lines of the bundle are tlie pairs of points representing one Master File record and one Transaction File record with the same partner. A function of a bundle (FOB) is a mapping that assigns an area to a bundle such that (a) there is a many-to-one correspondence between the lines in the bundle and the points in the area; (b) the value of each properly of each point in the area is defined by an FOL of the corresponding line of the bundle; (c) the value set of such an FOL must be a subset of the corresponding property value set. The function of a bundle assigns a point to each line of the bundle; thus a new Master File record must be assigned to an old master file record and a matching transaction file record. Extract: Glumps and functions of glumps Glumps and functions of glumps If A is an area and g is an FOL defined over lines of span 1 in A, then a Glump G - G(g, A) of an area A for an FOL g is a partition of A by g such that an ele- ment of this partition consists of all points of A that have identical values f' or g. The function g will be called the Glumping Function for G. The concept of a glump does not imply an ordering either of points within an element, or of elements within a glump. As an example, let a back order consist of points with the three non-null properties: Part Number, Quantity Ordered, and Date. Define a glumping function to he Part Number. Each element of this glump consists of all orders for the same part. Different glump elements may contain different numbers of points. A function of a glump (FOG) is a mapping that assigns an area to a glump such that (a) there is a many-to-one correspondence between the elements of the glump and the points of the area ; (b) the value of each property of a point in the assigned area is defined by an FOA of the corresponding element in the glump: (c) the value set of the FOA must be a subset of the corresponding property value set. in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details External link: Online copy in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Proceedings Decision Tables Symposium September 1962 Association Computer Machinery, New York, 1962. view details in Ideas for Management, 1964, International Systems Meeting, Systems and Procedures Association, Philadelphia, 1964 view details in Ideas for Management, 1964, International Systems Meeting, Systems and Procedures Association, Philadelphia, 1964 view details logic. Decision tables have many inherent advantages. The technique to be illustrated puts these advantages to use in that it enables one to program directly from a decision table. The technique is based on the creation of a binary image of a limited entry decision table in computer memory. A binary image of a given set of input conditions can also be created. This data image is used to scan the decision table image to arrive at the proper course of action. There are several advantages gained from the program- ming point of view: (1) amount of computer memory used is drastically reduced, (2) programming is simplified, and (3) documentation is brief and clear. Extract: Introduction Introduction This paper describes a technique (first used in 1958) which makes it possible to program a computer directly from decision tables. At the present time, flowcharts are widely used to describe computer program logic. Although these charts are satisfactory in many instances they have the following disadvantages: they tend to be confusing in complex situations, they are not suitable for communicating directly with the computer, and they are not as readable as decision tables. Decision tables tend to overcome these objections, and also offer several advantages. Logic is stated precisely and compactly, complex situations are more easily understood, relationships between variables are apparent, and programming is simplified. In addition, the tables provide an excellent form of documentation. The articles mentioned in [1, 2] will provide one with an additional understanding of the use and advantages of decision tables. in [ACM] CACM 8(01) Jan 1965 view details in DPMA Quarterly 8 (1965) view details in The Computer Journal 10(2) 1967 view details in The Computer Journal 10(2) 1967 view details in Computer Program Abstracts Cumulative Issue July 15, 1969 -- July 15, 1971 view details in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details Attempts have also been made to imbed decision table forms and aids in a language which would help programmers in converting flow charts and programs. FORTAB and DETRAN in FORTRAN and DETAB-X in COBOL are examples from the early 1960's. More recently, a number of decision table translators for generating COBOL logic statements have been designed. This has been in conjunction with the recent attention devoted to COBOL support packages and to programming and productivity aids in the 1970's. There are undoubtedly a few dozen decision table processors commercially available. There were at least ten of them available in 1971. Among these were TAB-70 from Control Data Corp., TABTRAN from Westinghouse Tele-computer Systems, and TABLEMASTER from Hoskyns Systems Research. They operate, with a few exceptions, in batch mode only. These processors usually translate tables with COBOL-compatible content, i.e., the condition stub contains COBOL relational expressions and the action stub contains COBOL assignment statements which correspond to the COBOL paragraphs of the PROCEDURE DIVISION of the COBOL program. Differences among the available translators are mostly in degree and translation algorithm. They usually check input tables for completeness, redundancy, and consistency, e.g., detect conflicts and duplicates. Some of the algorithms strive to minimize the Storage necessary for the program produced and others its execution time. Pooch provides a survey and comparison of algorithms for translating tables. Extract: PDEL A brief example will illustrate that many special purpose packages indeed have features in common with customizers. The partial differential equation Language PDEL - has been designed to solve partial differential equations which characterize a variety of systems across various disciplines such as thermal systems, hydrological systems, and particle diffusion systems [I51 The input language is nonprocedural and does not require programming know-how; no how-to-do-it numerical analysis indications are required. The PDEL translator, written in PL/I and originally implemented via PL/I macro facilities, generates a complete ready to compile PL/I program with the numerical analysis approach to solve the specific User problem, The translator is made up of 1) primarily n set of skeletal modules and often used structures of code, 2) a Set of modules which contains the logic equivalent to decision tables to choose the source statements corresponding to the input PDEL program specifications. 3) a set of code generators that create the necessary new code or modify built-in code dictated by the input specifications, and 4) a master control program which builds and edits a complete and debugged PL/I program made up of the selected prewritten code and of the new code created [16]. Usually from 50% to 85% of the complete program is comprised of prewritten code. Elements 1, 2 and 4 are much like those of customizers. Element 3, the creation of code, typifies high level languages. Notice the placement of PDEL and of other more widely used special purpose languages such as GPSS. SIMSCRIPT, and CSMP in the spectrum of code generators in Figure 2. in Computers & Automation 21(6B), 30 Aug 1972 view details |