IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

S0C7 ABEND when no arithmatic statment


IBM Mainframe Forums -> ABENDS & Debugging
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Sun Dec 07, 2008 12:30 am
Reply with quote

Hi,

I checked the search foe any information related to the S0C7 abend I have got, but didn't find anything that helped me. I am trying to find the location in the program which is throwing the error. I tried using the OFFSET address in the Complier listing but that took me to a Paragraph which had just a few MOVES and a EVALUATE statements. There were no arithmatic statments in the paragraph of I got stuck again - Thats when I saw the following message in the CAIPRINT of the Job SPOOL.

Code:

ABENDING INSTRUCTION                                                       
                                                                           
   FA55 2020 40CF    ADD                                                   
                                                                           
OPERAND:                                 BLL 002 DISP 000630               
  VALUE: F5F6F7F1F0F1                    <-- NOT NUMERIC                   
                                                                           
                                                                           
                                                                           
OPERAND:                                 BLW 000 DISP 0000CF               
  VALUE: 00000003045D                                                       
                                                                           
                                                                           
INTERRUPT OCCURRED AT ADDRESS A409DE4A AT OFFSET +01013A IN PROGRAM P6851M5A

Can someone tell me whats the meaning of 'FA55 2020 40CF' . The above message seems to indicate that S0C7 is occuring due to ADD. Should I go by this message ?

Please help...
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Sun Dec 07, 2008 12:52 am
Reply with quote

Believe the computer until you've got solid, 100% proof it's lying to you. If your compile does not not have the LIST option, recompile with LIST to get the generated Assembler instructions. Based on what you've displayed, it appears you've got a USAGE DISPLAY value of 567101 being added to a packed decimal value of -3045. One or the other of these values must be converted to the other form before the addition is done; your problem could be the EVALUATE statement, depending on what it says. From the display, the computer is expecting the 567101 to be converted to a packed decimal value and your code may need to be changed to force this to happen.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sun Dec 07, 2008 2:06 am
Reply with quote

Here's the breakdown of X'FA55 2020 40CF' -

X'FA' ===> OPCODE 'AP' (Add Decimal/Add Packed Instruction)
X'5' ===> Length of Operand-01
X'5' ===> Length of Operand-02
X'2' ===> Receiving Register (R2) - Operand-01
X'020' ===> Offset off R2 where the data can be found
X'4' ===> Sending Register (R4) - Operand-02
X'0CF' ===> Offset off R4 where the data can be found

So, at X'020' off R2, you'll find X'F5F6F7F1F0F1', which is an invalid format for packed-decimal (COMP-3). At X'0CF' off R4, you'll find X'00000003045D', which is a valid packed-decimal value of negative 3045.

Note that the Operand-Length(s) value is always 1 less than the actual data-length and the 'AP' instruction-format, as well as instructions SP, MP, DP, ZAP and others, is known as Storage-to-Storage (SS). There are three (3) different formats for SS.

When the 'AP' instruction is attempted, the instruction's microcode trys to add a 6-Byte packed-decimal value of negative 3045 to a 6-Byte display-numeric value of 567101, which causes a data-exception (S0C7) to be raised.

Apparently, you have display-numeric data in a field that's defined as packed-decimal/COMP-3.

Regards,

Bill
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Sun Dec 07, 2008 2:17 am
Reply with quote

Hi Robert,

So, Your saying that ADD is the operation in the program thats giving me the problem? Because earlier when I used the OFFSET complier option and looked in the COMPLIER LISTING and went by the OFFSET address, I reached a paragraph which has MOVE statements, an EVALUATE and there was call to a SUBPROGRAM. But SOC7 message that is thrown is from the CALLING PROGRAM. SOC7 if thrown will never be from the CALLED program right ? I mean, SOC7 if it occurs in say PROGRAM-B will be displayed as occuring in PROGRAM-B .. Can the Message show that its from the CAlled Program when actually its from the Calling program or vice-versa... hope I didn't confuse you icon_redface.gif
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sun Dec 07, 2008 2:28 am
Reply with quote

Hello,

Quote:
Can the Message show that its from the CAlled Program when actually its from the Calling program or vice-versa... hope I didn't confuse you
I believe you're confusing yourself. . .

The system will not make things up or show one thing when it means another.

The bit of info you posted shows exactly where the abend occurred.

You need to go to that address in the named abended code and fix the code or the data so the 0c7 does not occur. The value shown will cause an 0c7 every time it is used in an instruction requiring a packed-decimal value.
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Sun Dec 07, 2008 3:07 am
Reply with quote

Thank you so much... Robert.. Bill...Dick,
Thats some good information for me to work on..
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sun Dec 07, 2008 5:00 am
Reply with quote

You're welcome icon_smile.gif

