View previous topic :: View next topic
|
Author |
Message |
scdinesh
New User
Joined: 06 Sep 2006 Posts: 44 Location: United States
|
|
|
|
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 ... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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.... |
|
Back to top |
|
|
scdinesh
New User
Joined: 06 Sep 2006 Posts: 44 Location: United States
|
|
|
|
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 |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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.... |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
You never did say how this ARRAY was being populated. By VSAM records maybe? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
scdinesh
New User
Joined: 06 Sep 2006 Posts: 44 Location: United States
|
|
|
|
@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 |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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.... |
|
Back to top |
|
|
scdinesh
New User
Joined: 06 Sep 2006 Posts: 44 Location: United States
|
|
|
|
Nice Idea ...Bill , i can do that which would obviously save lot memory...
Thanks again for your suggestion and quick reply
Thanks,
Dinesh |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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.... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
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. |
|
Back to top |
|
|
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 -- |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3051 Location: NYC,USA
|
|
|
|
Please don't tailgate old topics. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
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 |
The original post did not mention subscript at all; the perceived problem was with the number of occurrences of the indexed table. The actual problem uncovered was a faulty declaration of a variable used as a subscript and this was clearly brought out in the posts. So where do you think index and subscript need to be differentiated?
And, as Rohit points out, the topic is 5 1/2 years old so there's not much you can add to the discussion at this point. |
|
Back to top |
|
|
|