VALUES ARE on TABLE ELEMENTS

[Eugenio Di Lorenzo]

In the following program VALUES ARE clause seems does not work.
Am I the one doing something wrong ?

          >>SOURCE FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTVALUES.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 wTAB-FREQ.
   05 wRAPP-FREQ occurs 7 PIC 9999V9999 VALUES ARE 1 1.125 1.25 1.333 1.5 1.6667 1.875.  
PROCEDURE DIVISION.
    *> display are always ZERO !?!?!  VALUES ARE is not working ...  is it a GnuCOBOL BUG ?
    DISPLAY wRAPP-FREQ(1)
    DISPLAY wRAPP-FREQ(2)
    DISPLAY wRAPP-FREQ(3)
    DISPLAY wRAPP-FREQ(4)
    DISPLAY wRAPP-FREQ(5)
    DISPLAY wRAPP-FREQ(6)
    DISPLAY wRAPP-FREQ(7)   
    STOP RUN.

[Vincent (Bryan) Coen]

Does not work with v3.2 final so suggest you create a bug report.

[Ralph Linkletter]

I have to ask :-)
Why use this syntax ?
Consider an array with 100 variables.
I don't think that even Source Free (that subverted COBOL) could manage such an array with this obtuse "C" like syntax.

Strange to me :-)

[Eugenio Di Lorenzo]

I believe that COBOL syntax is the easiest to read among all programming languages.
Even in this case listing the individual 7 values is the simplest and most natural thing you can have "VALUES ARE x y z etc ".
Assigning 7 values is therefore very simple.
Even if the values were many more, IMHO it remains the most readable solution.
Much easier to use than the usual "REDEFINES".
And I add that you could also write FROM ... TO as follows, even clearer and simpler, perhaps a bit verbose.

WORKING-STORAGE SECTION.
01 wTAB-FREQ.
   05 wRAPP-FREQ occurs 7 PIC 9999V9999 VALUES ARE 1 1.125 1.25 1.333 1.5 1.6667 1.875 FROM (1) TO (7).  

Also in my opinion there is no reason to continue writing COBOL source code with "SOURCE FIXED" when the compiler supports "SOURCE FREE".
All languages now allow you to freely write the line of code without column restrictions,
and with video screens, much larger than the old 3270, which allow you to read long lines of source code well.
If I'm not mistaken, only IBM COBOL on mainframes does not allow SOURCE FREE.

[Ralph Linkletter]

I agree that COBOL is the easiest language to read.
I do not agree with your position on VALUES are.
95 + percent of COBOL is written in IBM COBOL.

To each his own - heh :-)

[Eugenio Di Lorenzo]

Here is another sample program that demonstrates that the "VALUES ARE" clause works in some cases and does not work in some cases.

       >>SOURCE FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTVALUE7.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  WS.
    05  IX1  PIC 99.
    05  IX2  PIC 99.
    05  IX3  PIC 99.
    05  MONTH-IN-YEAR OCCURS 13 TIMES PIC X(3) VALUES "jan" "feb" "mar" "apr" "may" "jun" "jul" "aug" "sep" "oct" "nov" "dec" "Hi".
    05  DAYS-IN-MONTH OCCURS 13 TIMES PIC 9(2) BINARY VALUES 31 28 31 30 31 30 31 31 30 31 30 31.
    05  DAYS-MONTHS   OCCURS 2  TIMES.
        06  DAYX-MONTHX OCCURS 4 TIMES.
            07  DAY-MONTH  OCCURS 3 TIMES.
                10  XXX1   PIC X VALUE " ".
                10  MONTHS PIC X(3)
                    VALUES "Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct" "Nov" "Dec"
                           "JAN" "FEB" "MAR" "APR"  "MAY" "JUN" "JUL" "AUG" "SEP" "OCT" "NOV" "DEC" . *> "Bye".
                10  SEPX   PIC XX VALUE ", ".
                10  DAYS   PIC 99 VALUES 31 28 31 30 31 30 31 31 30 31 30 31   91 28 91 90 91 90 91 91 90 91 90 91.
                10  PER    PIC X  VALUE ".".
            07  FLR        PIC X(4) VALUES " <A>" " <B>" " <C>" " <D>" " <E>" " <F>" " <G>" " <H>" . *> " <*>".

