# in TSO, view a dataset, when use hex on function

Author Message
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 2:09 pm example: 3796100502 FFFFFFFFFFC 3796100502 you can see the hex value F3 for 3. why it's F3, not 03? confusion....
gcicchet

Senior Member

Joined: 28 Jul 2006
Posts: 1702
Location: Australia

 Posted: Thu Jan 29, 2009 2:22 pm Hi, are you saing that HEX ON is not telling you the truth ? Gerry
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 2:24 pm i think so, or what i understood is wrong.
Garry Carroll

Senior Member

Joined: 08 May 2006
Posts: 1175
Location: Dublin, Ireland

 Posted: Thu Jan 29, 2009 3:01 pm Suggest you have a look at publibz.boulder.ibm.com/epubs/pdf/dz9zs001.pdf and learn what the hex representation of characters is. Garry.
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 5:07 pm 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?
Garry Carroll

Senior Member

Joined: 08 May 2006
Posts: 1175
Location: Dublin, Ireland

 Posted: Thu Jan 29, 2009 5:18 pm 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.
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 5:19 pm this field is not EBIDIC code? why the hex value is like that?
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 5:23 pm So when i use the hex on command , what i get? it's not a really hex value?
Garry Carroll

Senior Member

Joined: 08 May 2006
Posts: 1175
Location: Dublin, Ireland

Posted: Thu Jan 29, 2009 5:48 pm

 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.
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 5:51 pm Could you give me some reference about this ? very appreciate.
Garry Carroll

Senior Member

Joined: 08 May 2006
Posts: 1175
Location: Dublin, Ireland

 Posted: Thu Jan 29, 2009 5:59 pm 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.
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8651
Location: Dubuque, Iowa, USA

Posted: Thu Jan 29, 2009 6:08 pm

 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.
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 6:12 pm Thanks all, very appreciated
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 7:20 pm got another question, how i can know how many digits after the dot?
Garry Carroll

Senior Member

Joined: 08 May 2006
Posts: 1175
Location: Dublin, Ireland

 Posted: Thu Jan 29, 2009 7:29 pm 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.
dick scherrer

Moderator Emeritus

Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

Posted: Thu Jan 29, 2009 10:12 pm

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.
 View Bookmarks All times are GMT + 6 Hours

 Topic Forum Replies Similar Topics Repeat a DD line- comment and insert ... CA Products 3 Dataset size increase on adding 1 byt... DFSORT/ICETOOL 8 REXX - Dataset checking in a do forev... CLIST & REXX 6 FUNCTION NUMVAL problem COBOL Programming 6 Adding space to a dataset - getting D37 ABENDS & Debugging 10
Search our Forums:

 IBMMainframes.com is not an official and/or affiliated with IBM® in anyway Board Rules | FAQ | Downloads | Wiki | SiteMap | Contact Us