View previous topic :: View next topic
|
Author |
Message |
Kmr.deepakcs
New User
Joined: 11 Oct 2013 Posts: 37 Location: India
|
|
|
|
Dear experts.
I have a confusion..
what is difference between s9(6) comp-3 and s9(7) comp-3.
We know both will take 4 bytes in packed data representation..
Then when we use s9(6) comp-3 or s9(7) comp-3. what is internal memory representation difference b/w both of them.
Regards:
Deepak kumar |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
There is no difference in how they are stored.
There is a difference in how they get to where they are stored.
Any COMP-3 field with an even number of digits (all digits, that is, before or after the implied decimal place (which, when not specified, is in the obvious place) will have, when the compiler feels it is needed, code generated to ensure that nothing ever gets into the left-most half-byte of the field. Like an "AND" (NI) with X'0F'.
However, the NI-code will only be generated when the field is a target. If someone REDEFINES using a COMP-3 with an even number of digits, then no code is generated to protect the left-most half-byte and a pickle can ensue when the field is used as the source of a statement.
Why do you want to know? |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
As Bill has said, both definitions are 4 bytes packed. You MIGHT get truncation moving a 7-digit number into the S9(6) definition, I don't remember. A good way to find out is to test it. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
When a six-digit COMP-3/PACKED-DECIMAL is the target of something which has more than six digits there will definitely be actual truncation.
There will be an assumption by the compiler that all source six-digit fields do conform to PICture (nothing in the high-order half-byte).
Code: |
01 a-nicely-named-field PACKED-DECIMAL PIC 9(7).
01 another-nice-name
REDEFINES a-nicely-named-field
PACKED-DECIMAL PIC 9(6).
01 a-further-field-nice-name-of-course PIC 9(7).
MOVE 123467 TO a-nicely-named-field
MOVE another-nice-name TO a-further-field-nice-name-of-course
DISPLAY a-further-field-nice-name-of-course
DISPLAY another-nice-name |
The result in a-further-field-nice-name-of-course will be 1234567, seven digits, which have come from another-nice-name (nominally six digits) although DISPLAY another-nice-name will only show six digits because the compiler knows for DISPLAY that the field is only six digits long.
So, don't, or be incredibly careful (and a good documenter) when doing it, use REDEFINES with COMP-3/PACKED-DECIMAL and an even number of digits. Otherwise you get great confusion and "But I know my program is right, I DISPLAY the field".
If you really want to know what is in any COMP-3/PACKED-DECIMAL using DISPLAY, use REDEFINES to make it a PIC X(of the correct size), DISPLAY the PIC X and look at the output in HEX. Or use some module which does hex output of storage. One can be found in this forum. OK, several can be found in this forum... |
|
Back to top |
|
|
|