How to Write Cope Decision Tables

    1. Introduction
    2. Limited Entry Tables
    3. Sequence of Rows
    4. Checking of Rules
    5. Multi-Choice Entry
    6. Substituting Numbers
    7. Review of Decision Tables.
    8. Linking Tables into a Program.
    9. Rule Groups
    10. The Else Group
    11. Summary of Groups
    12. Converting Flow-Charts to Decision Tables
    13. Program Testing
    14. Review of Testing
    1. Use of Coding Forms
    2. Format of Tables
    3. Generated Rows
    4. GO TO and STOP Statements
    5. Interpretation of Tables
    6. Cope Operation
    7. Using Cope Efficiently
    8. Getting Started
    9. Error Diagnostics

Up to Barry Dwyer's Home Page



Cope is a program that converts decision tables to Cobol source statements. This text assumes that you have some knowledge of Cobol, but it does not assume any knowledge of decision tables.

A decision table is a way of expressing logic in tabular form. It comprises three elements: a set of conditions that control the logic, a set of executable actions, which depend on the conditions, and a set of rules, which interrelate the conditions with the actions. The rules specify the paths of logical flow through the program.

A decision table performs a similar function to a flowchart. The two are alternatives, but a table has the advantage of being better suited for computer processing. The relationship between flowcharts and decision tables is explained in more detail in the section Converting Flowcharts to Decision Tables.

For systems analysis purposes it is possible to express a problem as a set of rules in an informal language; but if we are prepared to state the rules in a programming language, it is possible to have them automatically converted into a sequence of instructions.

Using Cope, your task is to state the conditions on which the rules depend as Cobol conditions, and the actions that depend on the rules as Cobol statements. You must then list the rules that relate them together.

Cope will work out a suitable flow-chart from the rules you have stated. Once it has done that, it will improve its flow-chart to eliminate duplicated parts. Then it will decide where to put any procedure-names or Go To's that are needed to write the program. Finally, it will produce a Cobol program incorporating the conditions and statements you originally specified.

Cope tables are designed to fit naturally into a Cobol program. They are an addition to the Cobol language. The name Cope means Cobol Plus Enhancements.


Before turning the page, consider the question: What are the advantages or disadvantages of an automatic decision table processor?


Some advantages are:

1) better program documentation,

2) the resulting program is carefully optimised.

Some disadvantages are:

1) additional computer time to prepare programs,

2) it is something else to learn.


The general arrangement of a Cope decision table is shown in Example 1. This table consists of a heading and four rows. The first two rows are conditions, and the last two are actions. A condition row consists of a number of entries followed by the word is and a Cobol condition. An action row consists of a series of entries followed by a Cobol statement.

A vertical column of entries makes a rule. The example has 4 rules. A rule is read down the page. If an entry is a Y the condition to its right has to be true, if it is an N, it must be false. An X indicates a statement to be executed, and a hyphen (-) indicates a statement to be ignored. The first rule in Example 1 is YYX- and reads as follows: "If A is equal to zero and B is equal to zero, move zero to C. (But do not add 1 to C)".

Example-1.  Note Decision Table.
    Y Y N N        is A = 0.
    Y N Y N        is B = 0.
    X X - -        Move 0 to C.
    - X X X        Add 1 to C.
(Alternatively, using two lines per row, the rules may be written on the right:
Example-1.  Note Decision Table.
                    Y Y N N
    is A = 0.
                    Y N Y N
    is B = 0.
                    X X - -
    Move 0 to C.
                    - X X X
    Add 1 to C.
but the one-line format will be used in all the examples that follow).

Problem 1:

If A is zero and B is 1, what will be the resulting value of C?

Problem 2:

If A is not zero, is the value of B relevant?

Answer 1:

C will be set to 1. (The second rule applies).

Answer 2:

No. Rules 3 and 4 select the same statement. In both cases C will be increased by 1.

When the same result is required irrespective of the value of a condition, two rules may be combined. The entry for the condition is written as a hyphen, meaning that it need not be tested. The entry is referred to as a don't care. The resulting table is shown in Example 1a. The hyphen in the second row of the third rule is the don't care. The third rule of this table replaces the third and fourth rules of Example 1.

Example-1-A.     Note Decision Table.
    Y Y N        is A = 0.
    Y N -        is B = 0.
    X X -        Move 0 to C.
    - X X        Add 1 to C.
Although Example 1a expresses the logic more concisely than Example 1, you should not suppose that Cope will produce a shorter program. The Cope processor will combine Rules 3 and 4 of Example 1 automatically. Some programmers will prefer to write tables that explicitly show each combination of conditions separately. The programs they obtain will be the same as if they had combined rules using don't cares.


If there are two conditions, each with two outcomes, four True/False combinations are possible. (True-True, True-False, False-True, and False-False). How many combinations are possible if there are six conditions with True or False outcomes?


64. The first condition has two possible values, True or False. Each value of the first condition can be combined with two possible values for the second. For each of these 4 combinations there are two possibilities for the third condition, making 8 combinations, and so on. In general, if there are n True/False conditions, there are 2 to the power n possible combinations. Because Cope permits a maximum of 50 rules, it is only possible to list all combinations exhaustively when there are 5 conditions or less.

Another situation in which a hyphen may be used as an entry against a condition is when its value is implied by an entry in another rule. For example, both the N entries of Example 1a are implied by Y values in other rules. Replacing them by hyphens gives Example 1b.

Example-1-B.     Note Decision Table.
    Y Y -        is A = 0.
    Y - -        is B = 0.
    X X -        Move 0 to C.
    - X X        Add 1 to C.
In Rule 2 the hyphen in the second row cannot be interpreted as don't care, because Rule 1 specifies a Y. If both conditions (A=0 and B=0) are true, then we shall prefer to use Rule 1, and Rule 2 will not be used. Therefore Rule 2 will only apply if the first condition is true, and the second is not true. Similarly, in Rule 3, the hyphen in the first row must be equivalent to an N.

When a rule has hyphens against all the conditions it is referred to as an else rule. It applies only if no other rule applies, and handles all combinations of conditions that are not handled by other rules: either a specific rule will apply, else the else rule will apply. In Example 1b, Rule 3 is the else rule.

Cope will produce the same program from Example 1b as from Example 1 or Example la.


In Example 1b there is no particular advantage in using an else rule, because Example 1b has just as many rules as Example 1a. When would you expect there to be an advantage?


When there are more conditions, and many more possible combinations. We would probably be able to combine most of the combinations into an else rule.


The sequence of rows in a decision table is important. It is not possible in general to change the order of the rows and retain the same meaning. Example 1c is similar to Example 1b expcept that sequence of the last two rows has been reversed.
Example-1-C.    Note Decision Table.
    Y Y -       is A = 0.
    Y - -       is B = 0.
    - X X       Add 1 to C.
    X X -       Move 0 to C.
Inspection of the table shows that if A is 0 and B is 1, C will be set to 0, not 1 as you worked out for Example 1.

Do not assume that the order of the rows can never be changed without changing the meaning of the table; but, if executing a particular row will affect the value of a variable used in another row, the order of the rows will be important. In Example 1b the 3rd row affects the value of C and the 4th row uses the value of C. When the rows are exchanged, as in Example 1c, the result is different.

Problem 1:

Does the exchange of the 3rd and 4th rows affect Rule 1 or Rule 3?

Problem 2:

Is there any way, in general, that by inspecting a table, it can be determined whether the order of its rows can be changed?

Answer 1:


Answer 2:

Not without also checking the Data Division to see if apparently different data-names redefine the same area. If the table included Perform statements, it would also be necessary to check the instructions to be performed.

It is not practical for Cope to decide if it can safely alter the sequence of rows in a table in order to get a more efficient program. Consequently the testing of conditions and execution of statements in the resulting program will always follow the same logical order as the rows of the table.

Example 1d shows another version of Example 1b. In this case the order of the two operations on C is unchanged, but the 2nd and 3rd rows have been exchanged. The conditions and actions are now interspersed.

Example-1-D.      Note Decision Table.
    Y Y -         is A = 0.
    X X -         Move 0 to C.
    Y N -         is B = 0.
    - X X         Add 1 to C.
This table is perfectly valid, because the decision to set C to zero is not dependent on the value of B. The program that results will be different from that of Example 1b, because the logical order of the statements will follow the same logical order as the rows of the table.

Question 1:

Each rule in Examples 1b and 1d checks the same conditions and performs the same actions; but is there any context in which Example 1d and Example 1b would not give equivalent results? (Here is Example 1b again).

Example-1-B.     Note Decision Table.
    Y Y -        is A = 0.
    Y N -        is B = 0.
    X X -        Move 0 to C.
    - X X        Add 1 to C.
Question 2:

When is it valid for a condition to follow an action? (As in Rows 2 and 3 of Example 1d)?

Answer 1:

Only if B and C redefine the same area of storage. If they did, the condition B=0 would always be true when it was checked in Example 1d (but not in Example 1b), because setting C to zero would also set B to zero.

Answer 2:

Execution of the action must not depend on any condition that follows it. The rules where the action appears must therefore exhaust all the logical combinations of the conditions following the action. If all combinations were not accounted for, then there would be circumstances where, after the action had been performed, it would be found that the rules where it was specified did not apply.


Example 1e is yet another version of Example 1b. This time the order of the rows is unchanged, but the order of the rules is reversed.
Example-1-E.     Note Decision Table.
    - Y Y        is A = 0.
    - - Y        is B = 0.
    - X X        Move 0 to C.
    X X -        Add 1 to C.
This table has exactly the same meaning as Example 1b. Rule 1 is now the else rule. It can be read, "Normally, add 1 to C; but if A is zero, move zero to C and then add 1 to C; unless both A and B are zero, then just move zero to C."


Can you foresee any advantage of making the meaning of the table independent of the order in which the rules are written?


It means that you can write down the rules in the order you think them out, rather than the order they will have to be tested. When you amend a table to correct a program bug, you can add the new rule more easily. (Also, the fact that a hyphen may represent an implied condition means that the rules already in the table will have their meaning suitably modified).

It is important that you understand this point clearly: the meaning of a table depends on the order of its rows but does not depend on the order of its rules.

For any given table, it is always possible to say in which order the rules must be checked in order to select the correct rule, without reference to the particular conditions or actions involved. It is only necessary to consider the entries. If one rule has an entry where the other has a hyphen, it must be checked first. In any other case, the sequence won't matter.


Consider the following set of rules labelled A, B, C, and D.

Y Y - Y
Y Y - Y
- Y - Y
- N - N
- - - N
- - X -
X - - -
- X - -
- - - X
In what order will they need to be checked?


DBAC. In particular, C is an else rule and will be used only if no other rule applies.

The correct sequence of checking is worked out automatically by Cope. The rules are now shown in their proper context in Example 2.

