Issue 145 - cobol 88 example with multiple definitions per 88
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
Mike I've seen COBOL value ranges in practice but not when the field is used as a redefines discriminator. I am therefore ok with keeping the elementAlias property as a single value. We can always extend if we have to in the future. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org Date: 03/04/2012 15:42 Subject: [DFDL-WG] Issue 145 - cobol 88 example with multiple definitions per 88 Sent by: dfdl-wg-bounces@ogf.org 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
participants (2)
-
Mike Beckerle -
Steve Hanson