IBM Mainframe Forum

Oh ok BillyBoyo, i dint know that. One more question. What will be Displayed if index variable is Displayed directly?
Usaully if we want to display a index variable we wil set display-varibale to index-varibale and then we will display the display varibale.

My understanding is, the TABLE-MAX is the number of items u have defined i.e., the table can hold 300000 ELEMENTS.
If my understandins is correct

Your understanding is wrong. There is nothing in COBOL to enforce a limit on the number of elements of a table (although compile option SSRANGE will do so). TABLE-MAX is a COBOL variable -- nothing more, nothing less -- and how that variable is used depends upon the program. And note that the original post had OCCURS 200000 even though TABLE-MAX is defined as 300000 -- so obviously there is no relationship between the number of elements in the table and the variable TABLE-MAX.

What will be Displayed if index variable is Displayed directly?

A compiler error message will show up, so nothing will be displayed.

Gokul, the thing to do is to try it out. Then check in the manual. Or check in the manual first, and see if you want to try it out.

The manual will tell you exactly how indexes are treated in all situations. The same of USAGE INDEX items.

If I'm doing a looping construct with an index, I like to do this sort of thing.



Assume also that the table itself has a-nicely-named-index.

At the "top" or the program or "first time",


The I use table-max-good-name-as-index for the maximum test. Save the compiler some conversions. Maybe doesn't matter these days, but it's what I like to do.

I also like to check that the table-maximum-but-with-a-meaningful-name has the correct value.



How would you put in code, to check at run time, that the value of nicely-named-table-max is the same as the number of occurs. The idea is, if someone comes along and changes one without the other, how do you trap it automatically?

Hint: Look at the special-register LENGTH OF or the FUNCTION LENGTH,

Hi Robert,
I think a cobol table cant hold more than what its declared in the occurs times of values. Correct me if i am wrong.
Let me correct my post as :
My understanding is, the TABLE-MAX is the number of items you supposed want the table to hold but as per definition it cant hold more than 200000 element values.

As i read the post my doubt was " How can the index which is supposed to store the disposition can be compared with the counter variable." But it was later clarified by Billyboyo that the compiler will automatically convert the index disposition to the count(like the value similar to the subscript).

For more clarification i posted asking the display thing for which you have replied it ll through a compiler error.

As Billiboyo suggested i wish to try n check it, but unfortunately i am right now not in any project and i dont have MF access .

Even with no access, you do still have the manuals. There are some free Cobol compilers out there. They aren't Enterprise Cobol, but you can try some things out with them and then check later when you do have access.

I think a cobol table cant hold more than what its declared in the occurs times of values. Correct me if i am wrong.

If you place more elements in a table than it is allocated via the OCCURS clause, you start writing over memory outside the table limits. While this is not illegal in COBOL, write over enough memory, and you are GUARANTEED to get an abend -- a S0C4 if you start writing over memory that doesn't belong to your program, or any of a number of other system abends if your overwritten memory happens to include the load module instructions. It is an extremely bad -- and dangerous -- practice to ever let such a memory overlay occur. Using SSRANGE compile option enforces the table size limit for table references -- but it takes additional processing time when the program is executing.

Other COBOL compilers may differ, but with Enterprise COBOL for mainframes, the OCCURS sets the boundary. You may declare other variables as you see fit, but the only thing that sets the table size is the OCCURS clause. And I am not aware of any COBOL that allows you to set the run-time size of a table; COBOL is a compiled language and the limits of a table are set at compile time, not at run time (although there are some cases when OCCURS DEPENDING ON can allow for a run-time change).

Enterprise COBOL allows indexes and subscripts to be used almost interchangeably and will convert the table offset value of an index into a subscript number and vice versa as required. However, if you attempt to use DISPLAY TABLE-NDX where TABLE-NDX is defined by an INDEXED BY clause, the compiler will generate an E-level error and not generate a load module as a result.

Dynamic tables, tables that can expand or shrink at run-time, is defined in the COBOL 2002 standard, but is not yet implemented in z/OS. A nice feature to look forward to and will eliminate the problem discussed in this thread.
The Occurs maxvar Depending On numvar clause is a way to tell COBOL the maximum number of elements and how many elements of the table you really are using: when you load the table you vill have to increment the value of numvar for every element you create. Assuming this value is smaller than the value maxvar, COBOL can exlude unused elements when you use the SEARCH-verb, either sequential search or binary search, to find what you are looking for.

We don't know yet what the problem is, so I'm not sure we know how to "eliminate" it. TS/OP says only 40,000 entries in table, so doesn't know how it says 300,000 is bust. So many errors, I can't being to guess.

I haven't looked, but would the table get bigger as you add entries to it, or can you just give it a fixed size at run time, or is it fixed-but-can-be-specifically-changed-if-necessary. Depending on what it is, might not even deal directly with the "normal" overflow-of-table problems.

Hello,

Dynamic tables, tables that can expand or shrink at run-time, is defined in the COBOL 2002 standard, but is not yet implemented in z/OS. A nice feature to look forward to and will eliminate the problem discussed in this thread.

Please post the info from (or the direct link to) the IBM documentation where this was found.

My guess is that the problem in this topic is problem code or a misunderstanding of what is/should be happening.

Dick,
I checked the finalized document for the 2002 standard and just found that the proposal was dropped, meaning its not part of the 2002 standard (sorry!).
I found that it was/is a proposal to the 2008 standard, which I havent seen any trace of so far. I´m checking further on this.
The initial refrence to Dynamic Tables was found in the book Advanced COBOL for structured and Object-Oriented Programming (third edition) by Gary DeWard Brown.