Example-2.    Note Decision Table.
    Y Y Y -   is Month numeric.
    Y Y Y -   is Day numeric.
    Y Y - -   is Month > zero.
    N N - -   is Month > 12.
    Y - - -   is Day > zero.
    N - - -   is Day > Days (Month).
    - - - X   Move "Non-numeric" to Warning.
    - - X -   Move "Month" to Warning.
    - X - -   Move "Day" to Warning.
    X - - -   Move spaces to Warning.
This example will soon be used to demonstrate a number of points, so make sure you understand it now. The objective is to check two elementary items, Month and Day, to see if they are reasonable values for a date. The maximum value possible for a day is determined by reference to a list called Days. Days(1) has value 31, Days(2) has value 28, and so on. The possibility of a leap year is ignored. If the values are satisfactory, Warning is set to spaces, otherwise it is set to indicate the source of the error. "Non-numeric" means that Day or Month is not numeric; "Month" that Month is out of range; "Day", that Day is out of range.

Problem 1:

When there are 6 true/false conditions, there are 64 possible combinations. How many combinations are covered by Rule 1? How many by Rule 2? Rule 3? Rule 4?

Problem 2:

Can all 64 combinations arise in practice? (Or are the conditions related in such a way that some combinations can never occur?)

Answer 1:

Only 1 by Rule 1, because all condition values are specified. Rule 1 is YYYNYN---X, and is only satisfied by the combination: (True, True, True, False, True, False). Because Rule 2 has two hyphens in it (in conditions 5 and 6) it basically will accept 4 combinations. The hyphens could stand for YY, YN, NY or NN. But one of these combinations is covered by Rule 1. So Rule 2 covers 3 combinations (4 minus 1). Similarly, Rule 3, with 4 hyphens, covers 12 combinations (16 minus 3 minus 1). Rule 4 handles the remaining 48.

Answer 2:

No. For example, If Month is greater than 12 it must also be greater than zero. Also, some conditions imply that others are meaningless. For example if Month or Day are non-numeric it is dangerous to check their numeric values. Likewise, if Month is equal to 13, it would not make sense to check Day>Days(13).

Example 2a shows a version of Example 2 where the order in which the conditions are evaluated has been changed.

Example-2-A.   Note Decision Table.
    Y Y Y -    is Day numeric.
    Y - - -    is Day > zero.
    N - - -    is Day > Days (Month).
    Y Y Y -    is Month numeric.
    Y Y - -    is Month > zero.
    N N - -    is Month > 12.
    - - - X    Move "Non-numeric" to Warning.
    - - X -    Move "Month" to Warning.
    - X - -    Move "Day" to Warning.
    X - - -    Move spaces to Warning.
Problem 1:

Is the order in which the conditions are evaluated satisfactory?

Problem 2:

Apart from Example 2 or Example 2a, is any other sequence of rows possible?

Answer 1:

No. Month is used to reference Days before its validity is checked.

Answer 2:

Provided that Month is not used as a subscript until it is known to be a number between 1 and 12, any sequence is valid. It is also necessary to check that Day and Month are numeric before checking their ranges. The order of the action rows is completely unimportant as they are quite independent. Another possible valid sequence is Example 2b.

Example-2-B.   Note Decision Table.
    Y Y Y -    is Month numeric.
    Y Y - -    is Month > zero.
    N N - -    is Month > 12.
    Y Y Y -    is Day numeric.
    Y - - -    is Day > zero.
    N - - -    is Day > Days (Month).
    X - - -    Move spaces to Warning.
    - X - -    Move "Day" to Warning.
    - - X -    Move "Month" to Warning.
    - - - X    Move "Non-numeric" to Warning.
If the proper testing of a condition demands that certain other conditions are already satisfied, it must appear after them in the table. Also, it must have a hyphen entry in any rule where the preconditions are not met. For example, proper checking of Month>zero requires that Month numeric is true. Month>zero must therefore follow Month numeric in the table. In Rule 4, where Month numeric need not be true, there has to be a hyphen against Month>zero, so that it will not be tested.

Cope will generate a flow-chart that copies the sequence of conditions you write in the table. Therefore Example 2 and Example 2b will produce slightly different programs, although both will have the same effect when executed.


Each of the last four rows of the table moves something to Warning. Is there anything you can notice about the relationship between their entries?


Only one is ever selected in any rule.


This introduces a new topic: extended entry, or as we prefer to call it with Cope, multi-choice entry. When we have a number of actions that are similar in some way, we can select the one we want from a list of alternatives. Only one row is used instead of several. Example 2c shows how this is written.
Example-2-C.   Note Decision Table.
    Y Y Y -    is Month numeric.
    Y Y Y -    is Day numeric.
    Y Y - -    is Month > zero.
    N N - -    is Month > 12.
    Y - - -    is Day > zero.
    N - - -    is Day > Days (Month).
    1 2 3 4    Move .. to Warning.
               spaces, "Day", "Month", "Non-numeric".
The notation of two consecutive periods is used to indicate a missing part of a sentence. The sentence is followed by a list of items that can be fitted in place of the two periods. Which item to select is determined by the entry in the table. For example, Rule 3 has an entry of 3 and will therefore select the 3rd item, "Month". The entry in Rule 3 therefore selects the sentence, "Move "Month" to Warning."


What action sentence is selected by Rule 1?


"Move spaces to Warning." The entry is 1, selecting the first item in the list.

In Example 2d, a similar notation has been adopted to merge condition rows 3 and 4. The two periods on this occasion are immediately followed by a third, to mark the end of the condition.

Example-2-D.     Note Decision Table.
    Y Y Y Y -    is Month numeric.
    Y Y Y Y -    is Day numeric.
    1 1 2 - -    is Month > ...  zero, 12.
    Y - - - -    is Day > zero.
    N - - - -    is Day > Days (Month).
    1 2 3 3 4    Move ..  to Warning.
                 spaces, "Day", "Month", "Non-numeric".
In the third row of Example 2d, a 1 means that Month must be greater than zero; and 2 means greater than 12. In Rule 4 the hyphen is an implied condition that Month is neither greater than zero, nor greater than 12 (ie. it is zero or negative).

The intention of the table is that Rule 3 will handle those cases where Month is too large, and Rule 4 where it is too small; leaving Rules 1 and 2 to handle values from 1 to 12.

Unfortunately, Cope will not produce a program from this table that does what is intended. Month>zero will be tested before Month>12. The logic error that results will be the same as if, in Cobol you had written:

If Month > zero go to Rules-1-and-2.
If Month > 12 go to Rule-3.
Any value of Month that satisfies the second condition will also satisfy the first, so Rule 3 will never be selected or executed.

For example, if Month were equal to 13, both Rule 2 ( YY1--2) and Rule 3 (YY2--3) would be satisfied. But only one rule could be selected, and that is Rule 2. Yet there is nothing in Rule 2 to suggest we go on and check for Month>12. Although Cope will construct a flow-chart with a path on it for Rule 3, there is no value of Month that can ever cause that path to be taken.

Problem 1:

If Rule 3 could be checked before Rule 2, the table would be satisfactory. If the rules were written in a different order, would it correct the situation? (Think carefully).

Problem 2:

Is there any way, in general, that Cope could work out automatically which choice to check first?

Answer 1:

No. You will remember that to make it easier to amend a table, the order of the rules is always irrelevant.

Answer 2:

No. Which would you test first, P<M or P<N? The correct sequence will depend on the values of M and N.

In case you should think that using multi-choice entries is more trouble than it is worth, it must be pointed out right away that the logic problem of Example 2d is easily avoided. The situation is saved by choosing the correct sequence for the list of items to be checked: "is Month > ... zero, 12" is inherently wrong.

"Is Month > ... 12, zero" is correct, and implies that the test for greater than 12 must be considered first. If it is, there is no danger of the value 13 being considered merely greater than zero.

In determining the order in which rules should be checked Cope will rely on the numbers of the entries, and check the smallest numbered conditions first. The corrected table is shown in Example 2e.

Example-2-E.     Note Decision Table.
    Y Y Y Y -    is Month numeric.
    Y Y Y Y -    is Day numeric.
    2 2 1 - -    is Month > ...  12, zero.
    Y - - - -    is Day > zero.
    N - - - -    is Day > Days (Month).
    1 2 3 3 4    Move ..  to Warning.
                 spaces, "Day", "Month", "Non-numeric".
The order of checking the rules will be Rule 3, Rule 1, Rule 2, Rule 4, Rule 5. Rule 3 comes before 1 and 2, because it has a 1 in the 3rd row, and Rules 1 and 2 have a 2. Rule 1 will be preferred to Rule 2 because it has entries in Rows 4 and 5 but Rule 2 does not. Rule 4 has a hyphen in the 3rd row, and so comes after Rules 1 and 2. Rule 5 is the else rule, and will be used only if no other rule applies.

It is also useful to look at Rule 4 as an else rule of a kind. The first 4 rules form a sub-table that handles all the combinations of conditions where Month and Day are both numeric. Rule 4 is the else rule for this sub-table.

Problem 1:

Will the following sequence of alternatives be satisfactory?

is Age < ...  20, 30, 40, 50, 70.
Problem 2:

What about the following?

is Year equal to ...  71, 73, 79.

Answer 1:

Yes, irrespective of what entries are specified in the table. Checking of the conditions will occur starting from the left. Therefore, if Age has the value 15, it will be judged <20, rather than <30 or <40, etc. Likewise, if Age<20 and Age<30 are alternatives, Age<30 will only select values 20 through 29. But, presumably, that is what would be intended to happen.

Answer 2:

Yes. Only one condition can be true at any one time, so any order will do.

As a rule, with the less than (<) relation the values in the list should increase from left to right; with greater than (>), they should decrease. With equal to (=), the order never matters.

We can also apply the same notation to rows 4 and 5 of Example 2e, producing Example 2f. (The rules in this table are in a different order to Example 2e).

Example-2-F.       Note Decision Table.
    Y Y Y Y Y -    is Month numeric.
    Y Y Y Y Y -    is Day numeric.
    1 2 2 2 - -    is Month > ...  12, zero.
    - 1 2 - - -    is Day > ...  (Days (Month)), zero.
    3 2 1 2 3 4    Move ..  to Warning.
                   spaces, "Day", "Month", "Non-numeric".
Note that Days (Month) has to be enclosed in parentheses, otherwise it would be regarded as two separate elements, Days and (Month). In common with Cobol syntax generally, elements in a list are separated by spaces, and a comma or semi-colon is purely optional. Therefore the space between Days and (Month) would act as a separator. When (Days (Month)) is inserted, the outermost level of parentheses will be deleted, giving Days (Month).


In the following row, what two action statements are generated?

1 2    Move zero to A ...  (X, Y)  ((X, Y)). 

