Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

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

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 2:09 pm    Post subject: in TSO, view a dataset, when use hex on function
Reply with quote

example:
3796100502
FFFFFFFFFFC
3796100502

you can see the hex value F3 for 3.

why it's F3, not 03?

confusion....
Back to top
View user's profile Send private message

gcicchet

Senior Member


Joined: 28 Jul 2006
Posts: 1703
Location: Australia

PostPosted: Thu Jan 29, 2009 2:22 pm    Post subject:
Reply with quote

Hi,

are you saing that HEX ON is not telling you the truth ?



Gerry
Back to top
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 2:24 pm    Post subject: not sure
Reply with quote

i think so, or what i understood is wrong.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jan 29, 2009 3:01 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 5:07 pm    Post subject: Another question
Reply with quote

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
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jan 29, 2009 5:18 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 5:19 pm    Post subject: The sum field is fix dec attribute
Reply with quote

this field is not EBIDIC code? why the hex value is like that?
Back to top
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 5:23 pm    Post subject:
Reply with quote

So when i use the hex on command , what i get? it's not a really hex value?
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jan 29, 2009 5:48 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 5:51 pm    Post subject:
Reply with quote

Could you give me some reference about this ? very appreciate.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jan 29, 2009 5:59 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Jan 29, 2009 6:08 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 6:12 pm    Post subject:
Reply with quote

Thanks all, very appreciated
Back to top
View user's profile Send private message
Joe_Song
Currently Banned

New User


Joined: 22 Jan 2008
Posts: 53
Location: china

PostPosted: Thu Jan 29, 2009 7:20 pm    Post subject:
Reply with quote

got another question, how i can know how many digits after the dot?
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jan 29, 2009 7:29 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Thu Jan 29, 2009 10:12 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts FTP - JCL failed while passing FTP co... Suneetha1612 JCL & VSAM 12 Wed Nov 16, 2016 7:33 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Check System time(Minute) Using TIME1... balaji81_k DFSORT/ICETOOL 5 Fri Nov 11, 2016 10:53 am
No new posts To trim spaces in a pipe delimited da... Nish84 COBOL Programming 16 Mon Oct 10, 2016 1:54 pm
No new posts Strange EXEC function call in z/VM Willy Jensen CLIST & REXX 3 Wed Oct 05, 2016 2:07 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us