|
View previous topic :: View next topic
|
| Author |
Message |
sprikitik
New User
Joined: 29 Jan 2007
Posts: 61
Location: Makati City, Philippines
|
|
|
|
HEllo,
WS-TMP-YY-MM PIC S9(06).
WS-TMP-XX-XX PIC S9(04) USAGE COMP.
How do i move WS-TMP-YY-MM to WS-TMP-XX-XX correctly?
Im my program, if WS-TMP-YY-MM is +201103, when moved to WS-TMP-XX-XX, the value of WS-TMP-XX-XX is +4495.
thanks |
|
| Back to top |
|
 |
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| How do you expect to move 6 digits to 4 digits?? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Indeed, make the COMP field bigger.
You have defined it to hold four digits (maximum value 9999*). You are trying to move six digits to it. It is not going to work.
*You have TRUNC(BIN) as your compiler option. This will utilise all the bits irrespective of the PICTURE (the PICTURE determines the size of the storage, in this case a "half-word", then you have access to all the bits in the half-word, giving you, for a signed field, values in the range +32767 to -32768.
You then move 201103 to this field. This will cause truncation. 201103 in hex is 3118F. Drop the three (a half-word is two bytes, four hex digits). That gives you 118F. 118F in decimal is 4495.
Edit: I said "I suspect you have TRUNC(BIN). Pointless, since I know you have it. |
|
| Back to top |
|
|
sprikitik
New User
Joined: 29 Jan 2007
Posts: 61
Location: Makati City, Philippines
|
|
|
|
| Bill Woodger wrote: |
Indeed, make the COMP field bigger.
You have defined it to hold four digits (maximum value 9999*). You are trying to move six digits to it. It is not going to work.
*I suspect you have TRUNC(BIN) as your compiler option. This will utilise all the bits irrespective of the PICTURE (the PICTURE determines the size of the storage, in this case a "half-word", then you have access to all the bits in the half-word, giving you, for a signed field, values in the range +32767 to -32768.
You then move 201103 to this field. This will cause truncation. 201103 in hex is 3118F. Drop the three (a half-word is two bytes, four hex digits). That gives you 118F. 118F in decimal is 4495. |
Thanks for the explanation! |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
No problem.
If you have a chance, compare it with the truncation without TRUNC(BIN).
You'll get a different answer. Scratch here XXXX to see what it is.
Your receiving field should always be at least as big (in digits) as your sending field, unless you deliberately want truncation.
Get used to the hex representation of binary values. Something you'll need for dump-solving, if nothing else.
If you want to see the hex without a dump, redefine your binary field
| Code: |
01 W-A-BINARY-VALUE-TWO-BYTES COMP PIC S9( 1-4 ) (one to four digits, will occupy the same space)
01 W-DISPLAY-CONTENTS-OF-TWO-BYTE-BINARY
REDEFINES W-A-BINARY-VALUE-TWO-BYTES PIC XX.
01 W-A-BINARY-VALUE-FOUR-BYTES COMP PIC S9( 5-9 )
01 W-DISPLAY-CONTENTS-OF-FOUR-BYTE-BINARY
REDEFINES W-A-BINARY-VALUE-FOUR-BYTES PIC X(4).
DISPLAY ">" W-DISPLAY-CONTENTS-OF-TWO-BYTE-BINARY "<"
DISPLAY ">" W-DISPLAY-CONTENTS-OF-FOUR-BYTE-BINARY "<" |
Then, when looking at the output, put HEX on. You'll see the hex value in your binary field. |
|
| Back to top |
|
|
|
|
