When I first saw the (non-standard!) enhancement to Enterprise COBOL 5.2  for "unbounded" tables I thought, hey, that's great!  But as I think more about it I wonder what the real advantage of it is.  For one thing, is it really technically "unbounded"?  Aren't you still limited to the maximum value of occurrences that can be held by the "DEPENDING ON" object?  Specifically, how are the following two declarations different?

LINKAGE SECTION.01  HALFWORD-LEN         PIC 9(4) COMP.01  BOUNDED-TABLE.    05  X1 PIC X OCCURS 1 TO 9999 DEPENDING ON HALFWORD-LEN.01  UNBOUNDED-TABLE.    05  X2 PIC X OCCURS 1 TO UNBOUNDED DEPENDING ON HALFWORD-LEN.

The only advantage I can think of is with UNBOUNDED you could change HALFWORD-LEN to a COMP-5 and now have a maximum occurrence number of 65535, without the need to change the X2 declaration.

Am I just totally missing something?

Additionally, another thing that UNBOUNDED does not provide is true "dynamic tables", where you could build up a table on an "per occurrence" basis.  You still have to allocate enough storage to hold the "unbounded table", so you must know prior to this allocation the number of occurrences there will be.  And you don't always know this ahead of time, unless you process the data twice; once to get the number of occurrences, then again (after allocating data for the table) to actually add the data to the table.

Frank

Maybe you even have TRUNC(BIN) already :-)

As you have pointed out previously, I didn't really understand the UNBOUNDED in relation to storage allocation. Somewhere I misunderstood a reply of Tom Ross's, but can't find the discussion (most likely on LinkedIn where searching for things seems largely futile unless you know where it is already).

So, yes, there is a bound to the unbound table, which is the data-item used. But, you can change the value at run-time, and as long as you've allocated extra storage, your table is not bounded by what existed at compile-time.

My question to Tom was something like "so this is a formalisation of the technique to acquire storage for a table in the LINKAGE SECTION", and the reply was in the affirmative, so I assumed the memory-management was "done for you".

You bringing up "per occurrence" also sheds light on the inaccuracy of my question, I missed out something like "in a reasonable way".

