Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

Author Message
Joe_Song
Currently Banned

New User

Joined: 22 Jan 2008
Posts: 53
Location: china

 Posted: Thu Jan 29, 2009 2:09 pm    Post subject: in TSO, view a dataset, when use hex on function 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: 1703
Location: Australia

 Posted: Thu Jan 29, 2009 2:22 pm    Post subject: 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    Post subject: not sure i think so, or what i understood is wrong.
Garry Carroll

Senior Member

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

 Posted: Thu Jan 29, 2009 3:01 pm    Post subject: Suggest you have a look at http://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    Post subject: Another question 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: 1092
Location: Dublin, Ireland

 Posted: Thu Jan 29, 2009 5:18 pm    Post subject: 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    Post subject: The sum field is fix dec attribute 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    Post subject: 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: 1092
Location: Dublin, Ireland

Posted: Thu Jan 29, 2009 5:48 pm    Post subject:

 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    Post subject: Could you give me some reference about this ? very appreciate.
Garry Carroll

Senior Member

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

 Posted: Thu Jan 29, 2009 5:59 pm    Post subject: Try Googling 'packed decimal'. There are many references, e.g. http://www.simotime.com/datapk01.htm http://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: 8567
Location: Dubuque, Iowa, USA

Posted: Thu Jan 29, 2009 6:08 pm    Post subject:

 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    Post subject: 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    Post subject: got another question, how i can know how many digits after the dot?
Garry Carroll

Senior Member

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

 Posted: Thu Jan 29, 2009 7:29 pm    Post subject: 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: 19254
Location: Inside the Matrix

Posted: Thu Jan 29, 2009 10:12 pm    Post subject:

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.
 All times are GMT + 6 Hours
 Page 1 of 1

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics DB2 - row_number function - Need 1st ... Q5P418 DB2 5 Wed Sep 09, 2020 8:35 am Fetch the Dataset names from inside m... kalyan94 TSO/ISPF 18 Wed Jun 17, 2020 2:06 pm How to Assign a Function key to Mainf... upendrasri TSO/ISPF 4 Sat May 30, 2020 9:03 pm what is the DSORG(Datset orgnisation)... sandeep prajapati JCL & VSAM 8 Mon Mar 30, 2020 9:09 pm IEBGENER is not Creating Member in PD... sandeep prajapati JCL & VSAM 7 Mon Mar 23, 2020 11:50 pm

 © 2003-2020 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us