Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Got the reason for SOC7 error, but not sure why data was so.

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging
View previous topic :: :: View next topic  
Author Message
Arunkumar Kowalpadoli

New User


Joined: 19 Jun 2011
Posts: 1
Location: US

PostPosted: Sun Jun 19, 2011 3:03 am    Post subject: Got the reason for SOC7 error, but not sure why data was so.
Reply with quote

Hi!

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?
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Jun 19, 2011 3:14 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Jun 19, 2011 3:18 am    Post subject:
Reply with quote

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



You don't think that AA1 might be your '12 extra spaces'?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8117
Location: East Dubuque, Illinois, USA

PostPosted: Sun Jun 19, 2011 3:50 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Jun 19, 2011 4:35 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Tue Jun 21, 2011 1:26 pm    Post subject:
Reply with quote

Quote:
Please note that this group variable is initialised before increment logic


please elaborate.

do you mean the VALUE clauses in the data element definitions
or
is this an INITIALIZE ...

and if the latter, why?
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts copying data without knowing location arunsoods DFSORT/ICETOOL 6 Thu Jul 20, 2017 1:03 pm
This topic is locked: you cannot edit posts or make replies. Fetching data from BAI File arunsoods JCL & VSAM 1 Wed Jul 19, 2017 4:28 pm
No new posts Loading data to table gives wrong for... Raghu navaikulam DB2 18 Thu Jul 13, 2017 2:11 pm
No new posts SQL - select data available in index Nileshkul DB2 3 Mon Jun 26, 2017 1:30 am
No new posts NDM syntax checking without actually ... GAPX1 All Other Mainframe Topics 0 Wed Jun 07, 2017 2:36 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us