Implement dynamic-capacity tables

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - COBOL Compilers

For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - COBOL Compilers

Thank you for bringing this RFE to our attention. But we believe that if implemented, it will be really slow and error prone. Some clients may have restrictions on using this. This is not in our multi-year strategy. Hence, we'll have to reject this RFE.

I thought I added this already, but..

Firstly, OCCURS UNBOUNDED is only allowed in the linkage section. This means it is limited to:
- Data passed to a program (you cannot create an 'unbounded' table in COBOL working-storage).
- Data created using dynamic memory allocation (such as through CEEGTST and CEECZST, as mentioned below). You'd place the table definition in the linkage section, allocate memory for it, and then point the LS item to the address.

Even the latter is of some limited use, because you have to know the number of elements in the table before you can allocate it.

Dynamic-capacity tables, as defined by the COBOL 2014 standard, can have elements added (to the end) dynamically at run-time. There is no need to know ahead of time how many elements will end up being added to the table.

I would imagine that these tables would be implemented at run-time using some sort of linked-list process (though in behavior they are required to act in almost all cases just like a fixed-length or occurs-depending table).

I personally see this as one of the most important features that can be added to COBOL.

As for adding COBOL 2002 features prior to adding COBOL 2014 features, I don't agree. Features should be added based on their usefulness, and not just how long they have been, ummm, "standard". Note that the TRIM function was only added to 2014!

This is not to say I am not all for adding most of the features of COBOL 2002; I definitely am. But to me there are some things that aren't a priority, such as the Validate feature. I'd had for time to be spent on that feature that could be better spent elsewhere.

I am not sure, but could you define Tables with
"occurs 1 to UNBOUNDED depending on var1"?
Seems to work since COBOL V5.1, but not tested by me.

Added to GSE ADL watchlist.

That's part of COBOL standard 2014 and - not only therefore - necessary.

But. In my personal opinion it would be more senseful to fulfill the requirements based on 2002-standard like:
- bit/boolean support / Usage binary (MR0515073839/MR0511115749))
- exeption handling / Exception processing (MR0515073840 / MR051111259)
- allocate/free storage (MR0515073841)
- Literal Concatenation (MR0511115654)
- Conditional Compilation (MR0511115730)
- Usage float (MR051111587)
- Based Items and Pointers (MR0511115826)
- Validate (MR0314122313 / MR0511115843)
- ENTRY- / CALL-conventions (MR051111591)
- Prototyping (MR0314122314)
- User defined functions (MR051111322)
- Tablesort (MR051111343)
Wouldn't it?

This can be done today with CEEGTST, CEECZST, and SET ADDRESS OF. Having worked with developers on just such a technique, I am voting for this RFE as a more natural implementation.