#30 OCCURS UNBOUNDED TIMES extension (IBM)

[Frank Swarbrick]

This patch is for including changes to implement OCCURS UNBOUNDED TIMES extension (see documentation from IBM in the Language Reference for COBOL 5.1 for z/OS for the syntax and the Programming Guide for details how to use it, too).

[Frank Swarbrick]

diffs for changes attached

[Frank Swarbrick]

Document that ChangeLog can be based on attached.

[Frank Swarbrick]

Programs (and data file) to validate usage.

[Frank Swarbrick]

Note that the file fpddir.txt is a publicly available file from https://www.frbservices.org/EPaymentsDirectory/fpddir.txt, which is why I chose it.

[Frank Swarbrick]

Ready for primetime? Who can say. There are definitely some questions regarding the "deallocation" of these items. Any thoughts are welcome. I will do more research/testing/thinking.

I did just email the request-assign.future to GNU.

[Simon Sobisch]

Thank you so far!

In general: please link the official documentation for these extensions (I've added UNBOUNDED but didn't found BASED ON on the first check).

Concerning the allocation/deallocation:
It is not necessary at all as the Programming Guide says: You can only have this item in LINKAGE-SECTION (is the check in already?). Therefore the storage comes either from a different program or is allocated locally before:

To work with unbounded tables and groups in a single program, do these steps:
1. In the LINKAGE SECTION, define an unbounded table (with the syntax of OCCURS n TO UNBOUNDED), which will be part of an unbounded group.
2. In the WORKING-STORAGE SECTION or LOCAL-STORAGE SECTION, define the OCCURS DEPENDING ON objects.
3. In the PROCEDURE DIVISION, do these steps to process unbounded groups:
a. Set the OCCURS DEPENDING ON objects.
b. Use the LENGTH special register or the LENGTH intrinsic function to compute the total size of the group.
c. Use the CALL statement to call a storage allocation service, such as the Language Environment service CEEGTST. Allocate enough memory for the total length of the group. You will need a pointer to this memory (the CEEGTST service returns a pointer). d. Use the SET statement to establish addressability. For example, SET ADDRESS OF group TO pointer.

So it is all up to the programmer... (OCCURS DYNAMIC is quite different here as it is up to the runtime to allocate the memory).

One thing I've spotted in the parser.y.diff (please place all diffs in one file, as this makes a review easier): all elements starting with an underscore are optional (contain | /* empty */ as first sub-element). You can find this and other styling issues in the [Style guide].

[Frank Swarbrick]

BASED ON is not an IBM extension (or anyone elses extension, as far as I know). It was something I thought would be useful and helpful when it came to actually implementing dynamic capacity tables. Dynamic capacity tables themselves do not use either the UNBOUNDED or the BASED ON syntax, but may use the new fields I put in tree.h in its implementation.

IBM Enterprise COBOL does not support the BASED keyword. All LINKAGE SECTION items that are not included in the PROCEDURE DIVISION USING clause have the same behavior as if they were "based". I do have a check to allow UNBOUNDED only for BASED and LINKAGE SECTION data items.

I thought your prior message had asked for separate diff files. I can certainly do a single file.

I will check out the style guide. I definitely did not know about the leading underscore indicating "optional".

Any other tips are quite welcome!

[Simon Sobisch]

BASED ON is not an IBM extension (or anyone elses extension, as far as I know).

I see. Please reduce this patch to UNBOUNDED it is enough already ;-) and let's discuss BASED ON in the forum later.

For the "conditionally set UNBOUNDED" as reserved keyword: we have the option to do exactly this already: there's the "context sensitive" part (may not be a bad idea to add this, even if it is not context sensitive with IBM) and the "reserve it in general depending on the compiler configuration" (it would be only reserved for the standard configuration without any change and should be added to mf.conf and ibm.conf to be supported there, too - please include this in the next patch version otherwise we may forget this).

[Frank Swarbrick]

I've removed the BASED ON stuff (not yet uploaded). I'm not clear on what I am supposed to do for the "conditionally set UNBOUNDED" reserved keyword. Can you expand on your directions above?

[Simon Sobisch]

I'm not clear on what I am supposed to do for the "conditionally set UNBOUNDED" reserved keyword.

1. Add to reserved.c (already done), this leads to a useable reserved word (if you want to do something you need to add the token in parser.y, done too)
2. As "standard" reserved words will only be active for compiler configurations that include specify-all-reserved: no (=> only the default configuration) add this reserved word to all compiler configurations that should use this (in this case: config/mf.conf, config/ibm.conf)
3. Optional: set this word to be context sensitive (you can check the following implementation with the good sample CB_CS_ROUNDED): add a define for the word that will set the context if not already in cobc/cobc.h (in this case CB_CS_OCCURS) and add it to the word defining the context (in this case it is OCCURS, the second line would look like CB_CS_OCCURS, 0) and to all reserved words that are only active in this context (in this case UNBOUNDED, the second line would look like 0, CB_CS_OCCURS).
   If it should be context sensitive in other configurations than default.conf (you'd have to check the docs from these vendors) add an asterisk in these configurations after the keyword.

If you need more directions leave a note :-)

Edit: changed the typo from cobc/cobc.conf to cobc/cobc.h

[Frank Swarbrick]

Your guidance was excellent, with the slight issue that you meant cobc.h not cobc.conf.

