Last year I submitted an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=73693) that Enterprise COBOL be enhanced to support dynamic capacity tables as defined in the COBOL 2014 ISO standard. It was declined: "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."
Since the year has passed I have resubmitted the RFE, now with the following comments that I hope might address IBM's concerns: "This RFE was declined based on concerns about performance. I would like to submit the following possibilities for consideration: Would IBM be more amenable 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. 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?" I still believe this would be one of the most useful enhancements that COBOL could have. Please vote if you agree. (There is also a similar SHARE requirement.) My resubmitted RFE: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92391 Share Requirement: http://www.share.org/index.php?mo=is&op=vi&iid=67&type=23 Frank Swarbrick Principal Analyst, Mainframe Applications FirstBank -- Lakewood, CO USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
