S0C7 ABEND when no arithmatic statment

JayC · New User Joined: 27 Sep 2008 Posts: 70

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.

Robert Sample · Posted: Sun Dec 07, 2008 12:52 am

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.

Bill O'Boyle · Posted: Sun Dec 07, 2008 2:06 am

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

JayC · New User Joined: 27 Sep 2008 Posts: 70

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

dick scherrer · Posted: Sun Dec 07, 2008 2:28 am

Hello,

JayC · New User Joined: 27 Sep 2008 Posts: 70

Thank you so much... Robert.. Bill...Dick,
Thats some good information for me to work on..

dick scherrer · Posted: Sun Dec 07, 2008 5:00 am

You're welcome

I just noticed this from your initial post:

Robert Sample · Posted: Sun Dec 07, 2008 8:44 am

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.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

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.

JayC · New User Joined: 27 Sep 2008 Posts: 70

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

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

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.

JayC · New User Joined: 27 Sep 2008 Posts: 70

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 :

Terry Heinze · Posted: Mon Dec 08, 2008 9:16 pm

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.

Robert Sample · Posted: Mon Dec 08, 2008 9:42 pm

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.

dick scherrer · Posted: Mon Dec 08, 2008 9:55 pm

Hello,

JayC · New User Joined: 27 Sep 2008 Posts: 70

Dick this program has been running fine for the last 15years in production.

JayC · New User Joined: 27 Sep 2008 Posts: 70

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 ?

Terry Heinze · Posted: Tue Dec 09, 2008 12:05 am

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.

dick scherrer · Posted: Tue Dec 09, 2008 12:26 am

Hello,

JayC · New User Joined: 27 Sep 2008 Posts: 70

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?

dick scherrer · Posted: Wed Dec 10, 2008 3:00 pm

Hello,

Robert Sample · Posted: Wed Dec 10, 2008 6:02 pm

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.

dick scherrer · Posted: Thu Dec 11, 2008 1:15 am

Hello,

Robert Sample · Posted: Thu Dec 11, 2008 1:46 am

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.

dick scherrer · Posted: Thu Dec 11, 2008 2:20 am

Hi Robert,