I think that is the correct way to do it, Frank. The chunk-size of "20" is obviously determined by whatever best fits the data use. I'd go for the old "table size you expect, and then a bit" but doing the "and then a bit" by extending it.
For batch it doesn't matter, but for other usage you do need to be aware that the address of the start of the table may change. If "something else" has the old address (when there is an old address) then something is going to behave less than optimally. The difference in your example to what you mentioned earlier is that the storage is entirely contiguous, and, since it is "defined" in the LINKAGE SECTION (a mapping of storage, with storage acquired for it) then nothing else gets upset. If you remember from a while ago I thought the UNBOUNDED *was* IBM's implementation of dynamic tables. Here's another example of what I presume your code is doing, generally (although you have the better idea with the chunks) http://enterprisesystemsmedia.com/article/leveraging-cobol-language-environment-services#sr=g&m=o&cp=or&ct=-tmc&st=(opu%20qspwjefe)&ts=1470260061 The actual dynamic tables (or the possibilities) described in the current Standard I regard as a nightmare. Even let's assume that all the dynamic table storage is consecutive. Well, you can get nested, and you can mix them with fixed or ODO tables under the same group item. Yes, you could implicitly untangle that, but at what cost? What about REDEFINES? Yes, you can ban it, like for an ODO, but for an ODO you can still achieve REDEFINES. Try to do that with the proposed junk, and there's a mess. IBM has just rewritten the compiler, including work on WORKING-STORAGE and LOCAL-STORAGE. Anything with a dynamic capacity table would have to have its own storage allocated, separate from the WORKING-STORAGE/LOCAL-STORAGE allocation (so you end up with multiples of each). Let's not get into how programmers may (ab)use it. Nor sites which "ban" its use. So, since UNBOUNDED does what you want in this example, you need a very strong case to get dynamic tables addressed, and I don't think such a case exists, given the inherent drawbacks. If it doesn't fit into IBM's plans, which they stated it doesn't when rejecting the RFE first time, then you're going to get it rejected again. I don't doubt that it would be great fun to play with, outside the Mainframe, and really welcome anything you can produce for GnuCOBOL, but I'm not sure you're going to get anywhere with Enterprise COBOL. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
