One of our production jobs which had never abended in years, went down with SOC7 error.
02 DTL-TBL.
05 ABC OCCURS 15 TIMES.
07 AA1 PIC X(12) VALUE SPACES.
07 AA2 OCCURS 40 TIMES.
10 BB1 PIC X(10) VALUE SPACES.
10 BB2 PIC 9(08) VALUE ZEROES.
10 BB3 PIC 9(10)V99 VALUE ZEROES.
It abended because BB2 which is PIC 9(8) field was carrying spaces and it was tried to be incremented. Please note that this group variable is initialised before increment logic. And, it didnot abend in the 1st record. It abended in the 308th record out of 5000 records. This increment logic is performed in a loop.
However, from abendaid, by counting the bytes, I figured out that BB2 was actually not spaces, infact there were 12 extra spaces between BB1 and BB2. Due to this data shift, BB2 was taken to be spaces and it resulted in SOC7 error.
As a fix, we used IS NUMERIC check before incrementing.
Can anyone please let me know under what condition can such a data shift happen. Is it a case of overflow?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I don't understand your fix. You tested for numeric, is so added, if not, did what?
If you got a S0C7, no matter what you might think, the field being used at the time did not contain data which was sufficiently valid for a numeric operation.
If you have correctly checked that the particular occurence of BB2 (idiotic data-names by the way, probably not your fault) is indeed valid, then you have incorrectly identified BB2 (whichever one) as the problem.
If you can show the instruction that you think caused the abend and fancy copy/pasting what you think is the relevant part of the dump, and the address of the start of the table and the values of the subscripts/indexes then we might be able to see what you are talking about.
Until you can resolve the contradiction in your post above, you can leave other theories to one side.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
I figured out that BB2 was actually not spaces, infact there were 12 extra spaces between BB1 and BB2.
Since you have 600 occurrences of BB1 and BB2, don't you think you might need to provide a little more data -- like WHICH OCCURRENCES of the 600 you are talking about?
For your information, if the data structure is as you posted, there will be no extra bytes between BB1 and BB2 -- ever. If you look at the data map for the compile, you will discover that they occur consecutively in memory. So either you didn't post the true actual data structure, or your conclusion is totally wrong, or there is more going on than you are telling us.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Arun,
1) You did not get the reason for the S0C7. If the phrase is to make any sense, it means you know why invalid data has appeared, and you have a fix for it which your boss will be happy with. A field having spaces in it doesn't count as a reason for a S0C7. A "Data Exception", the other name for a S0C7, means "invalid data in a packed decimal field" (my description, you can go and look up the real wording). In that sense, shortly after the phone call started you could "get the reason". "Oh, yes, that's invalid numeric data". (Robert, don't laugh, I've heard people say that very wisely).
2) The items in your table all have value clauses. Irrespective of whether you initialise the table in some way, the data as defined (according to your post) is starting off with correct values, and can only become invalid through something the program is explicitly (or implicitly via a called program) doing.
3) When you get an abend, it is rarely going to be with the first record. An abend occurs because the particular combination of data has never been through the program before. In your case, it occured on the 308th record. You have 5000 records. It had a 1/5000 chance of being any particular record, so the information in itself is useless to solving the problem.
4) You have a table with two-levels of occurs. As Robert has pointed out, you have 600 BB2s. It is entirely unsurprising, and again useless in itself, to learn that this is incremented in a loop.
5) Then we get into the stuff which is just plain hooey.
Look at your subscripts. The first should have a value between 1 and 15, the second a value between 1 and 40.
If they are OK, then something has splatted your table. If they are not OK, find out how they can be not OK and that is likely the answer.
If something has splatted your table, look at the values of all subscripts/indexes in the dump until you find one which is out of its range. Start with any belonging to storage immediately before/after your table and work through them all. If none, check for MOVE with reference modifcation. If none, check for any called programs. If none, then, you have a dump which is beyond the basic.
