IBM Mainframe Forum

Thanks Billy and others for responding to my query.
My sincere apologies for not having replied.

First of all I would like to admit that I am part of the QA team (Testing) and limited to finding line of code causing the issue.

But I had raised this to feed my curiosity.

The issue was resolved by changing the level number

from
01 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000

to

05 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000

inside the copybook.

Before the change

01 TRS-FINANCIAL-TRANS-STATUS.
05 TRS-MNEMONIC PIC X(08).
05 TRS-FIN-TRANS-STTS-TBL OCCURS 10000 TIMES
INDEXED BY TRS-INDX.

01 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000


We were initializing 01 TRS-FINANCIAL-TRANS-STATUS.
The other 01 level was untouched.
But this change did not work (the job abended).

The reason for this is we got a non-numeric value in TRS-TRANS-MAX-COUNT.

Just to let you know, we have intermediary architecture programs which would handle passing data between programs.

This architecture allows us to register 01 levels for a datablock.

And we have restrictions to register only one 01 level per copybook.

After the change

01 TRS-FINANCIAL-TRANS-STATUS.
05 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000

05 TRS-FINANCIAL-TRANS-STATUS-DTL.
10 TRS-MNEMONIC PIC X(08).
10 TRS-FIN-TRANS-STTS-TBL OCCURS 10000 TIMES
INDEXED BY TRS-INDX.

The initialize problem is now resolved as we can initialize 05 TRS-FINANCIAL-TRANS-STATUS-DTL separately.

Thanks again,
Regards,
David

Well, I'm glad it is working. I can't see from what you have posted why it is working, which always makes me feel a little twitchy.

You talk of "intitialise", but you have a VALUE clause, so why would you initialise it (again). If it has a value clause and in traditional use for such a thing nothing else would amend it, how did you get a non-numeric value in it? The thing about the solution not being an "obvious" solution is that it might just have moved the error to somewhere else, less obvious as an error.

Was/is this table in the Linkage Section?

The other comments we made might not, coding-wise, be your problem, by might be with your QA hat on (performance). The perform with equal and TEST AFTER is wrong, anyway, in that when there are no items in the table, it will go through the perform once. OK, so maybe there will never be no items, but the code is still not good practice (never say never, because you'll be proved wrong).

If you're happy with the solution, OK. I'm not, but that doesn't matter to anyone but me

I stand my position.... specially after seeing the original code: OUT OF BOUNDS!

Hello,

I believe the problem has not yet been corrected. . . The abend has been avoided for this testing, but i suspect the problem (addressing beyond the array - as Zio mentioned) is still happening if the code was not changed/corrected. . .

Depending on what follows the array, the results may be unpredictable