[DFDL-WG] Issue 145 - cobol 88 example with multiple definitions per 88

[Mike Beckerle]

Cobol below illustrates how the 88 statement can define more than one
constant to represent a selection. E.g., the definition for Consonant
below.

A single "Accept Char....When Consonant" test tests the char value
against the entire specification including individual enums, and the
ranges specified as well.

This is the mechanism I've seen used to specify that several different
enumerated codes correspond to the same record format. I've only seen
the multiple enumerated constants in practice, not the range
specifications:


IDENTIFICATION DIVISION.
PROGRAM-ID.  Conditions.
AUTHOR.  Michael Coughlan.
* An example program demonstrating the use of
* condition names (level 88's).
* The EVALUATE and PERFORM verbs are also used.

DATA DIVISION.
WORKING-STORAGE SECTION.
01  Char               PIC X.
    88 Vowel           VALUE "a", "e", "i", "o", "u".
    88 Consonant       VALUE "b", "c", "d", "f", "g", "h"
                             "j" THRU "n", "p" THRU "t", "v" THRU "z".
    88 Digit           VALUE "0" THRU "9".
    88 ValidCharacter  VALUE "a" THRU "z", "0" THRU "9".

PROCEDURE DIVISION.
Begin.
    DISPLAY "Enter lower case character or digit. No data ends.".
    ACCEPT Char.
    PERFORM UNTIL NOT ValidCharacter
        EVALUATE TRUE
           WHEN Vowel DISPLAY "The letter " Char " is a vowel."
           WHEN Consonant DISPLAY "The letter " Char " is a consonant."
           WHEN Digit DISPLAY Char " is a digit."
           WHEN OTHER DISPLAY "problems found"
        END-EVALUATE
    END-PERFORM
    STOP RUN.


I suggest that tests as complicated as the ones above that include
range specifications should turn into normal discriminators in DFDL.

But what if it was just enumerated values, e.g., I take the ranges off....

01  Char               PIC XX.
    88 BaseRecord     VALUE "a1", "11", "52".
    88 Ext-Record       VALUE "bb", "b0"

This is the example I've actually seen in data.

So in this case we just need the ability for the elementAlias to be a
list of potential values.

Or we can just be satisfied with requiring each of a1, 11, and 52 to
be a separate element with a different name, so the above becomes a
choice of 6 things, or we can just require a regular old discriminator
in any case more general than single-value dispatch.

I wanted everyone to see the example, but I actually advocate the
narrowest possible definition here. I think the dfdl:elementAlias
should be exactly one value only, and users should use a discriminator
with a test for anything more general.

...mikeb