xenium
asked on
How does packed decimal translate to ASCII?
Hi,
Simple follow-up question.
If i take the decimal number 98 and pack it into 1 byte i understand that:
9 becomes the firstpart of the byte (1st nibble)
8 becomes the second part of the byte (2nd nibble)
What will the ascii value of this byte be? How is this determined based on the codepage? (i know nothing of codepage)
Can you give me 2 examples of how this number would be translated?
If nothing else the complexity might make me drop the topic, but i'm stubborn.
Cheers
Simple follow-up question.
If i take the decimal number 98 and pack it into 1 byte i understand that:
9 becomes the firstpart of the byte (1st nibble)
8 becomes the second part of the byte (2nd nibble)
What will the ascii value of this byte be? How is this determined based on the codepage? (i know nothing of codepage)
Can you give me 2 examples of how this number would be translated?
If nothing else the complexity might make me drop the topic, but i'm stubborn.
Cheers
xenium:
Packed data is a form of BCD (Binary Coded Decimal). While a more pure form of BCD can 'pack' the value 98 into a single byte, the packed-decimal form would usually require two bytes. This is because the last nibble will contain the sign of the value and therefore move each decimal digit one nibble to the left. The high-order nibble would be set to a leading '0'. The result would be:
08
9F
The first byte is x'09' and the second byte is x'8F'. Together they're x'098F'. I used a x'F' as the sign nibble because there is no indication of positive/negative. The x'F' essentially indicates an absolute value; effectively it's a positive number. More precisely, a x'C' is designated as positive and x'D' is negative.
The value 98 is two digits and takes up two packed bytes. Not particularly an efficient use of the space. But the two packed bytes can hold a range of values from -999 to +999. If 16 bytes were used instead of two bytes, the range of values would be -9(31) through +9(31) where the (31) represents the number of digits. Sixteen bytes is 32 nibbles; minus a single nibble for the sign gives 31 digits. Each digit holds a value from 0 through 9.
Now, if you took those same 16 bytes and used them to store binary integers, you could have a larger range of values; but you run into a problem. There is no precise way to represent decimal _fractions_ in fields formatted as binary integers. Packed-decimal becomes particularly useful when _exact_ representations of decimal fractions is necessary. Most common in business is the representation of fractions of a dollar (cents).
The field definition of packed-decimal then has three general parts: (1) number of total digits, (2) signed/unsigned, and (3) the number of assumed decimal fraction digits. For a monetary field of dollars/cents, the assumed number of fractional digits would usually be '2'.
CPUs that handle packed-decimal have often had basic BCD processing modes. That tends to make them more efficient for business programming where money calculations are prevalent.
Okay, now 'conversion to ASCII'.
Well, usually there is no conversion to ASCII of packed-decimal data. Conversion to ASCII is generally for text data and a packed-decimal field would be considered binary/non-text data. In order to convert to ASCII, you would want to convert the packed data to characters first.
So, assuming a packed-decimal field of three digits and a single assumed decimal position and holding the value x'098D', then the character representation would be [9.8-], i.e. a (negative 9.8)... without the square brackets of course.
An ASCII representation of text [9.8-] is the same as it always is.
In OS/400, one way of handling this conversion more or less automatically is through the use of the CPYTOIMPF (Copy to Import File) command. This command can take a DB2 database file and do the conversions needed to create an ASCII text version. Various command parameters describe the characteristics of the resulting, e.g., whether or not a .CSV format should be created. That version would commonly then be FTPd or otherwise copied to an ASCII system.
Tom
Packed data is a form of BCD (Binary Coded Decimal). While a more pure form of BCD can 'pack' the value 98 into a single byte, the packed-decimal form would usually require two bytes. This is because the last nibble will contain the sign of the value and therefore move each decimal digit one nibble to the left. The high-order nibble would be set to a leading '0'. The result would be:
08
9F
The first byte is x'09' and the second byte is x'8F'. Together they're x'098F'. I used a x'F' as the sign nibble because there is no indication of positive/negative. The x'F' essentially indicates an absolute value; effectively it's a positive number. More precisely, a x'C' is designated as positive and x'D' is negative.
The value 98 is two digits and takes up two packed bytes. Not particularly an efficient use of the space. But the two packed bytes can hold a range of values from -999 to +999. If 16 bytes were used instead of two bytes, the range of values would be -9(31) through +9(31) where the (31) represents the number of digits. Sixteen bytes is 32 nibbles; minus a single nibble for the sign gives 31 digits. Each digit holds a value from 0 through 9.
Now, if you took those same 16 bytes and used them to store binary integers, you could have a larger range of values; but you run into a problem. There is no precise way to represent decimal _fractions_ in fields formatted as binary integers. Packed-decimal becomes particularly useful when _exact_ representations of decimal fractions is necessary. Most common in business is the representation of fractions of a dollar (cents).
The field definition of packed-decimal then has three general parts: (1) number of total digits, (2) signed/unsigned, and (3) the number of assumed decimal fraction digits. For a monetary field of dollars/cents, the assumed number of fractional digits would usually be '2'.
CPUs that handle packed-decimal have often had basic BCD processing modes. That tends to make them more efficient for business programming where money calculations are prevalent.
Okay, now 'conversion to ASCII'.
Well, usually there is no conversion to ASCII of packed-decimal data. Conversion to ASCII is generally for text data and a packed-decimal field would be considered binary/non-text data. In order to convert to ASCII, you would want to convert the packed data to characters first.
So, assuming a packed-decimal field of three digits and a single assumed decimal position and holding the value x'098D', then the character representation would be [9.8-], i.e. a (negative 9.8)... without the square brackets of course.
An ASCII representation of text [9.8-] is the same as it always is.
In OS/400, one way of handling this conversion more or less automatically is through the use of the CPYTOIMPF (Copy to Import File) command. This command can take a DB2 database file and do the conversions needed to create an ASCII text version. Various command parameters describe the characteristics of the resulting, e.g., whether or not a .CSV format should be created. That version would commonly then be FTPd or otherwise copied to an ASCII system.
Tom
ASKER
Hi tliotta,
Wow thanks for the explanation. I'm missing just one step:
Imagine I download this file to a PC without unpacking. I read the file byte by byte - what 2 ascii values will I see for the example [9.8-]. For sure I do not see [9.8-]. In understand it depends on the code page or something that presumably effects a translation during the download.
Cheers
Wow thanks for the explanation. I'm missing just one step:
Imagine I download this file to a PC without unpacking. I read the file byte by byte - what 2 ascii values will I see for the example [9.8-]. For sure I do not see [9.8-]. In understand it depends on the code page or something that presumably effects a translation during the download.
Cheers
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well you've impressed the hell out of me - i'll keep this for reference when I'm less employed or have some side-resource, but for now I'll put it on hold...as i said:
"If nothing else the complexity might make me drop the topic"
Many thanks
"If nothing else the complexity might make me drop the topic"
Many thanks
xenium:
I probably know a few percent more than the average developer who is involved in multiple file transfers. But I am far from certain ground.
The whole MS/Unicode and IBM/CCSID (and both are very much the same if you use them the same) deal is all because of the rapid rise of the internet. Rapid info transmission across language boundaries forces many of us to grapple with it without an education background for it. (It sure wasn't any college course that I had.)
For the most part, you do it just like you did. Find someone who will answer questions.
Where possible, you find tools such as the OS/400 CPYTOIMPF command to do it for you. Under many circumstances, you might create an SQL VIEW that will provide numeric<->character translation and then FTP the view rather than the physical table. In short, you find whatever works and use it.
Tom
I probably know a few percent more than the average developer who is involved in multiple file transfers. But I am far from certain ground.
The whole MS/Unicode and IBM/CCSID (and both are very much the same if you use them the same) deal is all because of the rapid rise of the internet. Rapid info transmission across language boundaries forces many of us to grapple with it without an education background for it. (It sure wasn't any college course that I had.)
For the most part, you do it just like you did. Find someone who will answer questions.
Where possible, you find tools such as the OS/400 CPYTOIMPF command to do it for you. Under many circumstances, you might create an SQL VIEW that will provide numeric<->character translation and then FTP the view rather than the physical table. In short, you find whatever works and use it.
Tom
I just want to say that I was very impressed with Tom's explanation too. I've been all over the internet (including Experts pages) and could barely understand some of the explanations for the Packed field. I need to write some code to unpack these fields - and because I didn't truly understand how they were created.. I couldn't quite understand the explanations of how to unpack them.. But Tom's 'solution' was amazing!! (You don't have to be an expert to understand him :-)
ASKER
Note: question is for mainframe packed data, but i think the logic is generic, or is it?
Anyone suggest a better topic area for this?