Array overflow on Internal table - Any Limit

scdinesh · Posted: Thu May 22, 2014 2:55 am

My COBOL program is failing because of array overflow on Internal table, currently it is declared as OCCURS 9999 TIMES , when am trying to increase the size to 99999 from 9999 still its failing with the same error, My question here is do there is any limit for array size declaration?

DECLARATION:

05 WS-TABLE OCCURS 9999 TIMES
INDEXED BY NDX.
10 WS-CUSTNO PIC 9(07) VALUE ZEROES.
10 WS-BRANCH PIC 9(03) VALUE ZEROES.

Please help me on this ...

Bill Woodger · Posted: Thu May 22, 2014 3:43 am

There is a Appendix containing all the Compiler Limits in the Enterprise COBOL Language Reference.

For a one-byte entry, you can have something over 132 million in the OCCURS, subject to sufficient space in WORKING-STORAGE. So, with your 10 bytes, you should be able to have an OCCURS of up to some 13 million.

Can you show the error message you are getting? It sounds more like a loop going out of its limits. Perhaps you can show the PROCEDURE DIVSION code which is causing the message to be produced?

Bill O'Boyle · Posted: Thu May 22, 2014 6:24 pm

Are you populating the ARRAY using VSAM data?

If this is true, then I may have an almost bullet proof method for this problem.

But Bill W's suggestion to post the error-message(s) is still needed.

Do you know your version of COBOL? This would be helpful also.

HTH....

scdinesh · Posted: Thu May 22, 2014 9:13 pm

Thanks for the reply.....

@Bill Woodger & Bill O'Boyle
Error message as:
CEE3204S The system detected a protection exception (System Completion Code=0C4)
Am sure this message is due to Array overflow ,as i've reduced the records in I/p file and resubmitted with the same OCCURS 9999 times which went fine.

Yes now i've identified the issue , it is due to less subscript declaration:
05 WS-SUB PIC 9(4) COMP VALUE 0.

changed to:
05 WS-SUB PIC 9(6) COMP VALUE 0.

its working fine, thanks a lot for your suggestion.

Regards,
Dinesh

Bill O'Boyle · Posted: Thu May 22, 2014 9:17 pm

You're limiting yourself with the redefinition of WS-SUB. Make it 9(08) or 9(09) COMP-5 (unsigned native-binary fullword) and you'll be good to go....

Bill O'Boyle · Posted: Thu May 22, 2014 9:51 pm

You never did say how this ARRAY was being populated. By VSAM records maybe?

Bill Woodger · Posted: Thu May 22, 2014 9:54 pm

You should find out what a S0C4 means. It doesn't mean quite what you think, but it can be caused by overflowing a table - usually by a considerable amount. Is your OCCURS in WORKING-STORAGE?

Are you using compiler option TRUNC(BIN)? Otherwise your original COMP field had a maximum value of 9999.

Are you using compiler option SSRANGE?

Since there is not enough information for an explanation of your original problem, I'd be wary of assuming that you have corrected the problem.

scdinesh · Posted: Thu May 22, 2014 10:44 pm

@Bill O'Boyle..
i've changed the subscript to 9(8) comp,
Array got populated from Flat file..

@ Bill Woodger
Am using default Compiler option NOSSRANGE , am not using TRUNC(BIN)

yep the problem got resolved after increasing the subscript size

Thanks All

Thanks,
Dinesh

Bill O'Boyle · Posted: Thu May 22, 2014 11:00 pm

My suggestion was to somehow pass to the program, the actual number of records in the flat-file. You could create a header-record with this information.

You could then define the ARRAY in LINKAGE, with a high OCCURS DEPENDING ON, with the DEPENDING ON defined as a binary fullword.

After reading the header and obtaining the number of records, use LE Callable Service routine "CEEGTST" and obtain only the amount of storage you need.

Then load your allocated ARRAY and you're done. I seriously doubt you'll ever get an overflow again if your DEPENDING ON is a high number.

When defined to LINKAGE, only the amount of storage you've requested will be used, whereas, in WS, all of the storage is used, regardless.

HTH....

scdinesh · Posted: Thu May 22, 2014 11:57 pm

Nice Idea ...Bill , i can do that which would obviously save lot memory...

Thanks again for your suggestion and quick reply

Thanks,
Dinesh

dbzTHEdinosauer · Posted: Fri May 23, 2014 4:29 pm

scdinesh

in COBOL, an array is a db2 host variable.

the array (the db2 host variable) is defined exactly like an COBOL internal table,
which it is.

array only has meaning in COBOL as a db2 host variable,
though the word array is used in other programming languages to mean a table.

also, had you used the indexed by clause,
and not used subscripts,
you would have never had the problem.

Bill O'Boyle · Posted: Fri May 23, 2014 5:28 pm

Scdinesh,

DBZ is correct.

Proper semantics is a necessity.

I used ARRAY because this is the way you presented it, although I should have corrected you from the onset.

Whereas, in your context, ARRAY should be referred to as a TABLE.

HTH....

Bill Woodger · Posted: Fri May 23, 2014 5:59 pm

With the COMP PIC 9(4) the maximum value which could be held was 9999 (no TRUNC(BIN)).

There was perhaps some condition "this field" > 9999, which could never be met, or simply no checking just loading another entry in the table.

When using the field as a subscript, once 9999 has been reached and one is added, the value goes to 0000. Zero is not a valid value for a subscript, and attempts to use it will access the "-1th" element of the table,

If there storage was acquired, that would (likely) cause a S0C4, Protection Exception. In WORKING-STORAGE, the table would have to be defined towards the "top", such that the reference to the -1th element would go below the start of the WORKING-STORAGE.

The table did not overflow, it could not, because that field as a subscript could not hold more than 9999.

Simply making the field bigger obviates the problem of 9999 going to zero when one is added, but there could still be any amount of shoddy code remaining to trip up another time (either in the program, or when copied).

There is a difference between just doing something which causes a problem to go away, and good code.

Of course do not have the information to confirm this, but it fits what is known.

"I got an array overflow so fixed the subscript size" doesn't cut it.

Bill O'Boyle · Posted: Fri May 23, 2014 6:26 pm

Bill,

This is why I suggested PIC 9(08) COMP-5 (which doesn't care about the TRUNC option) and then he's ready to go.

Now, as far as other errors, he's not really posted these so the best we can do is to suggest using a satisfactory subscript.

COMP-5 was introduced with OS390/COBOL 2.2 about 15 years ago.

haiardhan · New User Joined: 26 Jul 2008 Posts: 7 Location: india

i did not see , where you have differentiated subscript and index.
the question and example given with index and concluded by saying he has increased the subscript --

Rohit Umarjikar · Posted: Fri Jan 03, 2020 8:04 pm

Please don't tailgate old topics.

Robert Sample · Posted: Fri Jan 03, 2020 8:23 pm