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
 

 

SOC7 Numeric Movement

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
HameedAli

Active User


Joined: 16 Apr 2009
Posts: 151
Location: India

PostPosted: Tue Sep 11, 2012 7:13 pm    Post subject: SOC7 Numeric Movement
Reply with quote

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

Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Tue Sep 11, 2012 7:34 pm    Post subject: Reply to: SOC7 Numeric Movement
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Tue Sep 11, 2012 7:37 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


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

PostPosted: Tue Sep 11, 2012 7:55 pm    Post subject: Reply to: SOC7 Numeric Movement
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Wed Sep 12, 2012 2:20 am    Post subject: Reply to: SOC7 Numeric Movement
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Wed Sep 12, 2012 2:41 am    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Wed Sep 12, 2012 6:01 am    Post subject: Reply to: SOC7 Numeric Movement
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Wed Sep 12, 2012 6:43 am    Post subject:
Reply with quote

Hello,

Please note i've edited my previous post to clarify. . .
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 -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts Casting a Binary Number to Numeric in... Bob Steinkraus Java & MQSeries 6 Tue Aug 09, 2016 5:58 pm
This topic is locked: you cannot edit posts or make replies. Alphanumeric to Numeric move on UNIX mistah kurtz COBOL Programming 16 Wed Jul 27, 2016 8:47 pm
No new posts pass numeric value of length 14 to ti... Ralph Zbrog Java & MQSeries 4 Fri Jan 15, 2016 3:20 pm
No new posts Conversion from Numeric to BCD format dharmaraok DFSORT/ICETOOL 6 Mon Jan 11, 2016 9:27 pm


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