|
View previous topic :: View next topic
|
| Author |
Message |
sandra
New User
Joined: 06 Apr 2005
Posts: 27
|
|
|
|
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 |
|
 |
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
David P
Active User
Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio
|
|
|
|
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 |
|
|
vidyasaraswathi
New User
Joined: 10 May 2005
Posts: 72
|
|
|
|
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 |
|
|
senthilkumar selvaraju
New User
Joined: 30 May 2005
Posts: 16
|
|
|
|
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 |
|
|
sandra
New User
Joined: 06 Apr 2005
Posts: 27
|
|
|
|
Hi Vidya,
To define comp3 greater than 10 bytes, we have to include the statement Process Arith(extend) before identification division. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
I take back my previous apologies. 
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 |
|
|
David P
Active User
Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio
|
|
|
|
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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
David P
Active User
Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio
|
|
|
|
Hi Jack,
Thanks for your response.
regards,
David. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
| You're welcome David, but you didn't say whether you agreed or not. |
|
| Back to top |
|
|
David P
Active User
Joined: 11 Apr 2005
Posts: 106
Location: Cincinnati Ohio
|
|
|
|
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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
|
|
