View previous topic :: View next topic
|
Author |
Message |
HameedAli
Active User
Joined: 16 Apr 2009 Posts: 151 Location: India
|
|
|
|
Hi,
I am getting SOC7, when I check whether the variable is Numeric, I found it to be true and the value is 0
Code: |
DSN ENDED DUE TO ERROR+
SYSTEM ABEND CODE 0C7 REASON CODE 00000007 |
Code: |
CEE3207S The system detected a data exception (System Completion Code=0C7).
From compile unit PROGRAMN at entry point PROGRAMN at compile unit offset +00004852 at entry offset +00004852 at address 13059EC2. |
Code: |
IMP-RETRB-MENS PIC S9(15)V9(3) USAGE COMP-3.
IM-GRS-SLR PIC S9(15)V9(3) USAGE COMP-3.
MOVE IM-GRS-SLR OF DCLICTBG03 TO IMP-RETRB-MENS OF RECIRER1 |
Code: |
IF IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
DISPLAY 'IM-GRS-SLR-B :' IM-GRS-SLR OF DCLICTBG03
DISPLAY 'IM-GRS-SLR OF DCLICTBG03 IS NUMERIC'
END-IF
IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
IM-GRS-SLR-B :000000000000000000 |
How is this possible? |
|
Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010 Posts: 121 Location: Puerto Rico
|
|
|
|
Good day!
If your compare for numeric is after the move which is causing the SOC7 then that instruction (the MOVE) is not the one causing it. Get a LIST (PMAP) of the program then allocate the offset where it abended. The assembler OP code before the offset is the one causing it and it's probably a ZAP command. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
I suspect you have gotten the wrong field as the culprit. . . Or the data was corrupted after you checked it for numeric.
You need to look in the dump to make sure what value is in the problem field at the time of the abend. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
If the program is compiled using NUMPROC(PFD) then the actual bad packed-decimal data could have been ignored until an actual packed-decimal instruction (IE: ZAP) caused the data-exception.
For example, an MVC could have been generated by the compiler (NUMPROC(PFD)) to move one COMP-3 field to another. An MVC will never cause a data-exception. Also, this compiler option could raise a false positive, when one COMP-3 field has a 'C' sign-nibble and another COMP-3 field has a 'F' sign-nibble and would cause a not equal condition, even though the numeric-portion of the fields are equal, because a CLC rather than a CP was generated by the compiler. I'm not a big advocate of NUMPROC(PFD) and would much rather encounter bad packed-decimal data sooner than later, defaulting to NUMPROC(NOPFD), before any damage is done.
Just my two cents.... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Quote: |
Code: |
IF IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
DISPLAY 'IM-GRS-SLR-B :' IM-GRS-SLR OF DCLICTBG03
DISPLAY 'IM-GRS-SLR OF DCLICTBG03 IS NUMERIC'
END-IF
IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
IM-GRS-SLR-B :000000000000000000 |
|
You are showing the DISPLAY output as being "the other way around". Possibly the wrong bit of code, possibly you have "IS NUMERIC" from the previous and the "zero-looking" from the current.
I suspect you are using NUMPROC(NOPFD).
Can you confirm the value of NUMPROC compiler option please? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
If this is still not resolved, suggest you put an eye-catcher in front of each of these fields (as long as they are in working storage - and not in some record layout or other construct that is a group item). Something like:
Code: |
FILLER PIC X(05) VALUE 'MENS>'.
IMP-RETRB-MENS PIC S9(15)V9(3) USAGE COMP-3.
FILLER PIC X(04) VALUE 'SLR>'.
IM-GRS-SLR PIC S9(15)V9(3) USAGE COMP-3. |
Then look in the dump for the for the eye-catchers to see what is really in the fields. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
The NUMERIC test works. Always has, always will.
If the field was NUMERIC, you'd have got this:
Code: |
IM-GRS-SLR-B : 000000000000000000
IM-GRS-SLR OF DCLICTBG03 IS NUMERIC |
You say you got this:
Code: |
IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
IM-GRS-SLR-B : 000000000000000000 |
You might hat this without having shown us
Code: |
IM-GRS-SLR-B : 000000000001234567
IM-GRS-SLR OF DCLICTBG03 IS NUMERIC
IM-GRS-SLR-B : 000000000000000000 |
You might have, separately, in the program
Code: |
DISPLAY 'IM-GRS-SLR-B :' IM-GRS-SLR-B OF DCLICTBG03
|
or something
If your comp-3 field contains low-values, it will still DISPLAY as 000000000000000000. Don't be fooled by this. To see what is really in the field, you have to see the hex values, not see what DISPLAY makes of it in its native form.
So, you can search for BBHEXD in the forum.
Or you can REDEFINE your field as PIC X(9). Display that. Then SET HEX ON to see the hex value. I'd bet it is not a valid packed-decimal.
Now, how low-values got in there is of course the interesting part.... |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Please note i've edited my previous post to clarify. . . |
|
Back to top |
|
|
|