Move zero to A X, Y. 
Move zero to A (X, Y). 
There is no restriction on where the sequence of two periods can occur in a multi-choice row. Example 2g shows how Example 2f is modified when instead of spaces, we write " ", then move the quotes from the listed items into the model statement.
Example-2-G.       Note Decision Table.
    Y Y Y Y Y -    is Month numeric.
    Y Y Y Y Y -    is Day numeric.
    1 2 2 2 - -    is Month > ...  12, zero.
    - 1 2 - - -    is Day > ...  (Days (Month)), zero.
    3 2 1 2 3 4    Move ".." to Warning.
                   ( ), Day, Month, Non-numeric.
It is necessary for the first element in the list, a space character, to be enclosed in parentheses, or it will be non-significant. A similar treatment is needed when an item to be inserted includes a comma, period or semi-colon, to prevent it acting as punctuation.

You will notice that the table has a different shape from what it had in Example 2. It had 10 rows and 4 rules; now it has 5 rows and 6 rules. Even so, the program that Cope would generate would be almost the same.


In Example 2g, Rows 1 and 2 are True/False choices, and Rows 3 and 4 are three-way choices. (For example, Row 3 distinguishes three ranges of values for Month: greater than 12, from 1 to 12, and zero or negative). With 2 two-way choices and 2 three-way choices, how many combinations are there? How many are covered by each rule?


36 (2 times 2 times 3 times 3): Rule 1, 3; Rule 2, 1; Rule 3, 1; Rule 4, 1; Rule 5, 3; Rule 6, 27. In Rule 1 the combination of the first 3 conditions is specified, leaving the three choices of the fourth row open. In Rule 2, all 4 conditions are specified, giving only 1 combination. Similarly in Rule 3. In Rule 4, although the 4th condition is not specified, only one choice is possible, because the other two are covered by Rules 2 and 3; and so on ...


Suppose we change the problem slightly, and substitute a numeric item, Warning-Code, for Warning. Instead of written messages, we shall use code numbers. Zero will indicate no error, and the three error conditions will be numbered 1 to 3.
Example-2-H.  Note Decision Table.
    Y Y Y Y Y -    is Month numeric.
    Y Y Y Y Y -    is Day numeric.
    1 2 2 2 - -    is Month > ...  12, zero.
    - 1 2 - - -    is Day > ...  (Days (Month)), zero.
    3 2 1 2 3 4    Move ..  to Warning-Code.  0 1 2 3.
This gives us a chance to introduce a useful new notation for inserting numeric values into a statement or condition. Instead of writing numbers in the table that refer to another list of numbers on the right, we can write them directly into the table itself.
Example-2-I.       Note Decision Table.
    Y Y Y Y Y -    is Month numeric.
    Y Y Y Y Y -    is Day numeric.
    1 2 2 2 - -    is Month > ...  12, zero.
    - 1 2 - - -    is Day > ...  (Days (Month)), zero.
    2 1 0 1 2 3    Move ;; to Warning-Code.
Question 1:

Spot the change in the Move statement that indicates that the value of the entry itself is to be substituted.

Question 2:

Could we use the same notation in row 3? (Think carefully).

Answer 1:

Instead of .. there are two semi-colons (;;). (It is not the absence of a list of items to insert, because, if you needed to, you could use both ;; and .. in the same row.)

Answer 2:

Not as things stand. The table we would get is shown in Example 2j.

Example-2-J.        Note Decision Table.
     Y Y Y Y Y -    is Month numeric.
     Y Y Y Y Y -    is Day numeric.
    12 0 0 0 - -    is Month > ;;.
     - 1 2 - - -    is Day > ...  (Days (Month)), zero.
     2 1 0 1 2 3    Move ;; to Warning-Code.
There is nothing wrong with the format. Cope allows multi-choice entries from 0 through 99, so 12 and 0 are perfectly valid. The problem is a logic error, and it is one that you have seen before. Remember, Cope disregards entirely the order of the rules as they are written.


What exactly is wrong? Can it be put right?


We are back to the problem we had in Example 2d. The order in which multi-choice conditions are checked depends solely on the numerical value in the table. Rules 2, 3 and 4 will be checked before Rule 1. If Month had the value 13, it would match Rule 2, 3 or 4 and Rule 1 would never be used.

It is very rarely that the ;; notation can be combined with a greater than (>) relation. (But it is not impossible. For example, is N > Digit-;;. or, is ;; > N.)

It is usually safe to use ;; in conjunction with less than (<), and always safe with equal to (=).

Example 2k shows one possible way of correcting Example 2j.

Example-2-K.          Note Decision Table.
    Y  Y  Y  Y Y -    is Month numeric.
    Y  Y  Y  Y Y -    is Day numeric.
    0 12 12 12 - -    is Month not > ;;.
    -  1  2  - - -    is Day > ...  (Days (Month)), zero.
    2  1  0  1 2 3    Move ;; to Warning-Code.
Note that although we can use an N entry to reverse a True/False condition, there is no equivalent for a multi-choice condition, and the condition in row 3 had to be reversed by using not.

The table now reads as follows:

Rule 1: If Month and Day are numeric and Month is zero or less, move 2 to Warning-Code.

Rule 2: If Month and Day are numeric and Month is not greater than 12, and Day is greater than Days(Month), move 1 to Warning-Code.

Rule 3: If Month and Day are numeric, Month is not greater than 12, and Day is greater than zero, move zero to Warning-Code.

Rule 4: If Month and Day are numeric, Month is not greater than 12, and Day is zero or negative, move 1 to Warning-Code.

Rule 5: If Month and Day are numeric and Month is greater than 12, move 2 to Warning-Code.

Rule 6: If Month and Day are not both numeric, move 3 to Warning-Code.

No question.


Here is a review of the points you have studied so far:

  • Cope is a program that converts decision tables into Cobol instructions.
  • Decision tables comprise conditions, actions and rules.
  • The order of the conditions and actions is usually important, but the order of the rules is always irrelevant.
  • Actions may precede conditions provided that their execution does not depend on them.
  • Conditions and actions can be limited entry (Y N X or -), or multi-choice (0 through 99).
  • Multi-choice rows can either be varied by selecting inserted material from a list, or a number can be taken directly from the entry itself.
  • When you use a multi-choice condition, you must be careful that the items in the list are in a proper sequence.
  • The meaning of a rule can depend on other rules. For example, an else rule handles those combinations not handled by any other rule.
  • One rule is preferred to another if, in the first row where they differ, it has an entry where the other does not, or it has a lower numerical entry.
  • Although with certain combinations of data more than one rule can be satisfied, only the most preferred rule will be selected.

To check your learning so far, here is a problem where you must supply the rules.

Problem-1.  Note table to suffix a 1-digit number.
            is Digit = ;;.
            Move ".." to Suffix.  st nd rd th.
The idea is to convert 1 to "1st", 2 to "2nd", and so on.


The neatest answer is:

Problem-1.  Note table to suffix a 1-digit number.
    1 2 3 -    is Digit =
    1 2 3 4    Move ".." to Suffix.  st nd rd th.
If Digit is 1, the suffix is "st"; if 2, "nd"; if 3, "rd". For any other value the suffix is "th". If your answer was:
Problem-1.  Note table to suffix a 1-digit number.
    0 1 2 3 4 5 6 7 8 9    is Digit = ;;.
    4 1 2 3 4 4 4 4 4 4    Move ".." To Suffix.  st nd rd th.
You would get a similar result. When you see a whole series of rules with the same actions, it is a good opportunity to use an else rule. If you don't use one, Cope will eliminate most of the entries automatically.


This time the objective is to suffix a 2-digit number. Remember that we write 11th, not 11st!

Problem-2.     Note table to suffix a 2-digit number.
               is First-Digit = 1.
               is Second-Digit = ;;.
               Move ".." to Suffix.  st nd rd th.
Supply the rules.

Problem-2.     Note table to suffix a 2-Digit number.
    N N N -    is First-Digit = 1.
    1 2 3 -    is Second-Digit = ;;.
    1 2 3 4    Move ".." to Suffix.  st nd rd th.
(Rule 4 is an else rule.)


This one is a bit tougher. It requires you to supply the number of days in a month. So that you can work out if it's a leap year only if the month is February, the action and conditions are interspersed. (The order in the problem is correct). Assume that if the year divides by 4, it is a leap year.

Problem-3.  Note table to find days in month.
                            is Month = ;;.
                            Divide Year by 4 giving Leap-Year.
                            Multiply 4 by Leap-Year.
                            is Year = Leap-Year.
                            Move ;; to Days-in-Month.
Year, Month and Days-in-Month are numeric variables. Leap-Year is defined as a whole number. If Year was 81, after executing Rows 2 and 3, Leap-Year would equal 80, so Year would not equal Leap-Year. (You can ignore the case where Year is zero.)

Problem-3.  Note table to find days in month.
     9  4  6 11  -  2  2    is Month = ;;.
     -  -  -  -  -  X  X    Divide Year by 4 giving Leap-Year.
     -  -  -  -  -  X  X    Multiply 4 by Leap-Year.
     -  -  -  -  -  -  Y    is Year = Leap-Year.
    30 30 30 30 31 28 29    Move ;; to Days-in-Month.
Rule 1: 30 days hath September.

Rule2: April..

Rule 3: June...

Rule 4: and November.

Rule 5: All the rest have 31,

Rule 6: Excepting February alone, which has 28 days clear,

Rule 7: And 29 in each leap year.


No question.


We shall now begin a new topic: how to incorporate decision tables into a computer program.

The table was written as a series of comment lines, numbered 201300 to 201340. Here is the output that Cope might produce from Example 2k:

201300/Example-2-K.  Note Decision Table.
201310*    Y  Y  Y  Y  Y  -    is Month numeric.
201315*    Y  Y  Y  Y  Y  -    is Day numeric.
201320*    0 12 12 12  -  -    is Month not > ;;.
201330*    -  1  2  -  -  -    is Day > ...  (Days (Month)) zero.
201340*    2  1  0  1  2  3    Move ;; to Warning-Code.
201341*    End of table.  5 correctly coded rows,  6 rules.
201342*    (In Row 1, Rule 6 is implied from Y or N entry in Rule 1)
201343*    (In Row 2, Rule 6 is implied from Y or N entry in Rule 1)
201345 Example-2-K.
201346     If Month numeric;
201347     If Day numeric; go to Example-2-K-1315.
201346 Example-2-K-1520.
201349     Move 3 to Warning-Code.  go to Example-2-K-exit.
201350 Example-2-K-1315.
201351     If Month not > 0; go to Example-2-K-1515.
201352     If Month not > 12 next sentence else
201353         go to Example-2-K-1515.
201354     If Day > Days (Month) go to Example-2-K-1516.
201355     If Day > zero next sentence else Go To Example-2-K-1516.
201356     Move 0 to Warning-Code.  go to Example-2-K-exit.
201357 Example-2-K-1516.
201358     Move 1 to Warning-Code.  go to Example-2-K-exit.
201359 Example-2-K-1515.
201360     Move 2 to Warning-Code.
201361 Example-2-K-exit.
201362     exit.
There are a number of features you should notice.

  • The table is reproduced as part of the output.
  • A series of paragraphs are generated.
  • The last procedure name has the suffix -exit.
  • The other procedure names are suffixed by number codes.
  • The generated code may not be pretty, but it is fast and compact.

