|
View previous topic :: View next topic
|
| Author |
Message |
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
example:
3796100502
FFFFFFFFFFC
3796100502
you can see the hex value F3 for 3.
why it's F3, not 03?
confusion.... |
|
| Back to top |
|
 |
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
|
|
Hi,
are you saing that HEX ON is not telling you the truth ?
Gerry |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| i think so, or what i understood is wrong. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
when i use the icetool to sum some records on a field and got the summary as below with hex value.
023541
00193C
if i use the normal hex to change it, i got wrong number, in fact the value is 2031594.31
Anyone can tell me why? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
The field you describe is a 6 byte packed decimal field. Packed decimal fields hold one digit per nibble and a sign-nibble at the right. The field is non-printable and must be unpacked to be printable.
The sign-nibble is 'C' for positive, 'D' for negative or 'F' for unsigned.
In this case the printable field would be 11 bytes and would read either '0020315943A' ( X'F0F0F2F0F3F1F5F9F4F3C1' ) or '00203159431' ( X'F0F0F2F0F3F1F5F9F4F3F1' ).
The internal representation does not use the decimal point, that's specified by a mask in the program using the field ( e.g. PIC'(9)V.99' ). The mask can also specify whether the sign is displayed or not.
Garry. |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| this field is not EBIDIC code? why the hex value is like that? |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| So when i use the hex on command , what i get? it's not a really hex value? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| why the hex value is like that? |
This goes back to the days when memory was very restricted and disk/tape was expensive. Using this format saved space.
| Quote: |
| it's not a really hex value? |
It is a hex value. A hex byte can be anything from X'00' to x'FF' - there are 256 possible hex values and not all are printable.
The value you are seeing is what mainframe programming languages commonly use for manipulating numeric values.
Garry. |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| Could you give me some reference about this ? very appreciate. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
Try Googling 'packed decimal'. There are many references, e.g.
www.simotime.com/datapk01.htm
www.3480-3590-data-conversion.com/article-cobol-comp.html
Another numeric representation that is non-printable is binary. Numbers in this format occupy even fewer bytes. Typical is a halfword binary which is two bytes and can contain values from 0 to 32767 (x'0000' - X'7FFF') - the leftmost bit indicates the sign (0 = pos, 1 = neg).
Garry. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| this field is not EBIDIC code? why the hex value is like that? |
| Quote: |
| So when i use the hex on command , what i get? it's not a really hex value? |
If it's running on an IBM mainframe, 99.9% of the time the field is EBCDIC. You can do ASCII on the mainframe but it' is not always easy to do. And when you use HEX ON, what you are seeing is the hexadecimal values for the data (whether the data is ASCII or EBCDIC). Being able to interpret those values into numbers, for example, does require knowing how the various formats are stored internally -- which can best be found in the manuals -- but you're always getting hex values. |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| Thanks all, very appreciated |
|
| Back to top |
|
|
Joe_Song
Currently Banned
New User
Joined: 22 Jan 2008
Posts: 53
Location: china
|
|
|
|
| got another question, how i can know how many digits after the dot? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
This is totally application-dependant.
One application could consider the field to be whole numbers (e.g. stock number), another might have 2 decimal places (e.g. account balance) while another might have 6 decimal places (e.g. exchange rate). There's no way of knowing, looking at raw data, where the decimal place is located.
Garry. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| There's no way of knowing, looking at raw data, where the decimal place is located. |
Typically there is a record layout available that was used to create and subsequently read the data. This layout should clarify the field sizes and decimal positions in the raw data.
| Quote: |
| This goes back to the days when memory was very restricted and disk/tape was expensive. Using this format saved space. |
Also, 2 other reasons to use packed-decimal were because the IBM mainframe has machine instructions to process packed-decimal arithmetic which is exponentially faster than performing calculations using zoned-decimal numbers. Also the assembler instruction (edit) to make numeric data more readable (i.e. 12,332,456.88-) requires packed-decimal input, so even if the program used zoned-decimal fields for accumulators, they would be converted internally wasting more cpu time. |
|
| Back to top |
|
|
|
|
