TABSOL(ID:142/tab012)
Tabular systems language
for TABular Systems Oriented Language
T.F. Kavanaugh General Electric 1960
A language extension for GECOM written in the form of truth tables which was compiled into code for the tests and actions described.
from BRL Manifest
"TABSOL - TABular Systems Oriented Language. Allows source programs to be described in tabular form. It is a structure technique used to describe the step-by-step decision logic in the process of solving a problem."
Places
Structures:
Related languages
| GECOM | => | TABSOL | Subsystem of | |
| LOGTAB | => | TABSOL | Evolution of | |
| TABSOL | => | DETAB-X | Evolution of | |
| TABSOL | => | FORTAB | Influence |
References:
in [JCC 18] Proceedings of the 1960 Eastern Joint Computer Conference, New York, December 1960 view details
in ACM Computing Reviews 2(04) July-August 1961 view details
A UNIQUE CONCEPT IN COMPUTER COMMUNICATION
now available in the GE 225 ... and future General Electric general-purpose computers.
? processes COBOL, ALGOL and TABSOL
? all problem statements easily read and understood
? extended usage... re-programming unnecessary
? programs produced faster... more efficiently
GECOM?the first truly GENERAL COMPILER SYSTEM ?introduces a fresh, versatile approach to computer communication. Developed for the GE 225 computer, the GENERAL COMPILER makes available all of the various proved programming techniques in one consistent, compact package. No longer is it necessary to learn a dozen different programming systems to handle a full range of jobs effectively?each job is approached in exactly the same way, be it formula evaluation, a sort, or even a payroll. The language for describing any run is consistent, operating procedures and programming are standard, and documentation is readable and easily understood.
THE GENERAL COMPILER PROVIDES:
A FAMILIAR LANGUAGE STRUCTURE
Problems need not be stated in machine code. The GENERAL COMPILER processes English language statements (COBOL), Algebraic expressions (ALGOL) , and Structure Tables (TABSOL) . It permits you to use all or any one of the computer languages ... as your needs require. Still, you have available the capability to expand, use other languages and new techniques as your needs change.
A PROVED, ACCURATE CODER
Data Description and Problem Logic may be written in one, two, or a combination of the available languages producing a machine program of efficient, effective coding. Since the machine coding is derived directly from the logic of the problem statement, it is only at the logic level that debugging may have to be done.
A STANDARDIZED, UNDERSTANDABLE DOCUMENTATION
Because GENERAL COMPILER problems are written in familiar languages, they can be easily read and understood. In addition, problem format provides a high degree of standardization. Programs written for today's machines in GECOM format can be used for future General Electric computers?eliminating the need for re-programming.
AN EFFICIENT, ECONOMICAL USE OF COMPUTERS
Personnel training time and expense are sharply reduced .since the novice programmer may use the familiar terminology of his profession. Manual coding is eliminated and debugging cut to a minimum. Thus, a machine program may be produced much faster and more efficiently than by present manual methods.
THE GENERAL COMPILER is ANOTHER GENERAL ELECTRIC FIRST!
in ACM Computing Reviews 2(04) July-August 1961 view details
in ACM Computing Reviews 2(04) July-August 1961 view details
in ACM Computing Reviews 2(04) July-August 1961 view details
in Computer Automation 10(9) 1961 view details
Automatic coding languages are relieving the programmer of many details. The structure of these new languages is much like English. The programmer needs only to "describe" his problem to a computer using a combination of English words and phrases. This description is given to a special computer program commonly called a compiler which translates the English problem description to a computer program.
Automatic coding languages are relieving the programmer of many details. The structure of these new languages is much like English. The programmer needs only to "describe" his problem to a computer using a combination of English words and phrases. This description is given to a special computer program commonly called a compiler which translates the English problem description to a computer program.
The General Compiler provided for the GE 225 (GECOM) evolved from two noteworthy language efforts - the Common Business Oriented Language (COBOL) and the Algorithmic Language (ALGOL). Both were developed by voluntary committees of manufacturers and users and reflect the trend toward "common" compiler languages. COBOL was chosen as a base language since it satisfied the needs of a broad spectrum of data processing applications. Boolean expressions floating point arithmetic, and the ability to express equations were taken from ALGOL and Incorporated into the format of COBOL. Therefore I one may say that the present version of the General Compiler can accept programs written in ones twos or in a combination of two languages.
COBOL is well suited for processing and reporting information contained in data files. ALGOL provides an excellent means for expressing the mathematics and logic associated with scientific applications. Recent investigations by the Integrated Systems Project (ISP) a combined services project of General Electric uncovered an area of applications which require neither extensive file processing nor profound mathematics but rather an unwieldy number of sequential decisions. To cope effectively with these decisions the ISP team devised a tabular language to depicts by means of tables I the decisions encountered in the information flow of a business system. The new language was appropriately termed TABSOL for TABular System Oriented Language.
[...]
Since its creations TABSOL has been used bymany departments of General Electric to analyze and solve problems in product engineering manufacturing methods cost accounting, and Droduction control. The application of decision tables is continually growing. Studies show that they provide a concise method for supporting the logic of other data processing applications. For examples they may be used to specify a transfer vector associated with the values of one or more fields to control the printing of detail and mammary lines of a report, or to interrogate the sort keys in a file maintenance run. They have also proved a valuable tool in the design and implementation of the General Compiler.
in Proceedings of the 16th ACM National Conference, January 1961 view details
A vertical double line divides a rectangle into two rectangles. The left one is labeled, "Decision Logic", and the right is labeled 'Results or Functions". A horizontal double line divides the
rectangle into two, the upper one labeled "Column Headings" and the lower "Table Values". Thus, there is provided column headings for decision logic parameter names and the related table of parameter values on the right; similarly, for results or functions on the left. The structure table is thus a useful mechanism for documenting complex, multi-variable conditional statements, e.g. "If . . ., then . . ." with complex, multi-variable results. The table is divided in columns and lined in rows so that several such statements, using subsets of the same column headings, can be written in vertical sequence, one to a row. The null subset of decision parameters is also permitted (declarative and imperative statements). Sets of such tables for a business operation constitute a decision system. One table is usually used for expressing all alternative statements involving the same set of column headings. Conditional jumps from one table to another are readily designated where needed.
The application of a structure table is by testing the decision logic parameter values in a problem statement against those in the table and reading the result corresponding to "matched" decision logic values. "Matched" may be in some other sense than equality. The type of test of problem parameter value versus decision logic table value is indicated by symbols (relational operators) before each table value. Test types are =, >, <, A, _, <, true, false, and certain compound Boolean operators. Simplifying conventions are available for designating application of the same test to the decision logic parameter (in one column) in all statements included in one structure table.
Other simplifications provided are for an "all other" row to avoid exhausting all possible logical combinations of the decision parameters. However, this may be a dangerous vitiation of one chief value of TABSOL, an inexorable demand on the systems analyst for the complete documentation of the decision conditions. Normally, failure of a problem conditional to "match" a decision logic row is an "error" and causes a jump to a table trailer -- an error routine in language closely resembling IBM's COMTRAN or TABSOL in more discursive English, i.e. less tabulated. The trailer may, however, consist of nothing but a jump to another structure table for the error routine.
TABSOL at the computer level would resemble a tabularized, extended COMTRAN. However, at General Electric, it has been used at the company operation level for documenting any "goal-oriented, operating decision system" as a problem-oriented language scheme. It is not accompanied by any statements about the environment in which the operations are to be conducted, hence has no machine orientation. It has been applied to. the processing of customer orders from receipt to finished goods inventory in an integrated control system for a multi-product factory.
Structure table advantages include: simplicity and comprehensibility is promoted without extensive training; errors are evident at source language level; accuracy of problem analysis and solution is extended; maintainability of problem statement (system modifications) and solution (program) is enhanced.
The article is not a complete description of TABSOL. While TABSOL permits iteration, it is not clear whether TABSOL permits recursion, implies representations, nesting of tables within tables and communication between tables at the row level, etc. However, this article is a very readable introduction to the basic elements.
Since a major purpose of such a language is to bridge the gap between problem and hardware or human operator, General Electric has supplemented TABSOL with the GECOM compiler.
It is very encouraging that, in the search for a systems oriented language, a considerable step could be taken with so elementary a structure as TABSOL.
in Proceedings of the 16th ACM National Conference, January 1961 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
A vertical double line divides a rectangle into two rectangles. The left one is labeled, "Decision Logic", and the right is labeled 'Results or Functions". A horizontal double line divides the rectangle into two, the upper one labeled "Column Headings" and the lower "Table Values". Thus, there is provided column headings for decision logic parameter names and the related table of parameter values on the right; similarly, for results or functions on the left. The structure table is thus a useful mechanism for documenting complex, multi-variable conditional statements, e.g. "If . . ., then . . ." with complex, multi-variable results. The table is divided in columns and lined in rows so that several such statements, using subsets of the same column headings, can be written in vertical sequence, one to a row. The null subset of decision parameters is also permitted (declarative and imperative statements). Sets of such tables for a business operation constitute a decision system. One table is usually used for expressing all alternative statements involving the same set of column headings. Conditional jumps from one table to another are readily designated where needed.
The application of a structure table is by testing the decision logic parameter values in a problem statement against those in the table and reading the result corresponding to "matched" decision logic values. "Matched" may be in some other sense than equality. The type of test of problem parameter value versus decision logic table value is indicated by symbols (relational operators) before each table value. Test types are =, >, <, A, _, <, true, false, and certain compound Boolean operators. Simplifying conventions are available for designating application of the same test to the decision logic parameter (in one column) in all statements included in one structure table.
Other simplifications provided are for an "all other" row to avoid exhausting all possible logical combinations of the decision parameters. However, this may be a dangerous vitiation of one chief value of TABSOL, an inexorable demand on the systems analyst for the complete documentation of the decision conditions. Normally, failure of a problem conditional to "match" a decision logic row is an "error" and causes a jump to a table trailer -- an error routine in language closely resembling IBM's COMTRAN or TABSOL in more discursive English, i.e. less tabulated. The trailer may, however, consist of nothing but a jump to another structure table for the error routine.
TABSOL at the computer level would resemble a tabularized, extended COMTRAN. However, at General Electric, it has been used at the company operation level for documenting any "goal oriented, operating decision system" as a problem-oriented language scheme. It is not accompanied by any statements about the environment in which the operations are to be conducted, hence has no machine orientation. It has been applied to. the processing of customer orders from receipt to finished goods inventory in an integrated control system for a multi-product factory.
Structure table advantages include: simplicity and comprehensibility is promoted without extensive training; errors are evident at source language level; accuracy of problem analysis and solution is extended; maintainability of problem statement (system modifications) and solution (program) is enhanced.
The article is not a complete description of TABSOL. While TABSOL permits iteration, it is not clear whether TABSOL permits recursion, implies representations, nesting of tables within tables and communication between tables at the row level, etc. However, this article is a very readable introduction to the basic elements.
Since a major purpose of such a language is to bridge the gap between problem and hardware or human operator, General Electric has supplemented TABSOL with the GECOM compiler.
It is very encouraging that, in the search for a systems oriented language, a considerable step could be taken with so elementary a structure as TABSOL.
in ACM Computing Reviews 3(01) March-April 1962 view details
in ACM Computing Reviews 3(01) March-April 1962 view details
in The Computer Journal 10(2) 1967 view details
TABSOL
TABSOL (TABular Systems Oriented Language) was developed by General Electric, one of the early pioneers in the use of decision tables. TABSOL is an integral part of the GECOM-II Compiler, which produces an object program for use on any GE-200 series configuration. The GECOM language is based on COBOL and ALGOL (Internation /4Z.G0rithmic Language); TABSOL decision tables can be included in a GECOM source program.
Since the format of the TABSOL "structure tables" is somewhat different from that of the decision tables we have examined in the previous chapters, it would perhaps be instructive to look at two tables.
Figure 9-1 explains the basic TABSOL table format. The TABSOL primary rows are what we have been calling stubs, while the secondary rows are what we have called rules. The conditions are listed across the top left of the table, rather than down the upper left side; the actions are listed across the top right, rather than down the lower left side. Thus, TABSOL tables are oriented horizontally, instead of vertically. Similarly, the entries run along the opposite plane.
Figure 9-2 is an example of the table we are accustomed to using, while Figure 9-3 is a TABSOL-oriented table for comparison purposes. Permissible relational operators in the condition portion of the TABSOL table are EQ (equal to), GR (greater than), LS (less than), NEQ (not equal to), ATGR (not greater than), and NLS (not less than). Various logical expressions are permitted. The only GECOM verbs permitted in the action portions are CLOSE, GO TO, OPEN, PERFORM, READ, STOP, and WRITE. Special symbols allow the use of skip (-) or repeat (") operators.
TABSOL permits both limited and extended entry tables. Since else is not a GECOM or special TABSOL word, else rules are not permitted. Because TABSOL is part of the GECOM compiler, compilation time should be less as the extra time required to go from preprocessor to higher level language, and then from higher level language to machine language, is not required. However, tables are not checked for completeness or redundancy. Consequently, the condition testing cannot be as efficient as it should be, and the program itself will take longer to run. GECOM, of which TABSOL is part, is available only with the 200 series of General Electric's computers.
in The Computer Journal 10(2) 1967 view details
in The Computer Journal 10(2) 1967 view details
Summary
This paper describes the Tabsol Decision Table Preprocess or, a program product of the B. F. Goodrich Company. The Tabsol (Tabular systems oriented language) Preprocessor, itself written in ANSI Cobol, is designed to translate horizontal-rule, extended-entry decision tables into equivalent Cobol statements. Design objectives, language format and implementation results of the Tabsol Preprocessor are summarized in this paper. This preprocessor has been in full production use by the Information Systems Department of B.F.Goodrich Chemical Company since January 1971.
Extract: Introduction
The systems analysts and programmers of the Information Systems Department of B. F. Goodrich Chemical Company have made extensive use of decision table logic since 1962. Systems analysts use decision table logic in their initial program documentation. This documentation is converted by the programmer into a working program or set of programs.
During the period 1962 thru 1970. most of our commercial and scientific programming effor ts were implemented using a single compi ler language, Gecom. This compi ler, as developed by the Computer Dep art-ment of the General Electric Company for its GE 200 series computers (now marketed by Honeywell Information Systems) contained many language features that allowed it to be used for a wide range of commercial, scientific, and systems-oriented applications. A very important element of the Gecom compil er allowed decision tables to be inserted as an integral part of the Gecom source program..The Gecom compiler processed these tables as a natural part of its Cobol-1ike syntax.
Thus, we have not only used tabular decision logic for program logic definition but have also been able to insert the analyst-created tables directly and naturally into the source-language program as created by the programmer. We feel that the use of tabular decision tables has provided us with an effective device for analyst-programrner-progratn communication.
Since 1962, our use of decision tables represents over 100 man-years of experience. In this period, some 1,000 programs containing over 5,000 tables have been developed. In the opinion of our Information Systems management, the productivity of analysts and programmers in development and maintenance of EDP systems written in Cobol is at least doubled when decision tables are also used. Tables in these programs represent a wide range of applications including tables for complex file-updating, data validating, code or literal-value assignment, compi ler logic structures, program contro1 routing, and many other scientific and commercial logic structures.
The Information Systems Department of B.F,Goodrich Chemical Company has expanded its hardware capability for the 1970's with the acquisition of third generation hardware form International Business Machines Corporation. To ease conversion of existing programs to Cobol for the System 360/370 and to maintain the high productivity in program documentation, program creation, and system maintenance contributed by decision tables, it was necessary that decision table capabi lities be made available for use in Cobol..
Early in 1970, the design and implementation of a system to provide these capabilities was begun. Our requirements have been met with the creation of the Tabsol Decision Table Preprocessor, a program product of B. F. Goodrich Company. Extract: Design Objectives
Design Objectives
The objectives set forth for the design and implementation of the Tabsol Decision Table Preprocessor included these goals:
- Allow tab les to be written in a format si milar to that used in the Gecom language, i.e., tables incorporating the hor i zonta1-rule, extended-entry format.
- Preserve and improve, where possible, features contained in the decision table elements of Gecom.
- Design Tabsol so that it offers the programmer a reasonable subset of standard Cobol verbs and condition-expression formats.
- Design the Tabsol preprocessor around our needs but recognize the possibility of potential use of Tabsol by other installations.
- Write the preprocessor in ANSI Cobol.
- Design Tabsol to work with both DOS and OS operating systems on IBM System 360/370 hardware, and run on a minimum system as defined by a 64K 360/30 under DOS.
- Have a working Tabsol preprocessor by 1/1/71.
Extract: The design goals
The design goals have all been met and the Tabsol Dec ision Table Preprocessor has been in productive use under both DOD and OS since the first quarter of 1971.
Our decision to develop a decision table preprocessor based on the horizontal-rule, extended-entry format was three-fold. First, our experience with both vertical-rule and horizontal-rule table formats indicated that the horizontal-rule tables presented a more easily-understood visual presentation of the desired logic structure. The table elements are read in a left-to-right, row-by-row manner just as all other statements contained in a Cobol program. Second, our experience with maintenance of programs containing tabular decision tables indicated that most corrections and additions are made by adding or deleting one or more rows.jln a horizontal-rule table, this involves replacing only one card (i.e., that row). In a vertical-rule table, every card must be changed when a rule is added. Third, our analysts and programmers were already trained in the use of horizontal-rule tables, and many Gecom programs, marked for conversion to IBM System 360/370, contained horizontal-rule tables.
The language structure of the LANGUAGE FORMAT Tabsol was designed around the horizontal-rule, extended-entry format. A simplified structure of this table is shown in Figure 1. Each rule (row) in such a table is made up of condi tions formed by the combination of the primary row and a specific secondary row. If all conditions in a specific row (rule) are true, then all the act ions specified in that row are carried out. If all conditions are not satis fied, then the next rule is tested. A Tabsol table is easily read by replacing the column dividers with the words IF, AND, and THEN, as shown in Figure 1. Each row is then read as: IF condition-1 (true) AND condition-2 (true) AND ... THEN (do) ac t i on -1 AND (do) action-2
To provide standardization of tabl e format to the user, as well as to make the creation of the preprocessor in ANSI Cobol lass difficult, the Table He ader 1ine (see Figure 1) was made fixed-format. The table name was fixed at three characters, in coliimns 8 thru 10. The word TABLE must begin in column 16. The rest of the Table header line was tree format, beginning in column 28- These card column alignments conform to our ANSI Cobol programming standards for sentence-label, verb, and procedure s tatement star ting columns. The initial implement-ation of Tabsol handles a table having up to 10 conditions, 10 actions, and 25 rows. Each row of the table may be placed on as many as five successive cards, depending on the space required.
Special characters were selected for use by the programmer for coding the Tabsol tables on Cobol coding sheets: the lozenge (X , the pound sign (#) and the asterisk (*),
- The lozenge is used to separate each condition and action in a row. In the printed listing, the 1ozenge forms vertical line.
- The pound sign serves as a secondary column entry in a Tabsol table, to ind icate that a condition or action is the same as the same column entry
- The asterisk is used as an ignore tsntry in a specific condition or action column of a row. This indicates that the condition is not to be tested, or the action is not to be taken for that row.
The Tabsol preprocessor normally expects to find data-names, relational operators, verb formats, or combinations of these items as entr ies in condit~ ion and action columns. For reas ons of table readability, enforcement of re as on able -length data names, 'and for preprocessor stor age requirements, the maximum size of individual entries for condition or. action columns was set at 16 characters. In general, this means that data-names should not normally exceed 12 characters, and paragraph and section names c annot exceed 16 characters.
To accomodate tables with a large number of conditions and actions, each row of tKe Tabsol table is allowed to extend over five cards, though one row per card is recommended. The major design elements of the Tabsol preprocessor are summarized in Table 1.
Extract: Implementation of TABSOL Preprocessor
Implementation of TABSOL Preprocessor
As mentioned in the design objectives of Tabsol, the Tabsol Preprocessor was to be written in ANSI Cobol, ;which is not usually considered an ideal language for writing compilers and preprocessors. However, as used to produce the Tabsoi Preprocessor, ANSI Cobol has served well. Wherever possible, data formats and arrays were des igned to bes t use the capabilities of Cobol. Deficiencies of Cobol in the area of string manipulat ion were handled by using fixed-length data elements or by using less* than-optimum Cobol language elements. No special machine language routines were used to produce the Tabsol Preprocessor. We feel that the excellent documentati on and machine-independence of Tabsol as implemented in ANSI Cobol outweigh any slight increase in execution time or core requireBents.
The Tabsol Preprocessor, as currently implemented, executes the following tasks:
- Reads Cobol source deck with embedded tables and copies nontable elements.
- Checks each table for format an d usage errors; prints error codes ^en errors are found.
- Converts eacK valid Tabsol table into equivalent Cobol statements and adds these statemen ts to the user's Cobol program.
- Prevents the execution of the Cobol compile step if the Tabso 1 Preprocessor has de cec ted errors C option al) ,
While the above tasks are generally self-explan atory or can be understood by an examination of the final Cobol program created by Tabsol, some comments should be made about the preprocessor listing. While the limits of 10 conditions and 10 actions is reasonably large, our programmers found that most tables wouId seldom exceed two cards per row. Therefore, the preprocessor listing of the user's Cobol program was designed to expand a two-card-per-row table so that the entire row is printed on one line. Thus, visual examination of one- and two-card-per-row tables was facilitated. Note that all tables printed in the final Cobol ou tput listings are presented in NOTE format, one card per print line.
To ease the programmer's task in creating Condition and verb entries within his tables, special abbreviations for both relational oper a tor s and speci al Cobol verb forms were created. The re la t-ional operators are illustrated in Table 2. A sample of Tabsol verb formats is illustrated in Table 3. Extract: Decision Table Optimization
Decision Table Optimization
Prior to the discussion of the various optimization techniques reviewed during the development of the preprocessor, a review of a sample Tabsol table is in order. Figures 2, 3, and 4 illustrate the various phases of the system's output, as seen by the programmer using Tabsol. The sample table used to illustrate Tabsol represents a part of the logic contained in the Tabsol Preprocessor. This table provides the logic to scan each row of the table and form valid, formatted
entries for each condition and action element (an element consists of 16 or less characters between lozenges) within that row.
The table (TABLE TO 2) shown in Figure 2 represents the expanded table produced by the Tabsol Preprocessor, The Cobol program statements, except for table expansion, are printed just as the programmer has entered them. The same decision table is shown in Figure 3 as it appears in the normal Cobol listing. The table is now converted to a Cobol NOTE, The table shown in Figure 3 has been folded an d is much more difficult to follow than the preprocess or-expanded table. The Cobol statements generated by the preprocessor are shown in Figure 4. ; Note that the par agraph names generated by the preprocessor for each row of the table except for the first row are farmed from the combination of the table-name and the row-number. The first row is named with the table-name only.
The following detailed explanation of the logic contained in TABLE T02 illustrates how a specific dec ision table is actually used in the Tabsol Preprocessor, As the preprocessor examines each row of a user's table, it must first validate each condition and action element for correct length. Each element (the characters between two lozenges) must not exceed 16 characters, not counting leading and trailing blanks. Validation of each condition and action element for correct syntax and the generation of equivalent Cobol code is not done until the en tire table has been split into individual elements. Any error in element length prevents subsequent syntax checking and code generation,
A brief explanation of the data-names used in TABLE TQ2 (see Figures 2, 3, and 4) is given in Table 4, below.
The logic illustrated in the decision table TO 2 will process any valid primary or secondary row entry for both conditions and actions. Invalid entries in each row, i.e.; those exceeding 16 characters, are detected in TABLE T02 and subsequently reported in the RGW-ERROR routine. Prior to processing an element, the data-name I is set to point to the first character of the next element space (the space between two lozenges). Processing of this current element character-by-characger, continues until the next delimiter (lozenge) is found or until the current element length exceeds 16 characters.
A number of typical condition and action elements are shown in Table 5. The element, as presented, to TABLE T02, and its resulting conversion and storage into W-A, are shown. A number of input elements are shown without their corresponding converted value. The reader is invited to simulate this portion of the Tabsol Preproceissor logic by passing these elements thru TABLE T02 and writing the resulting chatacters in the W-A array, as directed by the table. Note that the presence of a special edit character in the output data-name is indicated as a space.
A number of optimization techniques were discussed during the development of Tabsol. These techniques included those designed to minimize the number of conditional statements generated by reorganization of the table rows, reduction of unnecessary code generation via redundancy checking, and optimization of action-generated code by the reorganization and combination of actions. We did not fully implemen t these optimization techniques in our first vers ion of Tabsol. Since the preprocessor was deve1 oped under a time and core-size con-straint, program e legance was traded for program availability and usefulness. Note, however, that many table optimization techniques generally save Core and not program execution time.
The preprocessor does attempt to provide loc al optimization. An examination of TABLE T02 (see Fig» ures 2 and 4) illustrates auch optimization. The table shouId have been w ritten using the pound sign for condi ti on 1 in rows two thru four. - This ' repe at' character allows: the preprocessor to produce code that wi11 exit to the next valid row, on an optimum basis. An examination of the Cobol code generated by Tabsol (see Figure 4) shows that if the data item CUR-CHAR does not equal the data item LOZ, the program is to begin its next test at row five (GO TO T02R05),'The same Cobol code would have been generated if the programmer had correctly used the pound sign. This local optimization of condition elements, in conjunction with a programmer-analyst experienced in structuring tables, provides us with very efficient Tabsol tables. (Once familiar with Tabsol, analysts and programmers will structure a table so that like conditions are placed in successive rows of that table. Where possible, they also place those rows containing the most frequently occurring states of the condi t ions at the beginning of the table. )
Another example of programmer-generated optimization is illustrated by the last row in the table T02R16. Here, a number of action elements common to a number of rows in the table, have been created only once. Each row using these elements has a GO TO T02R16 as its last action entry. The procedure-name TQ2R16 will actually be generated as part of the
Cobol statements associated with the last row (row 16) of this table. Thus, the code associated with this common set of statements is generated only once. Of course, such savings could also have been obtain -ed by p lacing the common se t of state men ts in a paragraph, then using the PERFORM verb within the table.
An advantage of Tabsol' s row-by row generation of Cobol statements is that programmers can visually compare the table with the generated Cobol code. This was very helpful during the debugging of Tabsol. In addition, this direct correspondence is reassuring to a Cobol programmer just introduced to the use of decision tables. Extract: TABSOL Experience
TABSOL Experience
The current version of Tabsol has been extensively tested critiqued by members of the BFG Chemical Company programming staff. Our attempts to use initial versions of Tabs ol in our Cobol programs uncovered numerous progr am bugs in the preprocessor. Interaction between the preprocessor development team and the programmers using Tabsol resulted in many improvements and language- extensions to the Tabsol system. During the production of a Tabsol Concepts Manual and a Tabsol Programmer's Guide, a number o£ remaining program problems were eliminated. It is interes ting to note that the production of comprehensive manuals seems to take as much time as the programming of the Tabsol Preprocessor itself!
The Tabsol Preprocessor has reached a stage of development and implementation where it provides a valuable tool for the B. F. Goodrich programming staff. In additi onto our use of Tabsol, if, is currently being marketed as a program product by the Information Systems Division of the B, F. Goodrich Company, Our plans call for additional improvements to the Tabsol language as we11 as ad-ditional optimization of generated code.
Currently, we are developing an integrated documentation technique for the creation of programming documentation. A form of the Tabsol decis-ion table will play a critical part in this system of documentation.
Goodstate, Goodrich documentation system using Tabular Techniques, will allow analysts to rapidly and efficiently write program specifications and logic requirements for both simple and complex programming applications, Most major program logic in Goodstate will be de fined in a Tabsol-like format. Programmers will create actual Tabsol tables from this, documentation. These tables will still be recognisable by the systems analyst who created the Goodstate documentation.
in [ACM] SIGPLAN Notices 6(09) September 1971 Special issue on decision tables view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
in Proceedings of the SIGPLAN symposium on Two-dimensional man-machine communication 1972 , Los Alamos, New Mexico, United States 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 Proceedings of the SIGPLAN symposium on Two-dimensional man-machine communication 1972 , Los Alamos, New Mexico, United States view details
in Annals of the History of Computing 02(3) July 1980 view details
in Annals of the History of Computing 02(3) July 1980 view details