|
View previous topic :: View next topic
|
| Author |
Message |
tushar_study
New User
Joined: 01 Feb 2007
Posts: 30
Location: Mumbai
|
|
|
|
Hi ,
I have the following working storage declaration:
| Code: |
01 WS-VAR.
05 WS-NUM.
10 WS-NUM1 PIC 9(02).
10 WS-NUM1 PIC 9(03).
05 WS-ALPHA REDEFINES WS-NUM PIC X(05) VALUE 'ABCDE'. |
MY QUERY :
1) WHETHER THE PROGRAM WILL COMPILE PROPERLY(AS I AM DOUBTFUL WHETHER NUMERIC WILL BE ABLE TO HOLD 'ABCDE').
2) WILL THE ABNORMAL CONDITION OCCUR ONLY DURING MOVES.
REGARDS,
tUSHAR |
|
| Back to top |
|
 |
prav_06
Warnings : 1
Active User
Joined: 13 Dec 2005
Posts: 154
Location: The Netherlands
|
|
|
|
Tushar,
Remove the value clause from u r w-s item it should go thro fine while compilation. and for u r second question yes if ya trying to move the WS-ALPHA item to a comp with non-numeric values YES u get a 0C7.
Thamilzan. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Code: |
01 WS-VAR.
05 WS-ALPHA PIC X(05) VALUE 'ABCDE'.
05 WS-NUM REDEFINES WS-ALPHA.
10 WS-NUM1 PIC 9(02).
10 WS-NUM1 PIC 9(03). |
This will compile better.
And yes, garbage in numeric fields can result in an 0C7... |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| I thought 0C7 was a packed decimal abend. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Phrzby Phil wrote: |
| I thought 0C7 was a packed decimal abend. |
Any math on those numeric fields could cause an 0C7. Why do you think not? |
|
| Back to top |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006
Posts: 771
Location: Germany
|
|
|
|
Hi !
S0C7
This ABEND is only caused by a data exception and can only occur
when decimal (packed) instructions are used.
The sign or digit codes of one or more bytes manipulated by the packed or CONVERT TO BINARY instructions is invalid for packed decimal use. Packed decimal digits must be in the range 0 through 9, with only the sign (i.e., rightmost) digit being a digit in the range A to F.
Fields in decimal (packed) arithmetic overlap incorrectly.
A packed decimal multiplicand has too many high-order significant digits.
The target operand of a CVD assembler instruction is not on a doubleword boundary
Regards, UmeySan |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
In order to perform arithmetic on a zoned decimal number it is first "packed internally". If a PIC 9(5) field that contains non-numeric data is used in an ADD statement, that will cause an 0c7.
The definition in the code does NOT have to be packed decimal to get an 0c7.
Keep in mind that there are packed decimal arithmetic and binary arithmetic assembler instructions, but there are NO zoned decimal arithmetic instructions. When you specify calculatons on zoned numbers, the compiler generates the necessary assembler conversion instructions and then does the calculaton with the generated packed decimal numbers.
This is also true if you move a PIC 9(5) field to a field of ZZ,ZZZ. The assembler to apply the editing uses a packed decimal number as input.
If you want to see this, look at the generated assembler code. |
|
| Back to top |
|
|
sachin_star3
Warnings : 1
New User
Joined: 30 Sep 2006
Posts: 78
Location: pune
|
|
|
|
redefine clause never used with value clause
and when alphanumeric value move to comp or numeric then it works fine only when alphanumeris contains the numeric value
but when alphanumeris value contains the other than numeris value then it gives soc7
from-sachin borase
pune |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
As Dick stated, it is correct that that certain USAGE DISPLAY calcs are converted to packed-dec, and as such invalid data in those can issue an 0C7.
Note that these are still packed-dec data errors, but not necessarily COMP-3 data errors. |
|
| Back to top |
|
|
|
|
