CODIT(ID:7297/cod009)
Decision table language
Decision table compiler
J.M. Jarvis, Benefit Trust Life Insurance Company, Chicago, Illinois
Related languages
| COBOL-61 | => | CODIT | Extension of | |
| DETAB/65 | => | CODIT | Influence |
References:
History
This paper covers work done over the last five years using decision tables and decision table compilers in the Business applications area. While there is a brief description of the Codit* compiler that has developed out of this work, most of the paper is devoted to setting out the characteristics of decision tables that have emerged from an analysis of systems and programs that have actually been installed using the technique. These characteristics are important since there is no doubt that ignorance of them will ensure failure and disappointment. It is also essential in data processing that we reach a point where we can quantify some of the problems we try to solve, and decision tables, because of their mathematical structure, may provide one such tool.
The statistics given in the paper are drawn from a cost and financial system installed at a steelworks by a group of some twelve programmer Analysts, ans several sys-tema installed at Benefit Trust Life Insurance Company, Chicago. Subsequently in the text, these will be referred to as the Steelworks project, and the BTT, project, respectively.
Extract: How the CODIT compiler works
How the CODIT compiler works
The Codlt compiler accepts a source deck consisting of the following categories of cards: (a) Cobol Identification Division; (b) Cobol Environnent Division; (c) Cobol Data Division; (d) Cobol Procedure Division, other than decision tables; (e) Parameter and Description (Exhibit 1); (f) Table Body (Exhibit 2).
Categories a through d are written to a mass storage file, exactly as submitted, while e is listed for documentation purposes. Category f is listed in decision table format and operated on to generate a Cobol section, which is written to the same file. The contents of the file are then input to the Cobol compiler.
Exhibits 3 and 4 show what the printout of the actual table from items e and f look like.
To illustrate how the code is generated, we will refer to an actual example. The decision table matrix is set up in core &s shown at the top of Exhibit 5* The C1, C2, etc., represent the conditions, and, for the sake of simplicity, the relevant actions for each rule havs been omitted.
By setting the row pointer to 1, condition Cl is examined, and, depending on the combination of Y's, N's and -*s found, simple conditional Cobol code is generated. This has the form:
where: C is the nth condition being tested; *1N is the paragraph name where further checks are to be made; *1 is a two-character alpha prefix and wis a three-digit number, both assigned by the compiler; *2M is the paragraph name preceding programmer-specified actions for rule M, *2 is a two-character alpha prefix supplied by the compiler, and H is a three-digit rule number;
*2P is similar to 2H; *30O1 is the paragraph name for the Else rule, where *3 is a two-character alpha prefix supplied by the compiler.
The brackets indicate alternatives, or portions of the code which may or may not be generated, depending on the particular combination of Y's, N's or -'s
The decision table matrix is now split as shown in Exhibit 5 by removing from the matrix all rules which have a Y in row 1. In the compiler, this is handled as follows: Initially, a one-dimensional control matrix is loaded with the numbers of the rules in the decision table matrix (in the example, 1.2,3,4,5,6,7,3,9, and 10) and each time the matrix is split, the numbers of the rules containing Y's are removed. In the case of row 1, columns 8, 9, and 10 are removed, leaving the contents of the control matrix as 1,2,3,4,5,6, and 7, and rows 2 through 7.
The process is now repeated on this sub-matrix and, so on, until a solution to one or maybe two rules has beer, found. Extract: The Practical Use of Decision Tables
The Practical Use of Decision Tables
4.1 General.
This section gives a brief summary of how decision tables should be applied, and some of their advantages based on experience gained in actual usage.
4.2 What the Technique Offers.
One of the major problems with flowcharting techniques is that the end result is almost 100% programmer-oriented. Often, it is not until a program is far advanced, or even finished, that the quality of the product becomes apparent. Under these circumstances, programming is more an art than a science, and, as such, does not lend itself well to production-type techniques and controls. This is one of the main reasons for high costs and bitter disappointments in the finished products, not to mention the nightmare of maintenance and staff turnover.
The decision table technique, combined with documentation aids and automated by means of a decision table compiler, results in a more scientific approach. The system enforces a logical step-by-step method, involving: the initial analysis of the problem followed by a detailed consideration of its individual components, while ensuring that the program documentation can be completed after the first compilation.
Decision tables provide for easy supervisory control, and they facilitate decomposition of the problem into comprehensible modules, which are linked together to form the finished program.
4.3 Definition of the Program Function.
A written specification of the main functions to be performed by the program, such as reading files, matching files, calculating commission, etc., is the starting point. By either combining or breaking down each of these functions, we end up with a number of "logic sets", each of which comprises naturally-related items of logic.
These logic sets are then related, one to another, to yield the structure of the program. This may be done by developing a small "linking section" written in Cobol, by drawing a very generalized flowchart, or even by means of a decision table, whose function is nothing more than linking the logic sets together.