Does any condition test or action statement appear more than once?


No. Each occurs exactly once.

The procedure-names generated by Cope consist of the procedure-name of the table heading followed by a suffix. Suffixes consist of a hyphen and from 1 to 4 digits, or the suffix -exit. Apart from -exit, the exact values of the suffixes may vary any time you amend the table, or might differ between different versions of Cope. You are not intended to refer to these names.

A decision table will be executed when control is passed to it by means of a Go To or a Perform, or when control passes sequentially from the statement that precedes it. If you wanted to transfer control to Example 2k by a Go To you would write:

Go to Example-2-K. 
Or, if you wanted to Perform Example 2k, you would write:
Perform Example-2-K thru Example-2-K-exit. 

If Example 2k formed the entire content of a section called Check-Date, what alternative Perform statement could you use?

Perform Check-Date.
You may refer to the procedure-name of a table or its Exit paragraph within the table itself if you wish. Example 3 illustrates the use of both procedure-names within the table.
Procedure Division.
    Open Input Source.
Read-Source.  Note table to skip blank lines.
    X X    Read Source, at end Go To Read-Source-exit.
    Y N    is Source-Line = spaces.
    - X    Display Source-Line.
    X X    Go To Read-Source.
    Close Source.
    Stop Run.
Example 3.

It would be possible to code sophisticated programs completely using decision tables linked by Performs or Go To's, but it would not be entirely convenient. We could find it necessary to code some parts of a program, especially those involving loops, as a series of linked tables. This would be poor documentation, because it would be necessary to read a number of tables to follow the logic of the program. That is, of course, completely contrary to the purpose of decision tables. The one thing we want to avoid is to have to follow the logical flow all over the program listing.


In order to avoid linking between tables, a Cope table can consist of more than one decision table. A series of linked tables related to a particular problem can therefore be written as a single table.


Writing a series of related decision tables as one Cope table doesn't sound much of an advantage. Can you see any merit in it?


When tables are interrelated, they will have similar actions and conditions. A combined table will be shorter to write, and will often produce a more efficient Cobol program. But you would not be well advised to try to put as much into one table as you possibly can. A better technique is to split your program into sub-routines, then write each sub-routine as a Cope table.

Example 3a shows Example 3 written as a Cope table.

Procedure Division.
Example-3-A.   Note table to process source lines.
    1 2 2 3    Group.
    X - - -    Open Input Source.
    - X X -    Read Source, at end Go To Example-3-A-3.
    - Y N -    is Source-Line = spaces.
    - - X -    Display Source-Line.
    - - - X    Close Source.
    - - - X    Stop Run.
    2 2 2 -    Next Group.
The rules are divided into groups. There is one rule in Group 1, 2 rules in Group 2, and 1 rule in Group 3. Each group is a separate decision table. (Although Groups 1 and 3 have only one rule each, they are still valid).

At any one time, only the rules in one particular group can be selected. The lowest numbered group is chosen first: in this example, Group 1. After a rule from the group has been selected, its Next Group entry will determine which group of rules can be considered next. In the example, Rule 1 will then select Group 2 (Rules 2 and 3).

Problem 1:

Does the table contain a loop?

Problem 2:

Can you spot how control eventually reaches Group 3?

Answer 1:

Yes. Both rules in Group 2 select Group 2 again.

Answer 2:

Via the Go To statement in the 3rd row. The procedure-name Example-3-A-3 signifies the start of the decision table made up of the rules in Group 3 (ie., Rule 4).

As this example shows, when a table is divided into groups, a specific name is given to the procedure-name that starts the instructions for each group of rules. In Example 3a, the following procedure-names will be generated:

Example-3-A. The entry-point for the table.
Example-3-A-1. The entry-point for Group 1.
Example-3-A-2. The entry-point for Group 2.
Example-3-A-3. The entry-point for Group 3.
Example-3-A-exit. The exit-point for the table.

Because Group 1 is the lowest numbered group in the table, Example-3-A and Example-3-A-1 are logically equivalent procedure names. Go To Example-3-A and Go To Example-3-A-1 would have the same effect.


Refer back to Example 3. If the procedure Initialisation in Example 3 corresponds to the procedure Example-3-A-1 in Example 3a, which procedure-names correspond to Example-3-A-2 and Example-3-A-3?


Example-3-A-2 corresponds to Read-Source and Example-3-A-3 corresponds to Finish.

A more sophisticated table is shown in Example 4. This table merges two files by the balance line method, and nicely illustrates the symmetry with which the two files are handled. However, the purpose of this example is not to illustrate the logic of a balance line merge, but to introduce some further notational points.

Example-4.  Note table to collate Update and Master files.
    1 2 3 4 4 5 5 5 6 6 6    Group.
    X - - - - - - - - - -    Open input Update, Master.
    - - - - - 1 - - 2 - -    is ..-Key > Last-Key.  Update, Master.
    - - - - - - 1 - - 2 -    is ..-Key < Next-Key.  Update, Master.
    - 1 2 - - - 1 - - 2 -    Read .. at end Move High-Values to
                                 ..-Key.  Update, Master.
    - 1 2 - - 1 1 - 2 2 -    If ..-Key < Next-Key Move ..-Key to
                                 Next-Key.  Update Master.
    - - - X X - - - - - -    Move Next-Key to This-Key.
    - - - X X - - - - - -    Perform Process-This-Key.
    - - - X X - - - - - -    Move This-Key to Last-Key.
    X - - X X - - - - - -    Move High-Values to Next -Key.
    - - - Y N - - - - - -    is Last-Key = High-Values.
    - - - X - - - - - - -    Close Update, Master.
    2 3 4 - 5 6 6 6 4 4 4    Next Group.
    Note groups have following functions.
    1  Open files.
    2  Force 1st read on Update.
    3  Force 1st read on Master.
    4  Process matched or unmatched record.
    5  Read new Update record as needed.
    6  Read new Master record as needed.
    Stop Run.
Notice in the sixth row, the action is a conditional statement beginning with the word If. It is not a condition; conditions always begin with Is. The use of the conditional statement saves 6 additional rules and an extra row.

Comments have been included in the table both as part of the Note sentence that begins the table, and following the word Note at the end of the table. These comments have no effect on the Cobol statements generated by Cope.


Here is a problem where you must supply the Group and Next Group entries. The table is intended to search an ordered list using the binary search technique. Two pointers, Min and Max, are set to point at the lowest and highest points in the list between which the required item might lie. At each stage, Probe is set to the mid-point of Min and Max to determine if the required item is in the top or bottom half of the list, or has been found. If it has not been found, either Min or Max is updated and another try is made. If Min and Max cross over without Probe locating the required item, it is not in the list and Probe is set to zero.

Problem-4.       Note Table.
    X - - - -    Move 1 to Min.
    X - - - -    Move Top to Max.
    - N N N Y    is Min > Max.
    - X X X -    Add Min, Max giving Probe.
    - X X X -    Divide 2 into Probe.
    - 1 2 3 -    is Desired-Item ..  Item (Probe).
      < = >.
    - X - - -    Subtract 1 from Probe giving Max.
    - - - X -    Add 1, Probe giving Min.
    - - - - X    Move zero to Probe.
                 Next Group.
(NB The value list for Row 6 has been written directly under its entries. This is quite in order. Cope, like Cobol, allows you to start and finish sentences anywhere you like within Area B. Usually, it will be best to continue rows to the right and leave the left-hand part of the form for the entries. But, in Problem 4, writing the values under the entries might be considered neater.)

Problem-4.       Note Table.
    1 2 2 2 2    Group.
    X - - - -    Move 1 to Min.
    X - - - -    Move Top to Max.
    - N N N Y    is Min > Max.
    - X X X -    Add Min, Max giving Probe.
    - X X X -    Divide 2 into Probe.
    - 1 2 3 -    is Desired-Item ..  Item (Probe).
      < = >.
    - X - - -    Subtract 1 from Probe giving Max.
    - - - X -    Add 1, Probe giving Min.
    - - - - X    Move zero to Probe.
    2 2 - 2 -    Next Group.


If desired, the Group entry for a rule need not be specified, and the entry may be written as a hyphen. Such a rule can then be selected as part of any group, but only if no numbered rule can be selected. Unnumbered rules are mainly used to trap error conditions.
Example-5.       Note Table.
    1 2 3 4 -    Group.
    - Y - - -    is Acct-Code numeric.
    - Y - - -    is Acct-Code < 1000.
    - - 1 2 -    is ..-In = .. (Acct-Code).
                 Charge, Password.
    1 2 3 - -    Display "Please type your ...".
                 (Account Code)  (Charge No)  (Password).
    1 2 3 - -    Accept ...  Ac-Code Charge-In Password-In.
    - - - 0 1    Move ;; to Error-Flag.
    2 3 4 - -    Next Group.
In Example 5, if any condition in Rules 2, 3 or 4 is not satisfied, Rule 5 will be selected.

Although Rule 1 is associated with the procedure-name Example-5-1, and so on, no particular procedure-name is associated with Rule 5, because it is not numbered.

Note that the use of a hyphen in the Group row is like its use in a multi-choice condition, and in the Next Group row, like its use in a multi-choice action.


Here is a review of the main points regarding groups.

  • Rules may be sub-divided into groups.
  • Groups may be numbered 0 to 99.
  • Execution of a table begins with its lowest numbered group.
  • Only rules with the number of the current group, or unnumbered rules, can be selected.
  • An unnumbered rule will be selected only if no numbered rule can be satisfied.
  • When groups are used, each rule must have a Next Group entry to specify which group of rules is to be applied after the rule has been selected and executed.
  • If the Next Group entry is a hyphen, control passes to the exit-point.
  • The entry-point of the table, the entry-point of each group, and the exit-point of the table have procedure-names that may be referenced by Go To and Perform statements.
  • The use of groups is optional.
  • Conditional statements such as Read or If, and sequence control statements such as Go To and Perform may be used freely in action rows.


In spite of their apparent dissimilarity, Cope tables and flow-charts have a great deal in common. In fact, if you consider the requirements of a language that would describe a flow-chart to a computer, it would be pretty much like Cope.

