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

Getting a S0c7 abend with MOVE Statement


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
sandra

New User


Joined: 06 Apr 2005
Posts: 27

PostPosted: Tue May 31, 2005 9:42 pm
Reply with quote

I am getting a S0c7 abend when I try to move the following fields.Could anyone figure this out.
When i display the charge-amount field, it is displayed as

CHARGE-AMOUNT:00000000000000000000000000



CHARGE-AMOUNT PIC S9(23)V9(3) USAGE COMP-3.

POPF175B-FRT-AMT PIC S9(5)V99 COMP-3.





MOVE CHARGE-AMOUNT OF FACT1123-REC TO POPF175B-FRT-AMT
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jun 01, 2005 8:19 am
Reply with quote

Hi Sandra,

When you DISPLAY a packed field an attempt to convert it to a displayable format takes place. Because of that, you can't tell what the data in the field really is. To prevent the conversion, try the following:

If the field is part of a group item, you DISPLAY the group item using reference modification. For example:
Code:

05 grp-item.
    other-fld1    PIC 9(04).   
    other-fld2    PIC x(05).   
    your-fld      PIC S9(23)V9(3) USAGE COMP-3.
      .   
      .   
      .   
DISPLAY 'DEBUG- HERE IS YOUR-FLD >' GRP-ITEM(10:14) '<'

When you look at SYSOUT in SDSF you'll probably see what look like SPACES between the ><. That's because you used "s" to view it. PF3 out and re-view it using "se", then enter "hex" on the cmd line.

This will show you the hex value of the contents of your field. It's probably spaces or binary zeros.
Back to top
View user's profile Send private message
David P

Active User


Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio

PostPosted: Wed Jun 01, 2005 10:39 am
Reply with quote

Hi Sandra,
Are you sure this move statement is causing the S0C7. As I believe any arithmatic operation on nonnumeric field can cause S0C7 but the move statement cann't. Please confirm this.

Correct me if I am wrong.

regards,
David.
Back to top
View user's profile Send private message
vidyasaraswathi

New User


Joined: 10 May 2005
Posts: 72

PostPosted: Wed Jun 01, 2005 11:45 am
Reply with quote

Hi,
I have a doubt here.

You are saying CHARGE-AMOUNT is defined as PIC S9(23)V9(3) USAGE COMP-3.
But, I have read somewhere that the maximum length of a field you can define using comp-3 is 10 bytes (i.e, s9(18) COMP-3).

How it is possible to define S9(23)V9(3) COMP-3 ?

Thanks and Regards,
Vidya Bhat
Back to top
View user's profile Send private message
senthilkumar selvaraju

New User


Joined: 30 May 2005
Posts: 16

PostPosted: Wed Jun 01, 2005 12:34 pm
Reply with quote

hi sandra,

I am not sure about comp-3 . You try to use packed-decimal instead of comp-3.

ex: CHARGE-AMOUNT PIC S9(23)V9(3) USAGE COMP-3.

CHARGE-AMOUNT PIC S9(23)V9(3) USAGE PACKED-DECIMAL.
Back to top
View user's profile Send private message
sandra

New User


Joined: 06 Apr 2005
Posts: 27

PostPosted: Wed Jun 01, 2005 9:44 pm
Reply with quote

Hi Vidya,
To define comp3 greater than 10 bytes, we have to include the statement Process Arith(extend) before identification division.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Thu Jun 02, 2005 5:17 am
Reply with quote

My comment here was deleted by me. The previous poster is correct - A move will not result in an 0C7.

My apologies for the misstatement.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Sat Jun 04, 2005 5:21 am
Reply with quote

I take back my previous apologies. icon_biggrin.gif

A MOVE to or from a comp-3 field using invalid data WILL cause an 0C7 ABEND.

David said:
Quote:
As I believe any arithmatic operation on nonnumeric field can cause S0C7 but the move statement cann't.

He was correct up to a point: only arith ops will cause an 0C7. The thing is, that "moving" data to/from a comp-3 field IS an arith op.

How it works moving to:

The sending field is packed and is ZAPed into the comp-3 field. A ZAP is an assembler instruction that means "Zero & Add Packed". It sets the receiving field to zeros and does a packed add into it. If the sending field contains invalid data the ZAP will fail w/an 0C7.

How it works moving from:

The sending field in this case is already packed and is ZAPed into a temp comp-3 field. Then it is unpacked into the DISPLAY field.

If the comp-3 field contains invalid data, the ZAP will fail w/an 0C7.

Take a look at this:

WS
01 JACK-FIELDS.
05 JACK-PD PIC S9(4) COMP-3.
05 JACK-DISP PIC S9(4).

PD
MOVE SPACES TO JACK-FIELDS
MOVE JACK-DISP TO JACK-PD

Generates this assembler code:
Code:

PACK  0(3,7),8(4,7)     JACK-PD <==  JACK-DISP
ZAP   0(3,7),0(3,7)     JACK-PD <==  JACK-PD


MOVE JACK-PD TO JACK-DISP

Generates this assembler code:
Code:

ZAP   2896(3,13),0(3,7)    TS2=16   <== JACK-PD
UNPK  8(4,7),2896(3,13)   JACK-DISP <== TS2=16
Back to top
View user's profile Send private message
David P

Active User


Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio

PostPosted: Mon Jun 06, 2005 10:13 am
Reply with quote

Hi jack,

Thanks for your detailed explanation but I still doubt that PACK and UNPK
assembler instruction check the validity of the data. Please confirm this
once.

thanks in advance,
David..
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Mon Jun 13, 2005 8:02 am
Reply with quote

Hi David,

Sorry for the delay in answering. I went off on a vacation.

It's not the PACK/UNPACK that causes the abend, it's the ZAP (it's an acronym for "Zero and Add Packed"). ZAP is an arithmatic instruction. It zeros the field then ADDs the value to be "moved".
Back to top
View user's profile Send private message
David P

Active User


Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio

PostPosted: Mon Jun 13, 2005 9:32 am
Reply with quote

Hi Jack,
Thanks for your response.

regards,
David.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jun 15, 2005 7:12 am
Reply with quote

You're welcome David, but you didn't say whether you agreed or not.
Back to top
View user's profile Send private message
David P

Active User


Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio

PostPosted: Wed Jun 15, 2005 9:48 am
Reply with quote

Hi Jack,

I agree with your explanation about ZAP, I was wondering if PACK or UNPK instructions check the validity of the data.

regards,
David.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Thu Jun 16, 2005 6:27 am
Reply with quote

Hi David,

No, a validity check isn't performed. They don't cause 0C7s. Only aritmatic ops do. BUT, some moves (usually those that require conversion from one numeric type to another) do perform arithmatic ops.
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 -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts ISAM and abend S03B JCL & VSAM 9
No new posts COBOL - Move S9(11)v9(7) COMP-3 to -(... COBOL Programming 5
No new posts How to move the first field of each r... DFSORT/ICETOOL 5
No new posts Abend S0C4 11 (Page Translation Excep... PL/I & Assembler 16
No new posts S0C7 - Field getting overlayed COBOL Programming 2
Search our Forums:

Back to Top