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

--

  dfdl-wg mailing list

  dfdl-wg@ogf.org

https://www.ogf.org/mailman/listinfo/dfdl-wg