|
View previous topic :: View next topic
|
| Author |
Message |
leo_sangha
New User
Joined: 11 Aug 2005
Posts: 85
Location: England
|
|
|
|
Can somebody explain, Will the below MOVE statement work, if YES, why?
01 WS-CODE-1 PIC S9(04) COMP.
01 WS-CODE-2 PIC S9(03) COMP-3.
MOVE WS-CODE-1 TO WS-CODE-2 |
|
| Back to top |
|
 |
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| leo_sangha wrote: |
Can somebody explain, Will the below MOVE statement work, if YES, why?
01 WS-CODE-1 PIC S9(04) COMP.
01 WS-CODE-2 PIC S9(03) COMP-3.
MOVE WS-CODE-1 TO WS-CODE-2 |
If you had looked in any COBOL manual or book you would find the answer. Yes. Why -- Because it is allowed. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| leo - didn't you even think to try it out? That's the only way to really learn and remember the answer. |
|
| Back to top |
|
|
leo_sangha
New User
Joined: 11 Aug 2005
Posts: 85
Location: England
|
|
|
|
| ok guys, dont get upset. Thanks for your prompt replies. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
IMHO, you'd be better off moving the S9(04) COMP field to an S9(09) COMP field and then, move the S9(09) COMP field to the COMP-3 field.
The maximum positive signed value you can have in an S9(04) COMP field is +32767 and when the COMP field is unsigned, this maximum grows to 65535, which is X'FFFF', which would be regarded as -1 in an S9(04) COMP field.
If the COMP-3 field is S9(05) or greater, you could have a high-order truncation issue on the MOVE to an S9(04) COMP field.
However, by moving it to the S9(09) COMP field beforehand, the high-order truncation issue will be reduced, but not eliminated.
Also, be very aware of the COBOL TRUNC compiler option, as it relates to binary-data, because it can burn you big time.
Regards,
Bill |
|
| Back to top |
|
|
Arun Raj
Moderator
Joined: 17 Oct 2006
Posts: 2481
Location: @my desk
|
|
|
|
| Quote: |
| he maximum positive signed value you can have in an S9(04) COMP field is +32767 |
The maximum positive value that can be stored in s9(4) COMP is +9999
Always there is a chance of higher order truncation when you are trying to move from s9(4) to s9(3) whichever numeric type it is in.
There'll not be any problem in moving s9(4) COMP to s9(4) COMP-3.
Thanks,
Arun |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Quote: |
| The maximum positive value that can be stored in s9(4) COMP is +9999 |
That depends on the compiler and the compiler options! |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| arcvns wrote: |
The maximum positive signed value you can have in an S9(04) COMP field is +32767
The maximum positive value that can be stored in s9(4) COMP is +9999
Always there is a chance of higher order truncation when you are trying to move from s9(4) to s9(3) whichever numeric type it is in.
There'll not be any problem in moving s9(4) COMP to s9(4) COMP-3.
Thanks,
Arun |
You need to review your information and understanding of binary. 
If this were true, then why can an S9(04) COMP field such as EIBCALEN in CICS, have a maximum-value of +32763 or for that matter, any other CICS-API which uses a binary-halfword length, whose values often exceed +9999?
BTW, the only COMP-3 field which uses an even number of digits effectively (without specifying the ARITH EXTEND option) is 9(18), whereas 9(02), 9(04), 9(06), etc, are wasted definitions as you're limiting the number of digits, but the same number of bytes are allocated, regardless.
As far as the high-order truncation, I had pointed out (either implicitly or explicitly) that moving a binary-halfword to a two-packed packed-decimal field, would in high-order truncation if the halfword value exceeded +999, which makes perfect sense.
One case in which TRUNC(OPT) can burn you is in a VALUE clause of a binary-field and that value exceeds the defined number of digits. However, TRUNC(BIN) will ensure that the value clause is honored, regardless, but generates brutally inefficient code, treating binary-data as packed-decimal.
Bill |
|
| Back to top |
|
|
|
|
