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?

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 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.

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.