I just noticed this from your initial post:
Quote:
There were no arithmatic statments in the paragraph of I got stuck again
The program does not need to have a "real" arithmetic instruction in the code for the underlying generated assembler code to contain arithmetic instructions (like the Add Packed (AP) in your case.

Where i suggest you concentrate is the data item containing a "display" value where the system is expecting a packed-decimal (comp-3) value. Make sure the field definiton is correct and that the data read/moved into the area conforms to the definiton.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Sun Dec 07, 2008 8:44 am
Reply with quote

Post the code for the paragraph in question; maybe it'll throw some light on the issues.

Also, the LIST option produces more output than the OFFSET option, but the LIST output can be more beneficial when debugging as the compiler translated assembler statements are displayed, allowing you to see exactly where the program abended and get some idea what the code was doing around the abend.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Sun Dec 07, 2008 6:40 pm
Reply with quote

Hi JayC,

When adding the LIST option be sure to remove the OFFSET option. You can code LIST,NOOFF to o'ride OFFSET if you can't remove it.
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Sun Dec 07, 2008 8:28 pm
Reply with quote

Ok thanks Robert..Jack...
Abend still not solved yet--- Still working on it. . .
The bigges hurdle is that this BATCHDB2 program where the S0C7 has occured, so I can't test run it and all.... The TEST DB isn't in SYNC with teh PRODUCTION DB. . . icon_sad.gif
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Mon Dec 08, 2008 10:11 am
Reply with quote

Hi JayC,

You don't have to re-test, just recompile using the LIST option as Robert suggested. Then find "OFFSET +01013A IN PROGRAM P6851M5A" (do an ISPF "find MVC" to bring you to the LIST that shows the AL expansion of each COBOL stmt).

When you find OFFSET 01013A scroll UP to the 1st COBOL verb you see, and use the stmt# at the left to find the offending COBOL stmt. If it's a simple move you should be home free. If it's a multi-MOVE stmt, etc. Bill O'Boyle's post will help.

Let's hope you don't have any static calls to deal with.
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Mon Dec 08, 2008 6:43 pm
Reply with quote

I recomplied the program with the require complier options and came to an ADD statement--but I validated the concerned data fields and concluded that the DATA is fine... The S0C7 is happening because of soemthing else...I am breaking my head over this but I just can't figure out what.
I restarted the job bapassing the record that was under processing while the S0C7 happened. This time my job ran fine for another 50 min and abended again with S0C7. This time there is a different OFFSET address shown and the CAIPRINT is as follows :
Code:

ABENDING INSTRUCTION                                                       
                                                                           
   FA55 2008 40C9    ADD                                                   
                                                                           
OPERAND:                                 BLL 002 DISP 000AA4               
  VALUE: 0003D522860D                    <-- NOT NUMERIC                   
                                                                           
                                                                           
                                                                           
OPERAND:                                 BLW 000 DISP 0000C9               
  VALUE: 00000001700D                                                       
                                                                           
                                                                           
INTERRUPT OCCURRED AT ADDRESS A409DE3E AT OFFSET +01012E IN PROGRAM P6851M5A
                                                                           
ENTRY POINT ADDRESS IS 2408DD10 AT OFFSET +000000 IN PROGRAM P6851M5A       


Somethings gotta give..... icon_sad.gif
icon_sad.gif icon_sad.gif
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Mon Dec 08, 2008 9:16 pm
Reply with quote

I don't know Assembler, but from what Bill explained, both operands in an AP instruction (X'FA") must be packed decimal usage -- COMP-3 in COBOL terminology. X'0003D522860D' is not a valid packed decimal number. It is 6 bytes but the 1st D you see is not a number. All digits except the last one, which is the sign, must be numbers between 0 and 9. You might have overlapping storage where the 1st 2 1/2 bytes (or 1st 3 bytes) of a 6-byte COMP-3 field was overlaid by another field.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Dec 08, 2008 9:42 pm
Reply with quote

Post the LIST output from P6851M5A that includes the 1012E offset so we can provide additional suggestions.

The computer is very accurate -- in both cases, you had non-numeric data in an ADD PACKED instruction, so the S0C7 is normal and expected for the given data. The question becomes, why are you getting invalid data in the field(s)? The abend could be at the same program instruction since the offsets could have changed slightly due to system maintenance between compiles.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Dec 08, 2008 9:55 pm
Reply with quote

Hello,

Quote:
The S0C7 is happening because of soemthing else
The 0c7 can only happen due to invalid data. The data shown is invalid in both sets of abend info posted.

It may be the code is corrupting something that was once valid.

Until the data is corrected or the code modified to detect bad data (or not corrupt good data), the abends will continue.

It now appears that there are multiple problems in the code/data.

How long has this successfully run in production before these abends started happening?
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Mon Dec 08, 2008 11:52 pm
Reply with quote

Dick this program has been running fine for the last 15years in production.
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Tue Dec 09, 2008 12:01 am
Reply with quote

The OFFSET addresses that the CAIPRINT shows for the two S0C7's are different. If this abend was due to corrupt code at a particular point in the program - Then the OFFSET address shown during each of the abend should have been same... ? Right ?
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Tue Dec 09, 2008 12:05 am
Reply with quote

Not necessarily. Compiler options could have been different, maybe other factors too. Please post your relevant code as suggested and display the field in error immediately before it's referenced in the Add Packed instruction or the COBOL verb that contains the AP instruction.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Dec 09, 2008 12:26 am
Reply with quote

Hello,

Quote:
If this abend was due to corrupt code at a particular point in the program - Then the OFFSET address shown during each of the abend should have been same
From what you have posted, there are at least 2 separate problems.

The code "corruption" may be due to (multiple?) bad data that is not being validated at the right time. If this code is reading a file that has been edited to make sure all of the data values are correct, this program should not need to validate the data. If the input file contains data that has not been locally edited, the data for this run may have invalid content.

Where does the input for this process originate? Have there been any changes to the process(es) that create the input for the problem process? If you run the previous input as a test, does the abend still occur?
Back to top
View user's profile Send private message
JayC

New User


Joined: 27 Sep 2008
Posts: 70

PostPosted: Wed Dec 10, 2008 2:30 pm
Reply with quote

Hi,
In restarting the abended job, I pointed to the same record to have the restart from-Now please note that this was the same record that had earlier caused the abend. This time that record went through the programs fine and the 2nd S0C7 happened while processing another record... So, this should be a data issue right ? Maybe some counters are over-flowing ? one more thing, this time around the data that I had to process was almost double the amount I have been processing all these years. Am I missing something here?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Dec 10, 2008 3:00 pm
Reply with quote

Hello,

Quote:
So, this should be a data issue right ?
Data and code combined possibly.

Quote:
Now please note that this was the same record that had earlier caused the abend. This time that record went through the programs fine and the 2nd S0C7
By restarting at the first problem record, the condition of all of the variables and data areas has been changed.

Quote:
this time around the data that I had to process was almost double the amount I have been processing all these years. Am I missing something here
There is some reason the input volume doubled. You need to understand why. This might make the job run longer, but should not cause abends related to invalid numeric data.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed Dec 10, 2008 6:02 pm
Reply with quote

I've told my programmers that a S0C7 is always, always, always a programming issue. Whether they didn't check a value to be numeric before using it, or set the size of a counter or accumulator too small, or trust the input file data format is correct without verifying -- the reason doesn't matter. The fix is the same: correct the erroneous code in the program.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Dec 11, 2008 1:15 am
Reply with quote

Hello,

Quote:
a S0C7 is always, always, always a programming issue.
The programming issue might not be in the program that abended with the 0c7, but in the program that generated bad data.

IMHO, a "master" file should always be correct and every program using it should not validate every field as though it could contain questionable content. If invalid values are ever detected in "the master file" (or the database for that matter), they should be corrected and the code causing the problem changed to prevent the error.

Sometimes, this latter most critical piece is not done due to laziness or inability icon_evil.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Dec 11, 2008 1:46 am
Reply with quote

Dick: if the program got a S0C7, it's not checking its data carefully enough. I don't think I've ever been in a shop where there was a master file with enough rigorous edits to allow programs using data from it not to verify numeric data. Your experience is obviously different.

But then I was working with medical data once and we found a male in the master file who'd had a nervous breakdown. We considered that quite understandable after the hysterectomy, however.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Dec 11, 2008 2:20 am
Reply with quote

Hi Robert,

Quote:
Your experience is obviously different.
Maybe not so very different. . . I just get noisier than most about crap code and crap data icon_smile.gif

The integrity of data has been one of my biggies for a long, long time. One of the places i've been recently still runs daily jobs to find/fix errors in one system's main vsam master - rather than fix the code that causes the bad data. I'm told these fix-it programs have been running for more than 10 years. . .

Quote:
if the program got a S0C7, it's not checking its data carefully enough
Definitely. If the data came from user entry or some external system, i believe every byte of every record should be checked. But i also believe this should be done on the front-end rather than in every process that subsequently uses the files/databases built from the "raw" input.

At a few sites (after seeing what i considered to be too many processing problems), i got the green light to write code that would indeed process the "master files" as though they were "new" data and report on discrepancies. A few files had hundreds of thousands of errors - and various code throughout the system worked around the data problems (some of the workarounds were also incorrect icon_confused.gif ). Sad state when multiple processes have different ways to get around a data problem that should not exist in the first place. And the way things are going, it will only get worse. . .

Oh, yeah, /Rant Off

icon_wink.gif

d
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> ABENDS & Debugging Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts ISAM and abend S03B JCL & VSAM 9
No new posts Abend S0C4 11 (Page Translation Excep... PL/I & Assembler 16
No new posts S0C7 - Field getting overlayed COBOL Programming 2
No new posts WER999A - UNSUCCESSFUL SORT 8ED U Ab... SYNCSORT 5
No new posts the system or user abend SF0F R=NULL COBOL Programming 0
Search our Forums:

Back to Top