You would need to define the contents of the condition boxes and the action boxes, and you would need to detail the connections between them. One convenient way of defining the connections would be to consider each path through the flow-chart and mark off each of the boxes you passed through, being careful to note whether the flow leaves the decision boxes through Yes or No exits. If you did this, you would find that each flow path was exactly the same as a rule of a decision table.

This means that if you have difficulty in solving a problem without the use of a flow-chart, you can still use one at the design stage, and then convert it to a decision table. On the next page we shall give a worked example of how the conversion is done.

The technique is especially useful until you get a feel for using Cope. It enables you to plan the number of rules you will need so that you can lay out the coding neatly. It also helps you spot similar actions and conditions, which can be combined into multi-choice row. As you gain experience, you will find that you will need this preliminary flow-charting stage less often.

The example is a flow-chart that collates two files using the high-low-equal technique. It is therefore similar in function to Example 4, which collates two files using the balance-line method. Do not confuse the two examples, they use different logic, and there is no reason to expect that the Cope tables will be similar.

In the high-low-equals technique, we read a record from each file, and compare their keys. If the keys are equal, we have a matched master and update record. If the keys are unequal, the record with the lower key is unmatched and we must skip over it before attempting to match the next pair of records. At end-of-file, high-value keys are inserted, to ensure the merge completes correctly. When both files show high-value keys, the run is terminated.

Here is the flow-chart:

          (Start)--------->Open Files
          |                    v
          |               Read Update
          |                    |
          | .----------------->|
          | |                  v
          | |             Read Master
          | |                  |
          | |                  |<-----------------------.
          | |                  v                        |
          | |     .--Update key ? Master key----.       |
          | |     |            |                |       |
          | |  (>)|         (=)|             (<)|       |
          | |     v            v                v       |
          | |  Process    End of File?--.    Process    |
          | | Odd Master       |        |   Odd Update  |
          | |_____|        (No)|   (Yes)|       |       |
          |                    v        v       v       |
          |                 Process   Close    Read     |
          |                 Matched   Files   Update    |
          |                 Records     |       |_______|
          |____________________|        v
Our first step is to locate the decision-trees on the flow-chart. A decision-tree is a series of decision boxes that split a single flow into two or more separate paths. We will make each decision-tree into a rule group. There is only one tree in the example, "Update key ? Master key" plus "End of File?" There are four paths leaving the tree (>, =/No, =/Yes, and <) so the group will have 4 rules. We follow each path and devise a list of actions that we can check off for each rule. We continue along a path until we reach either the exit, or a decision box.

Finally, because the Start connector is linked to the decision tree by a list of actions, a further rule is needed to do the initial set of actions. The table we get is:

Flow-Chart-Example.   Note Table.
    1 2 2 2 2    Group.
    X - - - -    Open Input Update, Master.
    - 1 2 2 3    is Update-Key ..  Master-Key.   > = <.
    - - Y N -    is Master-Key = High-Values.
    - 1 - 2 3    Perform ...  Odd-Master Matched-Pair Odd-Update.
    X - - X X    Read Update at end Move High-Value to Update-Key.
    X X - X -    Read Master at end Move High-Value to Master-Key.
    - - X - -    Close Update, Master.
    - - X - -    Stop Run.
    2 2 - 2 2    Next Group.
Rule 1 performs the initial set of actions. The 4 rules in Group 2 correspond to the four paths that leave the decision tree.


Once you have written a table that is acceptable both to Cope and the Cobol compiler, it will be unlikely to contain any logic errors. Writing tables is less error-prone than writing ordinary code. In a table, the logic is more clearly set out, so you are less likely to make a mistake. Also, Cope is able to make a number of useful checks on the logical relationships between the rules.

Even so, you will want to check if the set of rules you have specified in each table is correct. As a guide, you should devise a test case to satisfy each rule of each table. If you wish, you can trace your program by temporarily adding multi-choice rows containing Display statements.

For example, Problem 3 could be traced as follows:

Problem-3.  Note table to find days in the month.
     9  4  6 11  -  2  2    is Month = ;;.
     -  -  -  -  -  X  X    Divide Year by 4 giving Leap-Year.
     -  -  -  -  -  X  X    Multiply 4 by Leap-Year.
     -  -  -  -  -  -  Y    is Year = Leap-Year.
    30 30 30 30 31 28 29    Move ;; to Days-in-Month.
     1  2  3  4  5  6  7    Display "Problem-3, Rule ;;.".
