DETAB/65(ID:197/det001)SHARE/SIGPLAN decision table languageDEcision TABle. A. Chapman, 1964. Decision table COBOL preprocessor. Based on TABSOL Arose from SHARE/SIGPLAN workshops etc Structures: Related languages
References: in [ACM] CACM 9(02) February 1966 view details in [ACM] CACM 9(02) February 1966 view details in [ACM] CACM 9(02) February 1966 view details in [ACM] CACM 9(02) February 1966 view details in [ACM] CACM 10(07) (July 1967) view details in [ACM] CACM 10(07) (July 1967) view details in The Computer Journal 10(2) 1967 view details The section, Programming with Decision Tables, re views the various techniques by which decision tables are converted to object programs or to source programs the can be compiled. This section and the one on data relations will have more meaning for those who have been working in the decision table area, but will still be useful for those entering the field. This 22-page article, with its fine references, is one that will be referred to quite often. One error in the article needs to be corrected. The author attributes the implementation of DETAB to "Systems Development Corporation with a large group of volunteer from an Association of Computing Machinery special interest committee in the Los Angeles area." In fact, DETAB/ 65 was developed by Working Group 2 of SIGPLAN of the Los Angeles Chapter of ACM. The two SDC participants developed and implemented an algorithm for converting the decision tables rules to COBOL IF statements. in ACM Computing Reviews 8(04) July-August 1967 view details DETAB/65 DETAB/65 is a COBOL-oriented preprocessor. It was developed by the Los Angeles Chapter (Work Group 2) of the Association for Computing Machinery. The group was formed in June of 1963 to develop a preprocessor for DETAB-X, an earlier COBOL-oriented decision table language. Specifications for the original DETAB-X were so revised, however, that the preprocessor produced was called DETAB/65. The program has been implemented for CDC 1604-A, 3400, and 3600 and IBM 7040, 7044, and 7090/94 computers. At present, DETAB/65 is restricted to limited entry tables, though the group hopes that eventually all three types of tables can be converted. Each decision table is considered a COBOL section and can be included at the end of a normal COBOL program. All data names must have been defined in the Data Division. Like any preprocessor, DETAB/65 does not process COBOL statements; it passes them on to the COBOL compiler. One of the conventions and restrictions listed for DETAB/65 is that the last rule of any table must be an else rule; also, a maximum of 50 conditions, 50 actions, and 50 rules (including the else rule) are permitted. Much of the information needed to process the table is contained in the header card. DETAB/65 will recognize some decision table logic errors. No attempt is made, however, to optimize the condition testing or the coding of actions that occur in more than one rule. In general, DETAB/65 is not efficient in terms of execution time or storage. This inefficiency is acknowledged by the developers. The primary objective for the development of DETAB/65 appears to have been to allow users to experiment with decision tables. The deficiencies in this translator would seem to defeat this objective, since one of the objections often voiced against decision tables is that they cannot be programmed efficiently. in ACM Computing Reviews 8(04) July-August 1967 view details in ACM Computing Reviews 8(04) July-August 1967 view details in ACM Computing Reviews 8(04) July-August 1967 view details Extract: Introduction Introduction Documentation is recognized as a necessary, but time-consuming and often unpleasant, aspect of programming and analysis. Although narratives and flowcharts are the most widely used techniques, their shortcoming?verbosity, difficulties of interpretation, and the problem of maintenance?are not yet widely appreciated throughout the industry. Too, neither is readily convertible to source code, whereas a decision table can immediately be so converted. This paper will review the history of decision tables, their structure and advantages, and indicate the preprocessor modifications to the Detab/65 preprocessor that are needed to permit compilation by either Cobol-65 or ANS-Cobol. Extract: History History In 1957, General Electric developed this tabular systems analysis technique, then called 'structure table logic'. Indeed, the principles on which these tables are based rest on some 'hidden assumptions' set forth by Euclid, c. 300 B.C., but formally stated by M. Pasch and, independently, by D. Hibert about 1900. Other men who worked on the theoretical basis of decision tables were: B. Sch-roeder (1895), E.L. Post (1921), A. Church and, independently, the team of Alan Turing and G. Gentzen (1936). One goal of the 1957 General Electric study was improved documentation, a unique result of representing logic in this form. This was the initial use of tables as source language (Tabsol) for the Tabcon preprocessor. Tabsol was one part of Gecom (General Electric COMpiler) for the GE-225. From this initial work, additional studies were carried on by the Sutherland Company in 1958, as a part of an Air Force project. During 1960, the Codasyl Systems Group developed a technique for utilizing these 'decision tables', as they were beginning to be called, as a source language. Another use of this methodology for programming, as opposed to analysis, was discussed by Kavanaugh. The first decision table language associated with a widely used programming language (COBOL-61) was Detab-X (DEcision TABle experimental). However, this language imposed restrictions on both the Data and Procedure Divisions of the Cobol source program. These restrictions were removed in Detab/65; developed by Working Group 2 of SIGPLAN (Los Angeles Chapter, ACM). Extract: Decision Table Structure Decision Table Structure Decision tables present a graphic statement of a program's logic, providing visual indication of the variables and their values ('conditions' in decision table terminology), which control the execution of one or more program steps ('actions'). Conditions state those variables which must or must not contain specified values for one or more specified actions to be executed. A decision table is divided into four sections as shown in Figure 1. The upper table-half describes the Conditions to be tested and the expected results, while the actions, in the lower half, indicate the steps to be taken if the conditions are satisfied. A rule is formed of a set of Conditions plus their related Actions, and a decision table normally consists of several rules [11], per figure 1. A decision table may be written in one of three entry formats: Limited, Extended, or Mixed. Hicks and Pollack note: "in limited entry form, the entry portion is limited to a single character .... In contrast, the extended entry form has part of the Condition or Action extended directly into the entry. Both form may be used within one table (mixed entry), but any one horizontal row (Condition or Action) must be limited or extended" [12]. Further introductory information may be found in [13]. Extract: Advantages Advantages As compared with other means of program logic description, as flowcharts, decision tables have the following advantages in informal, and later, formal design and documentation: (a) Conciseness; (b) Thoroughness; (c) Ease of modification; and (d) Ready conversion to source code. This is not to imply, however, that flowcharts are not required. "The use of decision tables make it possible to use simplified flowcharts in place of conventional detailed flowcharts" [18]. Flowcharts have gained a place in aiding analysis of, guiding the coding for, then documenting, a program. These charts became the defacto industry-wide standard in these three programming steps, as their use and symbology became widely accepted. The Government added more pressure by establishing the U.S.A. Standards Institute, (later the American National Standards In-stitue) which began urging standardization of items as basic as the symbol to be used for a given operation; indeed, efforts were made to provide a unique interpretation for a given symbol. Flowcharting the logic of Detab 65, from the source code, produced seven pages of detailed flowcharts (on IBM Flowcharting Worksheets), covering only two-thirds of the Procedure Division. The uses of a given variable were so widely spread that it was quite impossible to trace or interpret the program's logic. A less-detailed flowchart was meaningless. However, in [19], Detab/65's algorithm is presented both as a verbal description and a decision table of the Detab/65 Generator: This documentation shows, far more succinctly than would a flowchart, the logic involved in generating the requisite IF statements. This analysis/programming/documentation technique is a valuable aid in detecting a logically-incomplete program, although the source code may already have been compiled and grossly tested. "Use of decision tables will insure: (1) that all possible combinations of conditions for the problem have been considered, (2) that the system does not prescribe different actions for the same situation, and (3) that the system describes each situation and its actions only once" [20]. This form of program representation directly and rapidly indicates, in a single column, those Conditions which directly influence the performance, or non-performance, of an Action. Extract: Modifications Modifications In [19] we are told that "because the preprocessor and the language associated with it were developed for Cobol users, the preprocessor was written ... in required Cobol-61". However, this software was first made available in February 1966; and during April of 1964, the S/360 was announced, bringing with it another COBOL dialect: Cobol-65. Thus, when 1965, the year during which the software was implemented was suffixed to the program's name, confusion arose as to the correct compiler dialect, Cobol-61 or Cobol-65. Tables 1 and 2 indicates those cards to be deleted, and specify the cards to be replaced (the card number's last digit (column 6) containing either a zero or a five) or inserted (column 6 containing any other digit. Making the changes indicated in either table will cause the source deck's syntax to agree with that required by Cob-ol-65 (Table 1) ANS-Cobol (Table 2) . In its unmodified form the program will not be compiled by either compiler. Note that, even in its modified form, the preprocessor will only convert limited-entry tables. in [ACM] SIGPLAN Notices 6(09) September 1971 Special issue on decision tables view details in [ACM] SIGPLAN Notices 6(09) September 1971 Special issue on decision tables view details |