Let's now consider if its worthwhile to make UNBOUNDED only context sensitive. Take the following for example:

::cobolfree
 working-storage section.
 01  unbounded            constant 50.

 linkage section.
 01  my-uodo-table.
     05  my-urow-cnt      pic s9(4) comp.
     05  my-rows          occurs 0 to unbounded 
                                 depending on my-urow-cnt.
         10  my-row.
             15  my-one   pic xxx value 'abc'.
             15  my-two   pic 999 value 999.

Prior to UNBOUNDED this would be the same as if I had specified occurs 0 to 50. Now its meaning is, umm, different. While not a likely situation, is it worth the confusion? Perhaps not.

[Simon Sobisch]

Correct, no context sensitive word here (as long as ibm docs don't state otherwise), of existing programs like your sample doesn't work it either can be changed or -fnot-reserved=unbounded used (the flag is currently -cb_conf=not-reserved:unbounded but this will change in the next 40 hours).

Is the patch ready?

[Edward Hart]

IBM unfortunately does not document what words are context-sensitive, but UNBOUNDED is missing from their reserved word list, which I guess means it's context-sensitive.

[Simon Sobisch]

MF neither has it in their reserved words table nor in their context sensitive table, too...

Let's define it as reserved word as DEPENDING isn't context-sensitive, too (I dropped Bill a note about checking this), we can change it to being context sensitive later if needed.

[Bill Woodger]

I agree with Edward's assessment. IBM do not define UNBOUNDED as Reserved, and do not list context-sensitive words, so I'd have to go for "context sensitive".

Perhaps Frank can check by compiling with V5 a program that has PGMNAME(LONGUPPER) and a PROGRAM-ID of UNBOUNDED. That will determine whether Reserved (failure to compile) or context-only (will compile).

[Frank Swarbrick]

Not sure what PGMNAME(LONGUPPER) has to do with anything, but I compiled a program with the following and it was successful:

 01  unbounded                   pic x value 'N'.
 01  cycle                       pic x value 'Y'.
 01  paragraph                   pic x value 'Y'.
 01  yyyymmdd                    pic x(8).
 01  yyyyddd                     pic x(7).
 [...]
  procedure division.
      accept yyyymmdd from date yyyymmdd
      accept yyyyddd from day yyyyddd
      display unbounded space cycle space paragraph space
              yyyymmdd space yyyyddd space

All of those (except unbounded) are declared as being context-sensitive words in the 2014 standard. Unbounded, of course, is an IBM extension, but appears also to be "context-sensitive". So I guess that is our answer.

I was honestly rather surprised that I could have fields named YYYYMMDD and YYYYDDD!

I'll see if I can get the patch completed an uploaded tonight.

[Bill Woodger]

I thought I'd explained :-)

UNBOUNDED is too long to be a "usual" non-quoted program-name in Enterprise COBOL. So the PGMNAME(LONGUPPER) (you could go for MIXEDUPPER, it wouldn't make any difference).

Then attempt to compiler the program. If the compile is successful, UNBOUNDED is context-sensitive. If the compile is unsuccessful, UNBOUNDED is Reserved (and the documenation is incorrect).

Since the only real issue in determining the answer from the documentation is to ensure that the documentation is correct, this is, to my mind, the simplest way to do it. Mileage may vary.

If you want a surprise, try using the Reserved Word COBOL :-)

[Frank Swarbrick]

I overlooked the "program-id" part.

In any case, "PROGRAM-ID. UNBOUNDED." compiles fine (well, once I eliminated the data item named UNBOUNDED!).

Firstly, I am surprised that the documentation says that "COBOL" is a reserved word. Why should it be?

Is the fact that I can use it as a user defined word the "surprise"?

[Bill Woodger]

I also have no idea why it says it is Reserved. Then subsequently you can use it freely anyway. Two surprises for the price of one. Good for winning bets, though :-)

[Edward Hart]

It might be a remnant of the ENTER COBOL statement (for OS/VS COBOL compatibility, perhaps?).

[Bill Woodger]

Thought that would be fun to try. Seems to accept any single period-terminated word, though. And then turns it into a CONTINUE anyway (Enterprise COBOL).

Did OS/VS COBOL have a working ENTER? The only place I've found it with a (1964) IBM compiler was for AUTOCODER.

I know that Tandem uses ENTER in their COBOL (at least one, anyway) to allow the use of a command-line command (ENTER TACL ...).

PS. Sorry for missing that it was you, Edward, who posted earlier - I've edited that.

[Edward Hart]

Did OS/VS COBOL have a working ENTER?

The 1983 manual says it's treated as documentation. It seems only Tandem COBOL has a working ENTER.

[Simon Sobisch]

Hi Frank, any update for the patch?

[Frank Swarbrick]

Just want to make sure you saw my reply (to the thread but not directly to you) at the end of this thread.

[Simon Sobisch]

Thank you, I've seen it. I'll have a look at it when I find some time - may need some days as I've used nearly all my spare time in the last week to finish the rc-1 yesterday.

The summary sound good (despite of the style issue of the underscore for a not optional definition; Ed brought this up and pointed to the [Style guide] before, please recheck it).

Maybe Edward finds the time to have a more detailed look?

The things that I personally miss in the diff are the Changelog entries (you have most of these posted as text already) and some testsuite entries (if possible every new syntax rule in syn_occurs.at and a working and a not working sample in run_extensions.at) it would be good to start these already.