PROCEDURE DIVISION.

DISPLAY "Simple OCCURS with multi VALUES".
PERFORM VARYING IX1 FROM 1 BY 1 UNTIL IX1 > 13
  DISPLAY IX1 ": " MONTH-IN-YEAR(IX1) " has " DAYS-IN-MONTH(IX1) " days" 
END-PERFORM

accept omitted
display space 

DISPLAY "Complex OCCURS with multi VALUES".
PERFORM VARYING IX3 FROM 1 BY 1 UNTIL IX3 > 2
  PERFORM VARYING IX2 FROM 1 BY 1 UNTIL IX2 > 4
      DISPLAY IX3 "-" IX2 ": " DAYX-MONTHX (IX3, IX2)  
  END-PERFORM
  display space
END-PERFORM
STOP RUN.

[Arnold Trembley]

I am surprised. In the past (before retirement), the ONLY place I ever saw or used "VALUES ARE" was in 88 level condition-names. I never imaged this alternate use was allowed or even possible.

The test program does suggest a bug in GnuCOBOL, but in some cases it works amazingly well. I compiled with a MinGW 32-bit GnuCOBOL 3.2 compiler.

Microsoft Windows [Version 10.0.26100.4202]  2025-06-02   0:36:07
C:\cobol>testvalue7
Simple OCCURS with multi VALUES
01: jan has 031 days
02: feb has 028 days
03: mar has 031 days
04: apr has 030 days
05: may has 031 days
06: jun has 030 days
07: jul has 031 days
08: aug has 031 days
09: sep has 030 days
10: oct has 031 days
11: nov has 030 days
12: dec has 031 days
13: Hi  has 000 days


Complex OCCURS with multi VALUES
01-01:  Jan, 31. Feb, 28. Mar, 31. <A>
01-02:  Apr, 30. May, 31. Jun, 30. <B>
01-03:  Jul, 31. Aug, 31. Sep, 30. <C>
01-04:  Oct, 31. Nov, 30. Dec, 31. <D>

02-01:  JAN, 91. FEB, 28. MAR, 91. <E>
02-02:  APR, 90. MAY, 91. JUN, 90. <F>
02-03:  JUL, 91. AUG, 91. SEP, 90. <G>
02-04:  OCT, 91. NOV, 90. DEC, 91. <H>

It seems like "VALUES ARE" did not work as expected for "PIC 99", but worked correctly for "PIC 9(02)". If PIC 9(02) works, I think PIC 99 should work equally as well, by the rule of least astonishment.

[Mickey White]

Neither program will compile on the mainframe.

[Simon Sobisch]

I'm only aware of BS2000 (mainframe from Fujitsu) where this is implemented since decades.
Standard COBOL got that feature (format 3 "table-format") with 2002, I think as soon as customers request that specific feature, it will be in Enterprise COBOL as well (because it is useful and non-conflicting).

Oh, and just a note - someone posted about VALUES x THRU y, but that's really only part of condition-format of VALUE clause (the one edited his/her post, so that info is not here any more, but I still wanted to note that for people reading with a topic-subscription).

Note: I don't think we need a support-option to disable this, but we could alias VALUES to VALUE - because (other than the standard) only with the plural form this "new" (24 year old) feature is active.

... and, we still need a qualified bug report "this works" but "this doesn't", a pre-analysis of the reason is welcomed, but not mandatory :-)

[Arnold Trembley]

I have created a bug report for this:

https://sourceforge.net/p/gnucobol/bugs/1119/