A decision table clearly documents the test cases it requires. Seven tests should be quite sufficient to check Problem-3: one for each rule. There is no point checking different values of Year unless Month = 2, or trying both Month = 1 and Month = 3 (unless you don't trust Cope to work correctly).


Supply the entries for the following table to check Problem-3.

Test-1.  Note Table.
    1 2 3  4 5 6 7    Group.
                      Move ;; to Month.
                      Move ..  to Year.  79 80.
                      Perform Problem-3 thru Problem-3-exit.
                      If Days-in-Month not = ..  Display
                      "Error in Test ;;.".  30 30 30 30 31 29 29.
    2 3 4  5 6 7 -    Next Group.

Test-1.  Note Table.
    1 2 3  4 5 6 7    Group.
    9 4 6 11 1 2 2    Move ;; to Month.
    1 1 1  1 1 1 2    Move ..  to Year.  79 80.
    X X X  X X X X    Perform Problem-3 thru Problem-3-exit.
    1 2 3  4 5 6 7    If Days-in-Month not = ..  Display
                      "Error in Test ;;.".  30 30 30 30 31 29 29.
    2 3 4  5 6 7 -    Next Group.
The particular arrangement of Group and Next Group entries in this test is typical of what is needed for testing, and simply selects each rule in turn. A special notation is provided for this purpose, and is shown below.
Test-1.  Note Table.
    Ascending Group.
    9 4 6 11 1 2 2    Move ;; to Month.
    1 1 1  1 1 1 2    Move ..  to Year.  79 80.
    X X X  X X X X    Perform Problem-3 thru Prodlem-3-exit.
    1 2 3  4 5 6 7    If Days-in-Month not = ..  Display
                      "Error in Test ;;.".  30 30 30 30 31 29 29.
No Next Group row is required.


If you use an Ascending Group row, is it logically possible to have any condition rows?


No. Since there is only one rule in each group, no alternative rule is possible. Therefore to specify conditions would imply that if they failed, the table would be logically in error, because no alternative rule could be selected.

Another approach to testing is to provide for all possible combinations of test values. Here is this method used in testing Problem 3, which is given 24 separate tests.

Test-1-A.  Note Table.
        Ascending Group.
    1 2 3 4 5 6 7 8 9 10 11 12 Move ;; to Month.
    3 1 3 2 3 2 3 3 2  3  2  3 Move 79 to Year;
                               Perform Problem-3 thru Problem-3-exit;
                               If Days-in-Month not = ..;
                               Display Month, Year, " Error.".
                               28 30 31.
    3 1 3 2 3 2 3 3 2  3  2  3 Move 80 to Year;
                               Perform Problem-3 thru Problem-3-exit;
                               If Days-in-Month not = ..;
                               Display Month, Year, " Error.".
                               29 30 31.
Rows 2 and 3 of Test la differ only in the value moved to Year and the values compared with Days-in-Month. The entries and the rest of the action are identical. When it is desired to repeat a row, paired commas (,,) may be used as a shorthand; as in Test 1b. (The list of inserted values is not repeated, and must always be written out).
Test-1-B.  Note Table.
        Ascending Group.
    1 2 3 4 5 6 7 8 9 10 11 12 Move ;; to Month.
    3 1 3 2 3 2 3 3 2  3  2  3 Move .. to Year;
                               Perform Problem-3 thru Problem-3-exit;
                               If Days-in-Month not = ..;
                               Display Month, Year, " Error.".
                               79 79 79; 28 30 31.
               ,,              80 80 80; 29 30 31.

How may different checks of Problem-3 will be made by Test 1b?


24. Two in each rule, exactly as in Test 1a.

If desired, the entries in a row may be specified, and the remainder of the model indicated by a pair of commas. This could be done to Test 1b to give Test 1c.

Test-1-C.  Note Table.
        Ascending Group.
    1 2 3 4 5 6 7 8 9 10 11 12 Move ;; to Month.
    3 1 3 2 3 2 3 3 2  3  2  3 Move .. to Year;
                               Perform Problem-3 thru Problem-3-exit;
                               If Days-in-Month not = ..;
                               Display, Month, Year " Error.".
                                  79 79 79; 28 30 31.
    3 1 3 2 3 2 3 3 2  3  2  3 ,, 80 80 80; 29 30 31.
Specifying the entries in this instance however, is quite unnecessary, because the two sets of entries are identical.

Another point illustrated by Test 1b and Test 1c concerns rows with more than one pair of periods. In previous examples where rows had more than one set of periods, the value to be inserted was the same for each pair. In these two examples, the values for the first pair and second pair are different. The complete list of values for the first pair must precede the list for the second pair. The number of values in each list must equal the highest entry in the row.


Refer back to Example 2k. Complete the rules in the following table in order to test it. It can be assumed that Days (Month) will have the correct values.

Test-2.  Note Table.
       Ascending Group.
                       Move .. to Month.  0 1 12 13 "X".
                       Move .. to Day.    0 1 31 32 "X".
                       Perform Example-2-K thru Example-2-K-exit.
                       If Warning-Code not = ;;
                           Display Month, Day, Warning-Code.
(NB The verb Display is part of the same row as the verb If.)


Here is a reasonably thorough test:

Test-2.  Note Table.
       Ascending Group.
    1 2 2 2 2 2 3 4 5  Move .. to Month.  0 1 12 13 "X".
    2 1 2 3 4 5 2 2 2  Move .. to Day.    0 1 31 32 "X".
    X X X X X X X X X  Perform Example-2-K thru Example-2-K-exit.
    2 1 0 0 1 3 0 2 3  If Warning-Code not = ;;
                           Display Month, Day, Warning-Code.
Tests 1 and 2 both checked subroutines by means of Perform statements. A different kind of testing method is to use tables to generate test files using Write statements.

When the number of test value combinations obtainable from one table is inadequate, tables can be linked by Perform's.


In the following example, if Output-Header writes one record and Output-Details writes 10 records, how many records will be written to Employees?

Generate-File.  Note Table.
    Ascending Group.
    X - - - - -    Open Output Employees.
    1 2 3 4 5 6    Move .. to Dept-Code.
                   1000 2001 2002 3004 7777 9990.
    1 2 3 4 5 6    Move ".." to Dept-Name.
                   Stamping Assembly Sales Maintenance
                   Personnel Administration.
    X X X X X X    Perform Output-Header thru Output-Header-exit.
    X X X X X X    Perform Output-Details thru Output-Details-exit.
    - - - - - X    Close Employees.


66. Eleven in each rule.


Here are the main points you should remember about testing:

  • Decision tables are easy to check, because the various cases are clearly documented.
  • It is easy to add Display statements to trace program execution.
  • The Ascending Group row makes it easier to write test routines.
  • Paired commas may be used to repeat a row when desired. This is especially useful when writing test routines.
  • When paired commas are used, the entries may either be specified or not, as desired.



We have completed the description of Cope tables, without giving a formal definition of the format. This will now be remedied.

There are two variants of the same basic format, depending on whether the Cobol compiler supports the use of Note paragraphs or of comment lines. (If the compiler allows both, either may be used.) The Note paragraph form is the more basic and will be described first.

Cope tables are written on normal Cobol coding forms. The procedure-name that names the table must begin in Area A (columns 8 through 11). All other entries must appear in Area B. A row may begin anywhere, although most programmers will prefer to align the start of each row in column 12.

A Cope table is a special form of Note paragraph. The first sentence of the table must begin with the words Note Table or Note Decision Table, without intermediate punctuation. The sentence may be extended with a comment, eg, to describe the function of the table. Other forms of Note paragraph are allowed, but are not processed by Cope.

Although a table is a Note paragraph, the ordinary rules for continuing words and literals must be observed throughout. Usually it will be convenient to continue lines away from the area used for the rules. The end of the table corresponds to the end of the Note paragraph.

A table is terminated by any line that begins in Area A, even if it is a comment line. The only exception is when the comment line is used to continue a word or literal. (See below.)

Except for multi-choice conditions and actions each row is written as a sentence. Multi-choice conditions and actions may consist of two sentences; a model, and a list of values to be inserted.

If a sentence begins with the word Note, it, and each following sentence is treated as a comment.

As in most Cobol usages, commas or semi-colons are optional, (except within quotes), but if used, must be followed by a space. Likewise a period, when required, must also be followed by a space. Outside quotes, a sequence of any number of spaces is treated as a single space. Although Cobol does not permit a space to precede a punctuation character, Cope does allow spaces, if desired to improve readability.


1 2 3    is Year > ..  .  40 30 20.
    1 2 0 - -    If X = ;; ; Add 1 to Counter.
Paired periods, commas or semi-colons may have no intervening spaces, and if they are split between lines, a hyphen is required in column 7 of the continuation line. None of these pairs has any special meaning except in the first sentence of a multi-choice row. In addition, paired commas only have meaning at the start of a row or immediately following multi-choice entries. However, a pair of punctuation characters is always treated as a single language element wherever it is encountered. To be treated as punctuation, a comma, semi-colon or period must be followed by a space.

Some Cobol compilers make allowance for an alternate quote character, usually the apostrophe ('). This character may be used to enclose non-numeric literals containing quotes. Throughout this text, any reference to quotes also includes alternate quotes.

When the compiler makes provision for comment lines indicated by an asterisk (*) or slash (/) in the continuation column, the same format is followed exactly, except for two modifications: First, each table line must contain an asterisk or slash in the continuation column. Second, if a literal or word is continued, the hyphen must not appear in the continuation column, but in the first column of Area A, and the continuation column must contain an asterisk. The literal or word itself may be continued anywhere in Area B. (Such a continuation line does not, of course, terminate the table).

The code generated by Cope differs slightly between formats, and depends on what is in the continuation column of the last line of the table.


A Cope table may have one of the following formats:

Format 1

{table-name}.  NOTE DECISION TABLE [comment] .
    { [condition-row]...
    [ NOTE {comment} .  
      [ {comment} .  ]...

Format 2

{table-name}.  NOTE DECISION TABLE [comment] .
    {numeric-entry}...  GROUP .
    { [condition-row]...
      {action-row} ...
    {numeric-entry}...  NEXT GROUP .
    [ NOTE {comment} .  
      [ {comment} . ]...

Format 3

{table-name}.  NOTE DECISION TABLE [comment] .
    [ NOTE {comment} .  
      [ {comment} .  ]...

(Format 2 is the most general format. A Format 1 table is equivalent to a Format 2 table in which each numeric entry in the GROUP and NEXT GROUP sentences is a hyphen. A Format 3 table is equivalent to a Format 2 table in which the entries in the Group sentence are 1, 2, 3... (n-1), n and the entries in the Next Group sentence are 2, 3, 4... n, -.)

A {condition-row} is defined as follows:

Format 1 (Limited-entry)

{condition-entry} ...  IS {condition} .

Format 2 (Multi-choice)

    {numeric-entry} ...  IS {model-condition} .
        [ {value}...  .
          [ [ {numeric-entry}...  ] ,, {value} ... .  ]...

An {action-row} is defined as follows:

Format 1 (Limited entry)

    {action-entry}...  {statement} .

Format 2 (Multi-choice)

    {numeric-entry} ...  {model-statement} .
        [ {value}... .
          [ [ {numeric entry}...  ] ,, {value}... .  ]...

(A Format 2 condition or action row is equivalent to one or more Format 1 condition or action rows, according to the rules for generated rows, which follow shortly).

A {table-name} is a Cobol procedure-name, not exceeding 25 characters.

A {comment} is any string balanced with respect to quotes.

A {numeric-entry} is a number from 0 to 99 or a hyphen. Leading zeros are not permitted; 01 must be written as 1.

A {condition-entry} is the letter Y, the letter N, or a hyphen.

An {action-entry} is the letter X, or a hyphen.

A {condition} is any Cobol condition (simple or compound).

A {statement} is any Cobol imperative or conditional statement. (But not a compiler directing statement).

A {value} is any string balanced with respect to quotes, and with respect to parentheses not enclosed in quotes, delimited by a space or punctuation character.

A {model-condition} or {model-statement} is any string that is balanced with respect to quotes and will generate a Cobol {condition} or {statement}.


A multi-choice row is logically equivalent to a number of limited entry rows, called its generated rows. The rules for determining the equivalent rows are as follows:

If the model condition or statement contains paired semi-colons, a row is generated for each different numerical value in the entries, starting with the lowest. The generated row is constructed as follows. Each entry is replaced by a hyphen, unless it has the numerical value for which the row is being generated, in which case the entry is replaced by an X, if it is an action row, or a Y, if it is a condition row. Each occurrence of paired semi-colons is itself replaced by the numerical value for which the row is being generated. Example:

    2 1 4 -    Move ;; to Item-;;-A.
generates rows for the values 1,2 and 4 as follows:
    - X - -    Move 1 to Item-1-A.
    X - - -    Move 2 to Item-2-A.
    - - X -    Move 4 to Item-4-A.
When the model contains paired periods the same rules apply, but in addition, each pair of periods is replaced by a value from the list of values in the following sentence. The list of values is comprised of a number of sub-lists. The number of values in each sub-list must equal the value of the highest entry in the row. The number of sub-lists must, in the first instance, equal the number of pairs of periods. But, if the number of sub-lists is less, the list is presumed to wrap around as required. For example, if there is only one sub-list, it will be regarded as if it were repeated the required number of times.

For example,

    2 1 4 -    Perform ..  thru ..-exit.  A B C D; A B C D.
    2 1 4 -    Perform ..  thru ..-exit.  A B C D.
both generate:
    - X - -    Perform A thru A-exit.
    X - - -    Perform B thru B-exit.
    - - X -    Perform D thru D-exit.
The number of values in a sub-list must equal the value of the highest entry, not the number of distinct entries. The above example requires 4 values, even though the 3rd value is irrelevant. The total number of values in the list must be a whole multiple of the highest entry in the row.

The value of the entry in the table therefore specifies the position of the replacement value within the sub-list. The order of the sub-lists corresponds to the sequence of the paired periods.

In the special case that the entry is a zero, no value is inserted to replace the periods, ie., the periods are simply deleted. The pair of periods will also be deleted if the value to be inserted is missing or null. The following example:

    0 1 2 3 -    Move A.. to Temp; Move B.. to A..; Move Temp to B...
                 (), , (2).
    X - - - -    Move A to Temp; Move B to A; Move Temp to B.
    - X - - -    Move A to Temp; Move B to A; Move Temp to B.
    - - X - -    Move A to Temp; Move B to A; Move Temp to B.
    - - - X -    Move A2 to Temp; Move B2 to A2; Move Temp to B2.
In the first row no value is to be inserted, in the second row the value is null, in the third it is missing. Only in the fourth row is a value inserted.

When a value to be inserted contains parentheses (not enclosed in quotes), as in the above example, the value is modified before insertion by removing the outermost level of parentheses. The parentheses need not enclose the entire value. For example: "(Days(Month))" and "Days((Month))" will both cause "Days(Month)" to be inserted.

A series of spaces enclosed in parentheses, but not inside quotes, is equivalent to a single space. The value, (   ), will cause not three spaces, but one space, to be inserted. If it is desired to insert three spaces, the value must be written ( )( )( ).

If a multi-choice model contains paired periods, it may be followed by one or more repeat rows. Repeat rows are designated by paired commas, occurring either at the start of a row, or immediately following the entries. Only the model can be repeated, the value list must be written explicitly each time. If the paired commas are placed at the start of the row, the entire model row is repeated; if after the entries, only the condition or statement is repeated. For example:

    1 2 3 -    Move zero to ...  A B C.
    1 2 1 2    ,, X Y.  ,, P Q.
generates the multi-choice rows,
    1 2 3 -    Move zero to ...  A B C.
    1 2 1 2    Move zero to ...  X Y.
    1 2 1 2    Move zero to ...  P Q.
(In the third row, the entries repeat those of the second, not the first row). The multi-choice rows then generate limited-entry rows, as described above. Thus the example is equivalent to 7 limited-entry rows in all.

An occurrence of paired punctuation characters outside of their proper context is not forbidden, but no replacement takes place. They can appear freely in limited-entry rows or value lists.


Although action statements may legitimately begin with the verbs Go To or Stop, they must be used with care. Normally, the sequence of execution will not pass from a Go To or Stop statement to the following statement, because it is transferred to a different procedure, or the program terminates. Consequently, when an action row beginning with the words Go To or Stop is logically followed by the table exit-point, Cope will assume that following the corresponding statement in the generated Cobol program, there will be no need for a statement to transfer control to the exit-point, because it would never be used.

If, however, there is a condition or action entry logically following the Go To or Stop entry, it is assumed that the same sequence is desired in the Cobol program. Control can reach this second statement if a Go to ... depending on ... statement has its control variable out of range, or if the program is re-started following a Stop statement.

A problem may arise under the following (unlikely) circumstances:

  • An action begins with the words Go To or Stop.

  • The action entry is not followed by any other action entry before the exit-point is reached.

  • It is desired that in some circumstances control should pass through the Go To or Stop to the exit-point of the table.

In such cases, control would pass through the Go To or Stop to a random point, not necessarily the exit-point.


Restart-Problem.  Note Table.
    N Y    is X = 0.
    X X    Stop run.
    X -    Move 1 to X.
An attempt to restart the program after the Stop in Rule 1 would be successful, but in Rule 2 it would not.

To avoid the problem, the offending action may be followed by a further Go To row, to transfer control explicitly to the table exit-point. Alternatively, the words Go To or Stop can be inserted into a model action row, as follows:

    1 1 - - 1    ...  (Go to A, B, C depending on N).
This will prevent Cope recognising the row as a Go To or Stop row.


The meaning of a Cope table may be defined formally by specifying which rule will be selected in any given circumstance. Not every set of rules that can be written is capable of valid interpretation. The following rules define the action of a valid table.

1) If a Group sentence is used the table can be logically replaced by a number of tables corresponding to each Group. Unnumbered rules are included in each of these tables, except where they would be redundant. The Next Group sentence is then equivalent to a multi-choice row in which the words Next Group are replaced by Go To {table-name}-;;.

2) Multi-choice rows are replaced by their generated limited-entry rows.

(After these two substitutions, all tables are reduced to limited entry tables without rule groups).

3) A Y entry is satisfied if the corresponding condition is true; an N entry is satisfied if it is false; a hyphen entry is always satisfied.

4) A rule is satisfied if all conditions in the rule are satisfied.

5) A rule is preferred to a second rule if, in the first row in which they differ, it contains a Y or N, and the second contains a hyphen.

6) Each time control of the program passes to a table, one rule, and only one rule, is selected and executed. The rule selected is the most preferred rule that is satisfied.

7) Within a rule, conditions are evaluated and actions are executed in the written order of the rows.

8) A condition is evaluated, or an action executed, if it has an entry in the most preferred rule for which all conditions in the preceding rows are satisfied.

In order for a table to be validly constructed, it must comply with certain other rules:

9) Under any set of conditions, at least one rule must be satisfied. However, if this stipulation is not met, one or more condition entries will be assumed to be redundant. For example, in the table:

