In an existing production program the working storage table is defined as
05 UNIT-AMENDMENTS OCCURS 12 TIMES.
10 NUM-OF-UNITS PIC S9(04) COMP-3.
10 UNIT-VALUES OCCURS 7 TIMES
INDEXED BY UNIT-INDX.
15 UNIT-ID PIC X(01).
15 UNIT-MEM-VALUES OCCURS 500 TIMES INDEXED BY
25 UNIT-MEM-AGRE-PA PIC X(02).
25 UNIT-MEM-AGRE-MGR-CODE PIC X(02).
25 UNIT-MEM-AGRE-PROD-ID PIC X(05).
25 UNIT-MEM-UNIT-ID PIC X.
The program reads a file sequentially and populates
UNIT-MEM-VALUES depending upon the number of records for a perticular key.
While population we are not giving any upper limit as
PERFORM UNTIL UNIT-CNTR > 500.
The program currently populates 558 UNIT-MEM-VALUES although the OCCURS
defined in the table are 500.
And while writing an output record it is correctly picking up the values
for the occurences above 500.
Can anybody please explain whether it is possible to have 501th occurence
in a table populated eventhough the OCCURS defined are 500.
Note: I checked using SSRANGE as a compiler option but it is not able to
trap the table overflow condition."
I m not sure why SSRANGE compile option didn't trap the error..it shud issue the error code..
Secondly...With out SSRANGE option ...Although we specify a limt for occurs class..say 500 in your case.... referring 501th memory area will use the memory area by calculating the respective displacement..
05 chk-occurs pic x(02) occurs 500 times.
by refering/using chk-occurs(501) will refer to the relative memory location of SM + 1002 byte..where SM is the starting memory address for this variable....but if the same memory location is used by some other variable the contents would be modified and it will lead to mess....
ie if SM+1002 byte is allocated to another Working storage variable it content would be altered
SSRANGE generates a code that checks if subscripts or indexes try to reference an area outside the region of the table. Each subscript or index is not individually checked .The effective address is checked to make sure that it does not cause a reference outside the region of the table.
If SSRANGE is in effect at compile time, the range-checking code is
generated. We can inhibit range checking by specifying CHECK(OFF) as a run-time option. This leaves range-checking code dormant in the object code. The range-checking code can then be optionally used to aid in resolving any unexpected errors without recompilation.
It seems the CHECK(OFF) is set as a run-time option in your installtion.It should be CHECK(ON).Also when overflow occurs sometimes it wil clash with other variables memory location leading to unpredeictable behaviours. Recently i had such a problem, where the program became crazy and started looping.