Acquiring storage is not so bad in itself, performance-wise, as you tend to do it only once for a particular thing. Unless... you want to add "per occurrence" storage to a dynamic table. If there is contiguous storage available (and you ask for contiguous storage) there is the overhead of the request, now happening much more often than once. If there is not contiguous storage available (or you don't ask for it) - then the whole table gets copied to a new storage location, so that you can add one more entry. That latter is bad-to-catastrophic, depending on the size of the table.

Extending a table by "lumps" is not so bad, but you have to manage the lumps (which is code, in COBOL, so we're used to that).

It's never been clear to me why SSRANGE can't be applied to the table either. The table does have a current bound, which is reliable, unless someone is doing the less-than-brilliant thing of using the UDO-item for another thing as well, in which case tough on them if they are caught.

So, yes, I'm unsure how it is best used, which is odd when it seems to be a major part of the "advertising"...

Bill, I think you've hit on one "advantage".  The reason I didn't think of it is I had not understood how SSRANGE worked in conjunction with variable-length tables.  It looks like the current occurrence is checked against the "maximum bounds" field, but never against the actual OCCURS DEPENDING ON object.  For example, the the following "table" definition:

05  X  PIC X OCCURS 1 TO 10 DEPENDING ON X-CNT INDEXED BY XIDX.

If you do a MOVE X(11) TO ... you will get an "IGZ0006S" condition, where "IGZ0006S The reference to table table-name by verb number verb-number on line line-number addressed an area outside the region of the table."  It does not matter that field X-CNT may have a value of more than 10.  While surprising to me, this agrees with the full description of IGZ0006S which says:

IGZ0006S The reference to table table-name by verb number verb-number on line
         line-number addressed an area outside the region of the table.       
                                                                              
Explanation: When the SSRANGE option is in effect, this message is issued to  
indicate that a fixed-length table has been subscripted in a way that exceeds
the defined size of the table, or, for variable-length tables, the maximum    
size of the table.                                                            
                                                                              
The range check was performed on the composite of the subscripts and resulted
in an address outside the region of the table. For variable-length tables, the
address is outside the region of the table defined when all OCCURS DEPENDING  
ON objects are at their maximum values; the ODO object's current value is not
considered. The check was not performed on individual subscripts.             
                                                                              
Programmer response: Ensure that the value of literal subscripts and/or the   
value of variable subscripts as evaluated at run-time do not exceed the       
subscripted dimensions for subscripted data in the failing statement.        

It also agrees with the Customization Guide where SSRANGE is described thusly:

"Generates code that checks subscripts, reference modifications, variable-length group ranges, and indexes at run time to ensure that they do not refer to storage outside the area assigned. It also verifies that a table with ALL subscripting, specified as a function argument, contains at least one occurrence in the table.

The generated code also checks that variable-length items do not exceed their defined maximum length as a result of incorrect setting of the OCCURS DEPENDING ON object. For unbounded groups or their subordinate items, checking is done only for reference modification expressions. Subscripted or indexed references to tables subordinate to an unbounded group are not checked."

In other words, the "maximum size" of the table defined above is 10, even though X-CNT could be, well, pretty much anything.

Conversely, if (for example) the above had been defined such that the value of 100 was the "maximum size", but X-CNT was set to a value of let's say 50, COBOL SSRANGE would let you freely refer to elements 51 -100. 

As I said, this was a surprise to me because I assumed that SSRANGE would check the "ODO object" and perhaps not even care about the "maximum size".  After all, for a LINKAGE SECTION item anyway the program doesn't really own the data anyway, so it seems to me it might be reasonable for SSRANGE to check the ODO object and not even really care about the "declared maximum".

But since it does work the way it works, and I have no intention of requesting it work differently, I guess that UNBOUNDED has the advantage that even if SSRANGE is turned on no range checking is done for unbounded data items.

Still, if there are any other differences anyone knows of (IBM COBOL development?) I'd be curious to learn about them.

Frank

Here is a bit of "trivia..":  The original motivation for adding this was to provide more natural support for XML schemas with something like:

<xsd::element name="myTable" maxOccurs="unbounded">

   <xsd::more_refinement ....>

   </xsd more_refinement>

</xsd:element>

By "bit of trivia" I mean "that's my story and I'm sticking to it :-)"

I understand that, but how is this:

01  HALFWORD-LEN         PIC 9(9) COMP.
01  UNBOUNDED-TABLE.
    05  X2 PIC X OCCURS 1 TO UNBOUNDED DEPENDING ON FULLWORD-LEN.
 

Any better than this?:
01  HALFWORD-LEN         PIC 9(9) COMP.
01  BOUNDED-TABLE.
    05  X1 PIC X OCCURS 1 TO 999999999 DEPENDING ON FULLWORD-LEN.

I'm not saying there's anything wrong with UNBOUNDED; I just don't see it as resolving all of the issues that there are with "unbounded XML".

Even an unbounded table is limited to 999,999,999 in Enterprise COBOL, so...
 

If you like (or need) COMP-5, it can be bigger :-)

You may want to edit those names in the definition of the binary fields.

If only that were true!

"The total size of an unbounded group at run time must be less than 999,999,999 bytes."

From http://www.ibm.com/support/knowledgecenter/SS6SG3_5.2.0/com.ibm.cobol52.ent.doc/PGandLR/ref/rlddevar.html

And trust me, I tried it.  The compiler even generates code so that of the subject (object?) of the "DEPENDING ON" is PIC S9(9) COMP-5 it will truncate the value it if its greater than 999,999,999 before it uses it!  :-(

Thanks. Interesting. I didn't expect a decimal limit. However, if it may reduce irrelevant use of COMP-5 :-)

That could confuse the unwary. And those who haven't read that bit of the manual. Yet.

I assume a half-word COMP-5 still gets full value?

I've just read the "less than". Does that mean the final allowed value is still not valid?

I was shocked as well.  And my thought is that its an artificial limit that could be extended to the maximum value that can be held in the "depending on" field.  Up to 2,147,483,647 bytes, anyway; since CEEGTST won't let you allocate more than that in one chunk there's perhaps no point in going further than that.  Well, sans 64 bit support, anyway!

I believe a half-word COMP-5 behaves as one would expect. 

I understand the concern that there is an over-arching limit notwithstanding the UNBOUNDED declaration.  And I admit that what follows is simply one person's opinion.  But I do think that it is better to express what the real intention is.  "OCCURS 1 TO 999999999" is an idiomatic use of the constant 999999999 which might be just fine.  "OCCURS 1 TO UNBOUNDED" really expresses in an explicit and more natural way the nature of this data item.  In my opinion, that's worth something.

Other than the implied limit with UNBOUNDED, are there other issues you've found with "unbounded XML?" 

It seems to me that UNBOUNDED tables are generally only of use in regard to XML documents that are created elsewhere and simply consumed by COBOL.  But try getting COBOL to generate an "unbounded" XML document.

To be honest, I have done it by using CEEGTST and CEECZST, and then COBOL's XML GENERATE.  But can your average COBOL programmer be expected to use that?  And even then you still have to guess the maximum size of the XML document as well, which is significantly greater than the COBOL structure it is generated from.

I know COBOL 6 has the new ALLOCATE statement, and that is a decent start.  But there's nothing corresponding to CEECZST (because the COBOL standard neglected to include it ), so it seems to me use of ALLOCATE alone, while technically possible with a lot of allocating, copying, and freeing, still does not resolve this issue.

Really, I agree that the UNBOUNDED keyword is nice, as you say, because it expresses that the table is bounded only by the size of the DEPENDING ON field.  However, I wonder (too late now) if it might have made more sense to just allow "OCCURS DEPENDING ON data-item", (no UNBOUNDED or explicit number of "TIMES"), rather than the possibly deceptive word "unbounded".

In the end, the true solution is seems to me is the COBOL 2014 feature "dynamic capacity tables".  I have requested this already and been shot down.  Double-

And for what its worth, it seems to be that "OCCURS UNBOUNDED" should mean "OCCURS 0 TO UNBOUNDED TIMES" rather than "OCCURS 1 TO UNBOUNDED TIMES".  But I don't know what "real difference" the zero or 1 there makes.

Another big advantage of UNBOUNDED is that if in a future compiler update, the limit table size is increased past 999,999,999, you can take advantage of this with a recompile. If you've hard-coded the 999,999,999, you'll have to change your code.

True enough.

I again want to stress I am not against UNBOUNDED in any way.  I just want to be clear on what it means (and what it doesn't mean!) and what true advantages there are to using it.

Thanks for everyone's comments!

I was remembering this, from internetland:

I was told (by Tom Ross) that UNBOUNDED has a max based upon the picture clause and definition, which in this case is a signed binary-fword.

That, of course, assumes a standard COBOL COMP data item, rather than the COMP-5 IBM extension.

Maybe another reason for E.COBOL to support COBOL 2002's true binary data types?

As for the "less than" I'm guessing it must be a documentation error.  I don't feel like verifying it for one byte.