View previous topic :: View next topic |
Author |
Message |
pkarthik@email.com Beginner
Joined: 29 Mar 2005 Posts: 34 Topics: 18 Location: Canada
|
Posted: Tue Sep 06, 2011 1:25 am Post subject: SOC7 Occured but No COMP-3 data type involvement |
|
|
We received below error.
Code: |
The system detected a data exception (System Completion Code=0C7).
From compile unit BSP390 at entry point BSP390 at compile unit offset +00000DC4 at entry offset +00000DC4
at address 21A4EDC4. |
Compiler Offset points to below location.
Code: |
IF C390-ARRAY(SUB1:1) IS NOT EQUAL TO '~'
ADD +1 TO SUB1
ELSE
ADD -1 TO SUB1
MOVE SPACES TO WS-INP-ARR
|
Initialisation happens like this
Code: |
05 SUB1 PIC 9(03) VALUE ZEROS.
05 SUB2 PIC 9(03) VALUE ZEROS.
05 SUB3 PIC 9(03) VALUE ZEROS.
|
Please help _________________ For any type of complex problems there will be multiple easiest solutions |
|
Back to top |
|
|
dbzTHEdinosauer Supermod
Joined: 20 Oct 2006 Posts: 1411 Topics: 26 Location: germany
|
Posted: Tue Sep 06, 2011 5:22 am Post subject: |
|
|
pathetic.
the offset points exactly to an executable instruction. which one is it?
part of the IF or one of the adds?
showing us working-storage definitions and a snipet of code is useless.
it could very be that the value of SUB1 during the REFERENCE Modification is zero or greater that the length of C390-Array.
it is really very poor to use display numeric as a reference modification variable.
and last but not least. you are subtracting from an unsigned field. _________________ Dick Brenholtz
American living in Varel, Germany |
|
Back to top |
|
|
John_Deal Beginner
Joined: 04 Sep 2003 Posts: 15 Topics: 1
|
Posted: Tue Sep 06, 2011 8:12 am Post subject: |
|
|
Additionally, a S0C7 has nothing to do with a COMP-3 field. It is non-numeric data in a referenced numeric field.
8) _________________ Life is a journey; enjoy the trip! |
|
Back to top |
|
|
papadi Supermod
Joined: 20 Oct 2009 Posts: 594 Topics: 1
|
Posted: Tue Sep 06, 2011 10:38 am Post subject: |
|
|
If you look at the expanded instructions generated by an add / subtract of a zoned-decimal number, you will notice that there are intermediate packed-decimal fields used. . . _________________ All the best,
di |
|
Back to top |
|
|
pkarthik@email.com Beginner
Joined: 29 Mar 2005 Posts: 34 Topics: 18 Location: Canada
|
Posted: Tue Sep 06, 2011 10:58 pm Post subject: |
|
|
Hi All,
This is a existing program executing in production for several years .Failed un-expectedly twice in production last week.
1. C390-Array is defined as X(100).
2. SUB1 has no reference modifications either.Its initialised to Zero in working storage section.
Our team was realy confused ? What's causing S0C7.Compiler offset points to Add Instruction.
Please help. _________________ For any type of complex problems there will be multiple easiest solutions |
|
Back to top |
|
|
dbzTHEdinosauer Supermod
Joined: 20 Oct 2006 Posts: 1411 Topics: 26 Location: germany
|
Posted: Wed Sep 07, 2011 2:12 am Post subject: |
|
|
pkarthik@email.com wrote: | This is a existing program executing in production for several years |
the german for 'so what' is 'na und?'
though not gutteral, the enunciation is enough to envision total distain, even to non german speakers.
since you have taken such a positive track
(must be something wrong with the op-system)
on the solution to your problem
you are going to have problems
and can see why you and your team are confused.
first, the variable SUB1 is used in a reference modification instruction as the starting location of a memory location.
as papadi alluded,
the underlying code generated by the compiler
to convert the value of this stupid/rookie PIC 9(3) variable to Binary for use in the reference modification
as well as for use in the ADD instructions,
first converts to PACKED-DECIMAL............
datatype conversions (display numeric to binary)
and computational instructions
ALWAYS use PACKED-DECIMAL,
and hence your non-numeric error which caused the ABEND.
now, go back to your assembler listing of your program,
and find exactly which instruction is failing
and you will find your culprit. _________________ Dick Brenholtz
American living in Varel, Germany |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Wed Sep 07, 2011 10:10 am Post subject: |
|
|
pkarthik@email.com,
If I had to take an educated guess , I think you have a working storage table just above the declaration of the variables you have shown. The working storage table you are loading might have overflowed and corrupted the variables you show. So check if there is an overflow. Also I would suggest adding the following line as the first line in your program(before ID Division) and re-run the program again to check if your subscript is out of bounds.
Check this link for a detailed explanation of compiler parameter SSRANGE
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG10/2.4.48?DT=20020923143836
Hope this helps...
Cheers
Kolusu |
|
Back to top |
|
|
misi01 Advanced
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
|
Posted: Thu Sep 29, 2011 3:02 am Post subject: |
|
|
My 2c's worth would be "Good call, Kolusu". I'll bet you're right.
pkarthik - I'm gonna assume you don't have access to something like Fault ananlyzer or similar ? _________________ Michael |
|
Back to top |
|
|
|
|