Implement dynamic-capacity tables

Whilst this RFE is a valid COBOL Standard requirement, based on our current plans and priorities, it is not likely that this could be implemented in the next 12 months, or in the next IBM Enterprise COBOL for z/OS compiler release. Correspondingly this requirement is being declined at this point. The requirement will be kept in our internal RFE backlog. As we work towards becoming aligned with the COBOL Standard, this RFE might be reassessed in the future. You also have an opportunity to resubmit in 12 months time if you wish it to be reconsidered then.

Moving this RFE to the 'Uncommitted Candidate' State.

This RFE is being discussed further.

The syntax is different, but that's essentially how dynamic capacity tables work as defined by the 2014 standard.

01 my-table.
05 my-row occurs dynamic, capacity in my-capacity, indexed by my-index.
10 my-table-field1 pic x.
10 my-table-field2 pic x.

*> my-capacity initially set to 0

set my-capacity up by 1
set my-index to my-capacity
move 'A' to my-table-field1(my-index)
move 'Z' to my-table-field2(my-index)

The "concerning" feature I believe is that I could have coded just the following instead:
set my-index up by 1
move 'A' to my-table-field1(my-index)
move 'Z' to my-table-field2(my-index)

Assuming that my-index was previously set to 0 the above code would have caused the runtime to detect that my-index is now greater than my-capacity and it would have adjusted my-capacity to match, allocated the proper storage, and effectively "inserted" a new row in the table.

Good or bad idea? I'm unsure. It could definitely cause some unintended behavior if you "my-index" is not properly set to 0 initially. But I would hope that the compiler would set it properly and that the programmer wouldn't just "randomly" set it to some large value.

That being said, it would cause some (how much?) performance degradation simply because it always has to check to make sure there is enough "current capacity" to support the moves; which is why I thought perhaps that feature could be left un-implemented.

How about something like:
OCCURS 0 TO nnn TIMES DEPENDING ON vvv-vvv [EXPLICIT / IMPLICIT].
For explicit, you must change vvv-vvv to expand the number of entries or you get a subscript range error.
For implicit, if the subscript exceeds vvv-vvv, vvv-vvv is implicitly updated and the number of entries is expanded.
Of course, since you don't know how many entries you will have, you have a list of 32 or 64 bit addresses, with each address pointing to that occurrence.

One other feature I can see that could be bypassed, at least initially, would be the behavior of the MOVE of a group containing a dynamic capacity table. Because a d.c. table would most likely not be "physically contiguous" with the rest of the items in the table, a MOVE of the entire group would at the very least be "less efficient". So how about a restriction that you can't do a group MOVE where the group contains one or more dynamic capacity tables? I don't see too many uses cases where this would cause an issue, and if we can get implementation of the most important features, that is better than nothing at all?

This RFE was declined based on concerns about performance. I would like to submit the following possibilities for consideration:

Would IBM be more amenible to a partial implementation? while you did not indicate in the declined RFE what performance issues you foresee, I can hazzard some guesses. One is the requirement in the standard is 8.5.1.6.3.2 Implicit changes in capacity: "When a data item in a dynamic-capacity table is referenced as a receiving item and the value of the subscript exceeds the current capacity of the table, a new element is automatically created and the capacity of the table is increased to the value given by the subscript. If this new capacity is more than one greater than the previous
capacity, new intermediate occurrences are implicitly created." I believe this would require a runtime check in each of these cases to see if the subscript is greater than the current capacity, and if so to increase the current capacity.

The current capacity can also be increased explicitly. 8.5.1.6.3.3 states "If the OCCURS clause specifies a CAPACITY phrase, the capacity of the dynamic-capacity table may be increased or decreased explicitly by means of the dynamic-capacity-table format SET statement." The "implicit changes" was one of the arguments I've seen against implementation of dynamic capacity tables, with the concern that one might have a bug that set a subscript to an incorrect and possibly very large value, which would cause the table to be increased to that value "improperly".

So why not eliminate that requirement as part of the implementation? I can't see any problem with a simple "SET tbl-capacity UP BY 1" when intentionally adding a new row to the table.