Table-X.  Note Table.
    1 2 3    is X .. 0.   < = >.
    1 2 3    Move ;; to Y.
Cope will assume that testing X>0 is redundant, as no rule can be selected if all three tests fail. Cope would issue a warning message.

10) Every rule must be capable of being selected under some set of condition values.

11) A rule may contain condition entries following action entries, provided that, whatever the result of evaluating these conditions, there is some other rule that will be satisfied, and which also contains the same action entries. However, if this condition is not met, Cope will assume one or more condition entries is redundant, as in Rule 3 in Clause 9 above.


The Cope program reads a source file, called the Cope source file, and produces an output file, called the Cobol target file. The Cope source file must consist of 80-column lines, which are assumed to be in standard Cobol format. Unless Cope encounters a decision table, each source line is copied to the target file without modification.

When decision tables are encountered, Cope will add Cobol lines following each table. If Cope discovers syntactical or logical errors within a table, it will insert appropriate comments into the target program. Therefore, if the target program is processed by a Cobol compiler, the compiler listing will contain all the information needed to check the Cope source file.

The usual operating arrangement is shown in Figure 1.

  ________      _________       ________      _________       ________
 /        |    |         |     /        |    |         |     /        |
|  Cope   |--->|  Cope   |--->|  Cobol  |--->|  Cobol  |--->| object  |
| source  |    | program |    |  target |    | compiler|    | program |
|_________|    |_________|    |_________|    |_________|    |_________|
                                             | compiler|
                                             | listing |
                                             |     _-_ |
                                              \___/   \| 

Figure 1: How Cope interfaces with a Cobol Compiler

Cope will also insert a number of lines into the target program at the end of its Procedure Division, summarising the tables processed. By referring to the end of the Procedure Division, you will be able to check if Cope found any errors. Cope notes each syntax error immediately after the source line causing the error, and notes logic errors immediately following the table.

Cope does not attempt to analyse the syntax of Cobol conditions or statements. Cobol errors will be diagnosed by the Cobol compiler from the generated code. You must then relate the Cobol error to the appropriate Cope source line. This is usually straightforward. Because Cope does not check Cobol syntax, it may be used both with ANS and non-standard compiler features.

If you use sequence numbers in the Cope source file, the target Cobol program will also be sequenced. As a rule, the target line numbers will equal the corresponding source line numbers. Lines inserted by Cope will be sequenced in ones. It is therefore best to leave about 100 unused numbers between tables. If the gaps are insufficient, the sequence numbers of the copied lines will be adjusted, in order to avoid sequence errors. Because Cope copies the sequence numbers from the source file to the target file, you don't need a cross-reference listing.

If you use columns 73-80 of a source line for program identification, Cope will copy the identification to the target line. Lines inserted by Cope have the same identification as the last source line copied.

If a Copy statement is used to copy decision tables from a source statement library, the tables must be processed by Cope before being placed in the library. Although Cope is normally used to process a complete source program, it will actually process any arbitrary collection of source lines. In many cases, it will also copy non-Cobol lines successfully, such as library update control statements.


Although the order of the rows in a table is important, in some cases more than one order is possible. It is possible for some of these sequences to be better than others, either in terms of execution time, or storage utilisation, or both.

Consider Example 6:

Example-6.           Note Table.
    1 1 2 2 3 3 -    is Client-Assets > ...   5000 500 100.
    Y N Y N Y N -    is Credit-OK.
    1 2 1 2 1 2 2    Move .. to Loan-Status.  Approve, Refer.
    1 4 2 4 3 4 4    Move .. to Max-Loan.     4000 300 50 zero.
In this example, the first and second rows could be interchanged, or the 3rd and 4th rows interchanged. Which arrangement would be best?

The action Move Approve to Loan-Status will need to be generated 3 separate times. It appears in Rules 1, 3 and 5, and in each rule it is followed by a different action. Consequently, it is not possible for Cope to devise a flowchart where only one copy of the action is generated. On the other hand, the action Move Refer to Loan-Status will be generated only once because it is always followed by the same action, which in turn is always followed by the exit-point. In this case Cope can arrange things so that both actions appear only once.

We call these actions a common tail. Cope will recognise common tails and generate the Cobol statements once rather than several times.


If you exchanged the order of the 3rd and 4th rows, would Cope be able to produce a better program?


Yes. It would no longer be necessary for Move Approve to Loan-Status to be generated more than once. The table you would get is shown in Example 6a:

Example-6-A.        Note Table.
    1 1 2 2 3 3 -   is Client-Assets > ...   5000 500 100.
    Y N Y N Y N -   is Credit-OK.
    1 4 2 4 3 4 4   Move .. to Max-Loan.     4000 300 50 zero.
    1 2 1 2 1 2 2   Move .. to Loan-Status.  Approve, Refer.
Example 6a has two common tails:
    Move zero to Max-Loan.
    Move Refer to Loan-Status.
    Move Approve to Loan-Status.
In the resulting program, each different action will appear only once. But some improvement is still possible, because the condition Credit-OK will still need to appear 3 times. Although its N entries have a common tail in Rules 2, 4 and 6, its Y entries do not, so it is not possible for Cope to combine the 3 tests into one decision.

Look what happens when we exchange the first two rows and re-group the rules:

Example-6-B.  Note Table.
    Y Y Y N N N -   is Credit-OK.
    1 2 3 1 2 3 -   is Client-Assets > ...   5000 500 100.
    1 2 3 4 4 4 4   Move .. to Max-Loan.     4000 300 50 zero.
    1 1 1 2 2 2 2   Move .. to Loan-Status.  Approve, Refer.

Is this an improvement?


Yes, some of the condition tests become redundant, and the last four rules can be combined into a single else rule.

Example-6-C.  Note Table.
    Y Y Y -    is Credit-OK.
    1 2 3 -    is Client-Assets > ...   5000 500 100.
    1 2 3 4    Move .. to Max-Loan.     4000 300 50 zero.
    1 1 1 2    Move .. to Loan-Status.  Approve, Refer.
Example 6c will give a flowchart where each condition and action appears once only. But since Example 6b and 6c are equivalent, so will Example 6b. Cope will detect and remove the redundant condition tests in Rules 4, 5 and 6. But Cope cannot achieve these same results from Example 6 or 6a, because it will not interchange rows.

In order to obtain the most compact programs you should therefore arrange the rows to give common tails. You should also choose a sequence of condition rows that leads to the least number of rules being required. (Neither of these operations is likely to have much effect on execution time.)

In order to improve execution time it is necessary to consider the frequency with which rules will be selected. If in Example 6 the most common situation were for Client-Assets to be less than 100 and Credit-OK to be true, Rule 4 would be the one most frequently chosen. But it would not be selected until after the other 3 rules had been rejected. By writing the second condition in the form

    is Client-Assets not > ...  100 500 5000.
and making other changes as necessary, execution time would be improved. The most efficient table will be one in which the most preferred rules are also the most frequently used. (See Interpretation of Tables for the definition of preferred.)

The table that gives the fastest execution time may not always be optimal in terms of storage utilisation.

Because as a programmer you can be aware of factors that Cope cannot take into account, you have the opportunity to influence the efficiency of the Cobol programs that Cope produces. By studying these programs in detail, you will quickly learn how to get the best results.

A method that has proved most useful when it is desired to obtain the best execution efficiency is to monitor the number of times each rule of each table is executed. This is easily achieved by temporarily adding a row to each table.

In Example 6c a suitable row could read:

    1 2 3 4    Add 1 to Rule-Count (6, ;;).
and would best be placed between rows 2 and 3.


Why at that particular point?


To maximise the common tails. (Actually in this example placing the new row between rows 3 and 4 would be no worse, but in general, the best place is immediately after the last condition row.)


In this text we have progressed from an informal description of Cope to a formal definition. Most of the material has therefore appeared twice. The later sections are mainly intended for reference. In the process of reading, you should have acquired a working knowledge of decision tables, and the use of Cope. Further understanding can only come through experience, and it is inevitable that at first you may be reluctant to abandon your traditional methods of programming in exchange for a technique you are not sure of. It is therefore appropriate to mention here what are believed to be the advantages of using Cope.

  • With practice, decision tables are easier to read than source programs.
  • The documentation given by the tables is always up-to-date.
  • The need for flow-charting is eliminated.
  • Certain types of logical errors cannot occur.
  • It easier to debug programs using decision tables. In particular, it is easy to identify those cases that may have caused a particular action to be executed.
  • Tables are a convenient tool for generating test data.
  • The number of runs required to debug a program is usually reduced.
  • There is less danger of introducing undesired side-effects when programs are amended.
  • The number of lines you need to write and maintain is reduced, which has a number of secondary benefits.
  • Decision tables are useful means of human-to-human communication, especially with people who are not computer literate.
