|
View previous topic :: View next topic
|
| Author |
Message |
bhairon singh rathore
New User
Joined: 19 Jun 2008
Posts: 91
Location: banglore
|
|
|
|
Tried below code it works in cobol.
why ??
ws-num would not contain non numeric value.
Output of below code
ABCDE
ABCD5
Working-storage section
01 WS-GRP.
05 WS-NUM PIC 9(5).
05 WS-STR PIC X(10).
01 WS-NUM2 PIC 9(5).
Procedure division
MOVE 'ABCDEFGDHAK' TO WS-GRP.
MOVE WS-NUM TO WS-NUM2.
Display WS-NUM.
Display WS-NUM2. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
A very common mistake beginners make in COBOL is to think that a numeric variable will only contain numbers. THIS IS NOT TRUE! As your example shows, a numeric zoned decimal variable may contain numbers or letters and COBOL will not have any problem with that. If you added one to WS-NUM, you would find the value becomes 12345 due to the way COBOL does arithmetic.
It is the responsibility of the programmer to ensure that a numeric variable contains only numbers -- COBOL has no such rule and will not enforce any such restriction, as you have seen. |
|
| Back to top |
|
|
bhairon singh rathore
New User
Joined: 19 Jun 2008
Posts: 91
Location: banglore
|
|
|
|
Thanks Robert,
Then when the concept of SOC7 comes into picture |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| The S0C7 abend occurs when you do arithmetic with a packed decimal (note this is COMP-3) variable that contains data that does not match the packed decimal requirements. The zoned decimal variable you used would not cause a S0C7 abend because when you add 1 to it, the variable is first packed -- which ignores the first 4 bits of each byte -- then the addition is done to the packed decimal value then the value is unpacked, at which time the first 4 bits of each byte are set such that only numbers are present. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
keep in mind that PIC 9(9) or S9(9) is numeric DISPLAY usage
which are baiscally alphanumeric elements that can be used in arithmetic instructions. (where as alpha elemens - X) can not.
you enter the world of actual numeric elements when your usage is COMP-3. |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
'E' is x'C5', an unsigned move forces hex F in the sign nibble.
The fifth byte thus becomes x'F5', which is... '5'  |
|
| Back to top |
|
|
bhairon singh rathore
New User
Joined: 19 Jun 2008
Posts: 91
Location: banglore
|
|
|
|
| Thanks, |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Adding to Kjeld's post, after WS-NUM is loaded with ABCDE, move it to an S9(05) COMP-3 field and it will equal P'12345'.
Internally, a PACK instruction discards the zones (except for the last byte, where the byte is flipped and the zone becomes a sign-nibble). Plus, if the receiving field is signed, an internal ZAP is issued (after the PACK) of the packed-field itself to ensure a 'C' (or a 'D' for negative) sign-nibble.
However, if the receiving field is not signed, the compiler will issue an OI X'0F' against the last byte, instead of a ZAP, to ensure an 'F' sign-nibble.
Bill |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
Wrinkle
You may do arithmetic with an S9(5) DISPLAY, and under certain circumstances the compiled code will convert to packed-decimal and then convert back. If I remember, this is in fact to do an OI dealing with the sign.
The point is, invalid numeric in the originating field may then cause an S0C7, even though your field is DISPLAY. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| Code: |
03 WS-NUM PIC 9(05).
03 WS-NEUTRAL PIC 9(05) COMP-3.
03 WS-SIGNED PIC S9(05) COMP-3.
MOVE LOW-VALUES TO WS-NUM (1:).
MOVE WS-NUM TO WS-NEUTRAL.
MOVE WS-NUM TO WS-SIGNED.
|
The MOVE of LOW-VALUES to WS-NUM (1:) is legitimate because WS-NUM is treated by the compiler as if it were PIC X(05). Without the reference modification, you'd get a compile error.
The first MOVE of WS-NUM to WS-NEUTRAL will work and the result in WS-NEUTRAL will be X'00000F' or Packed-Neutral ('F' sign-nibble) as the compiler will issue an OI X'0F' against the last byte after the PACK.
The second MOVE of WS-NUM to WS-SIGNED will raise an 0C7 because a ZAP will be issued against the packed-field itself (after the PACK) and because the sign-nibble is X'0', the data-exception occurs.
Both examples are based upon the default compiler option of NUMPROC(NOPFD).
Use NUMPROC(PFD) at your own risk and consider the potential pitfalls.... ;o)
HTH....
Bill |
|
| Back to top |
|
|
|
|