You should not expect that the first time that you write a program using Cope you will find it easy. You are more likely to find it rather frustrating. Many of Cope's advantages are felt during debugging and maintenance, rather than during coding. A good plan for getting to know Cope is to use one of the exercises in the text, for example, Test 2 and Example 2k make up a simple Procedure Division, which you can incorporate in a trial program. You could also start by re-coding a program you have already written, preferably one for which you have kept flow-charts. You will then be able to compare the two different methods of programming.


This section includes a list of all error diagnostics issued by Cope. The text of a message is inserted into the target program immediately following the line in error, or in some cases following the table in error. A summary is given at the end of the Procedure Division, as follows:
    nnnn Note paragraph(s) found,
    pppp with a valid table heading.
    qqqq had no coding errors, and
    rrrr had no serious logic errors.
You should check this summary. The numbers pppp, qqqq and rrrr should be equal. If the number nnnn is greater than pppp you should check that the Note paragraphs without valid table headings are meant to be ordinary Notes and are not meant to be decision tables. If the summary indicates that some tables have errors, you must refer back to them to locate the particular problem.

Errors are divided into two classes: coding (syntax) errors, and logic errors. Coding errors are errors in the format of a table, and include such problems as misplaced periods, etc. Logic errors are errors in the entries in the table that give rise to problems in generating a flow-chart. Errors in the syntax of Cobol elements are not diagnosed by Cope, but by the associated Cobol compiler. To aid the detection of these errors even when Cope is unable to analyse a table correctly, the processor will create dummy statements for those rows that can be analysed properly.

Dummy statements will be preceded by one or other of these warnings:

Unable to analyze some of your coding.
No attempt will be made to analyze the logic. 
Owing to serious logic errors,
no attempt will be made to generate a correct program. 
The error diagnostics are listed here alphabetically. Unless otherwise stated, the errors are coding errors.

Bug in processor.  Message type is nn.

Should never occur. If it does occur, please forward the listing to aid debugging.

Column 7 should be all * or /, or all spaces or hyphens.

Either a table should be laid out as an old-style Note paragraph, or as a comment in the form of a Note paragraph. The entries in column 7 suggest a mixture of styles. Possibly due to the table not being terminated correctly by an entry in Area A.

Complexity of table caused processor storage overflow.

The total number of uses of paired periods and semi-colons, plus the number of values to be inserted, plus the number of rows in the table has exceeded an internal limit. Split the table into smaller sub-routines.

Condition follows ASCENDING GROUP sentence.

If the Ascending Group sentence is used, it is logically impossible to have any condition rows.

End of the table, but not the end of a sentence.

The end of the table has been detected (because of an entry in Area A, etc.) But the previous line did not terminate with a period.

Entries are all hyphens.  Sentence discarded.

All entries in the row are hyphens. Alternatively, the left-most entry that is not a hyphen is invalid, and has been mistaken for a Cobol word.

Entries are followed by word NOTE.  Sentence discarded.

An action may not be a Note statement, owing to its unpredictable effects on the target Cobol program. Any comments must precede or follow the table rows. (A Note following the table does not have entries.)

Entries followed by NOTE in first row.  Sentence discarded.

Similar to the preceding message. The next row of the table will be regarded as if it were the first row.

Entry in Row nn, Rule rr is a comment - no valid alternative.

This is a logic error, but not a serious logic error. The appearance of this message may not indicate an actual problem. Considered in the context of other rules, the entry in Row nn Rule rr may be logically replaced by a hyphen, because if the indicated test were found to be false there is no (less-preferred) rule that could apply. The entry is therefore considered as documentation only. If there are other rules that have equal entries in Row 1 through Row rr, the message also applies to them. Either the indicated test is logically unnecessary, or an additional rule should be provided.

Entry is invalid because of leading zero.

A numeric entry less than 10 must be written as a single digit.

Group nn is in a loop of linked Group and Next Group entries.  

This is a serious logic error. It indicates that the specified Group entry leads immediately to a Next Group entry, which in turn leads directly to a Group entry, in a closed loop.

Group nn is in Next Group sentence but not in Group sentence.  

This is a serious logic error. It is impossible for Cope to construct a proper program, as there is no valid logic flow following any rule that specifies the offending group.

Group nn is not linked to table entry-point.

This is a logic error, but not a serious logic error. The group is either not referenced in the Next Group row, or is not referenced by any rule connected to the table entry-point. It may therefore only be reached by means of a Go To or Perform statement.

GROUP sentence, but no NEXT GROUP sentence.

The first row of the table was a Group sentence, but the last row of the table has been encountered, and was not a Next Group sentence.

GROUP sentence has invalid syntax.  Checking rest of table.  

What is presumed to be a Group sentence is wrongly formatted.

GROUP sentence is not first in table.  Sentence discarded.  

The Group sentence, if used, must be the first sentence after the table heading.

If test in Row nn, Rule rr fails, Row pp will be tested next.

A logic error, but not necessarily serious. Cope cannot construct a program that implements the rules as stated and preserves the logical order of the condition rows. Rule rr has a hyphen in Row pp, but there is at least one less preferred rule that does not. If the condition in Row nn, Rule rr is tested, and is not satisfied, Row pp will need to be tested, breaking the normal logical ordering.

(In Row nn, Rule ee is implied from Y or N entry in Rule rr).  

This message documents the use of implied conditions or else rules. The hyphen in Row nn, Rule ee must be considered as a less preferred alternative to the entry in Rule rr. (Rule ee is an else rule). If the hyphen can logically be replaced by Y or N the table will be easier to follow.

There is no corresponding message for multi-choice conditions.

Invalid combination of entries.  Sentence discarded.

Some combination of entries such as Y or N with X, or a number with a letter has been found.

Less values to insert than highest entry requires.

The last complete sentence is presumed to be a list of values to be inserted into the preceding sentence. If so, the number of values in the list must be at least equal to the highest valued entry in the row. Probably due to a misplaced period.

More than 99 paired periods.  Sentence discarded.

No more than 99 paired periods are allowed in any multi-choice row.

More than 99 values to insert.  Sentence discarded.

The last complete sentence was presumed to be a value list, and was found to contain over 99 values. Only 99 values are allowed in any one list. Probably due to an unmatched left parenthesis.

More values to insert than can be used.

The number of values in a value list cannot usefully exceed the product of the highest entry in the row and the number of paired periods in the model. Probably due to a misplaced period.

NEXT GROUP but no GROUP sentence.  Sentence discarded.

Either the table did not contain a valid Group sentence, or it contained an ascending group sentence, for which no Next Group sentence is required.

NEXT GROUP has invalid syntax.  Checking rest of table.  

What is presumably a Next Group sentence is wrongly formatted.

No space follows word IS.  Sentence discarded.

A correctly formatted condition requires a space following the word is.

No valid action sentences.  Table ignored.

A valid table must contain at least one valid action sentence.

Note end of table, nn correctly coded rows, rr rules.

This does not indicate an error. However, it may be worth checking that nn and rr equal the intended number of rows and rules.

Number of valid entries differs from preceding row.

The key word is valid. The error can be caused by an invalid entry, eg., a number exceeding 99. The error will usually occur twice: once following the row in error, and once following the subsequent row.

Number of values is not a multiple of highest entry.

It is required that the number of values be some multiple of the highest entry in the row. The error is possibly due to a misplaced period, or a value containing delimiters not being enclosed in parentheses.

Numeric entries but no paired periods or semi-colons.

Some entries are numbers, but the remainder of the row does not contain any paired periods or semi-colons. There is therefore no place for values to be inserted.

Over 50 entries.  Sentence discarded.

Cope tables are limited to a maximum of 50 rules. (This is more entries than can be written on one line).

Over 50 rows.  Sentence discarded.

Cope tables are limited to a maximum of 50 condition or action rows.

Over 99 nested parentheses.  Sentence discarded.

The parentheses are assumed to surround a value in a value list. Possibly due to a missing quote.

Paired commas not after multi-choice.  Sentence discarded.  

A row begins with paired commas or has numeric entries followed by paired commas, but the preceding row is not a multi-choice row. (A valid limited entry row cannot begin with paired commas).

Paired commas with Y N or X entries.  Sentence discarded.  

A row Y, N or X entries followed by paired commas. Paired commas may only be used with numeric entries, or with no entries at all.

Period found where action was expected.  Sentence discarded.  

A period was found immediately after the entries. Possibly due to a wrong continuation line or misuse of paired periods.

Period where condition was expected.  Sentence discarded.

A period was found immediately after the word Is. Possibly due to a wrong continuation line or misuse of paired periods.

Period where values were expected.  Sentence discarded.

A spurious period was found at the end of a model. Possibly due to a wrong continuation line or misuse of paired periods.

Previous line did not split a literal.  Hyphen ignored.

The line immediately above contains a hyphen in column 7 and the first character in Area B is a quote. But the line before that did not end with a broken non-numeric literal.

Quote assumed to precede first character of line.

The line has a hyphen in column 7, and the first character in Area B is not a quote, but the line before it began a non-numeric literal that was not completed. It is assumed that the continuation line should have contained a quote preceding the first character in Area B.

Quote inserted at end of line to terminate literal.

There is no hyphen in column 7 of the line, but the line before it began but did not complete a non-numeric literal. It is assumed that a quote should have appeared at the end of the line.

Rule nn can never be validly selected.

This is a serious logic error. There is no combination of conditions where Rule nn is the most preferred rule that can be selected. The error may arise because an attempt has been made to make an action depend on a condition that follows in a later row.

Sentence follows NEXT GROUP sentence.  Sentence discarded.

A Next Group sentence has previously been found but the sentence on the line above the message is not a Note sentence.

Table begins with a NOTE sentence.  Sentence discarded.

Normally any Note sentences must follow the last row of the table. If a Note is found at the start of the table, it is assumed that the Note is out of place, and not that the table has no rows.

Table name exceeds 25 characters.  Checking rest of table.

Because the procedure names generated by Cope append a suffix (eg. "-exit") to the table name, the name is limited to 25 characters in length.

The last row of the table is a condition.

The last row of the table (except for any Notes) cannot usefully be a condition row.

Total size of table exceeds storage area.

The total number of characters in the table, as written, excluding Notes, exceeds an internal limit of the processor. Split the table into smaller sub-routines.

Unpaired right parenthesis.  Prior sentence also discarded.  

The right parenthesis appears in a sentence that is presumed to be a list of values. The right parenthesis is not matched by a preceding left parenthesis. The entire row is ignored.

Unwanted values or sentence starts wrongly.  Discarded.  

The sentence does not begin with an entry or the word Note or paired commas, nor is a list of values required at that point.

X entry is followed by IS.  Sentence discarded.  

An X implies an action row, whereas is implies a condition.

Y or N entry not followed by IS.  Sentence discarded.

A Y or N entry implies a condition row, but the condition row is not properly formatted.

This page has been accessed times since 12th June 1997.

Up to Barry Dwyer's Home Page