jimsweb
asked on
convert numbers to hex format in DFSort
Can anyone help me to write a technique that can convert numbers like -122.68 to hex format..?
Preferably in DFSort. Any help in this regard is highly appreciated
Preferably in DFSort. Any help in this regard is highly appreciated
Murph is generally right. And more info is needed.
Since this showed up in both AS/400 and mainframe areas, it's likely that the basic encoding scheme is EBCDIC. Within that, there are three reasonable alternatives -- zoned, packed and a minor variation of packed (straight BCD). If numbers are negative, then I think anything but zoned and packed are unlikely.
In order to be certain, we'd need to know the field definition. We'd need to know zoned or pack, plus "scale" and "precision". I.e., how many digits are possible in the largest number that can be stored in the field and how many fractional decimal positions are allowed. (It looks reasonable that two decimal fraction positions are defined.
Tom
Since this showed up in both AS/400 and mainframe areas, it's likely that the basic encoding scheme is EBCDIC. Within that, there are three reasonable alternatives -- zoned, packed and a minor variation of packed (straight BCD). If numbers are negative, then I think anything but zoned and packed are unlikely.
In order to be certain, we'd need to know the field definition. We'd need to know zoned or pack, plus "scale" and "precision". I.e., how many digits are possible in the largest number that can be stored in the field and how many fractional decimal positions are allowed. (It looks reasonable that two decimal fraction positions are defined.
Tom
Do you really want hex or do you really want packed decmial?
ASKER
Thank you all for your invaluable inputs. I am really a newbie in Mainframe area.
I think I need to explain the situation in beeter way. I was working with a cobol program recently and it was handling packed decimals. So obviously, i was hitting on values which are not readable. So thought of making a Sort card that can convert packed decimals to readabl format and vice versa.
Please refer to this page. http://www.3480-3590-data-conversion.com/article-signed-fields.html
Here the +120 is represented as 12{
where, '{' indicates a positive number. And I assume that this should be the internal storage technique for a mainframe.
Is it possible for me to convert the above stffs to a redable format and vice versa..?
I think I need to explain the situation in beeter way. I was working with a cobol program recently and it was handling packed decimals. So obviously, i was hitting on values which are not readable. So thought of making a Sort card that can convert packed decimals to readabl format and vice versa.
Please refer to this page. http://www.3480-3590-data-conversion.com/article-signed-fields.html
Value EBCDIC hex Characters ASCII hex
+120 F1, F2, C0 "12{" 31, 32, 7B
+121 F1, F2, C1 "12A" 31, 32, 41
+122 F1, F2, C2 "12B" 31, 32, 42
+123 F1, F2, C3 "12C" 31, 32, 43
Here the +120 is represented as 12{
where, '{' indicates a positive number. And I assume that this should be the internal storage technique for a mainframe.
Is it possible for me to convert the above stffs to a redable format and vice versa..?
I understand, but packed is not the same as hex
in packed format 2 digitd ware stored in one character and the sign in the last character of the row.
It don't need conversion as you read it as packed, evry program will do the translation by it self,
Example a field 7 positions value 12345
The only thing you have to do to make it readable is to place it in a zoned-numeric field.
If you use an export (the right way) then the conversion is done automatically.
you can do the export by system commands or even bij the Excel transfer function.
You placed this question in the mainframe and as/400 zones.
If it is an AS/400 you can copy the file to an CSV or tab delimited file by using the CPYTOIMPF command
Let us know if you need more info
in packed format 2 digitd ware stored in one character and the sign in the last character of the row.
It don't need conversion as you read it as packed, evry program will do the translation by it self,
Example a field 7 positions value 12345
stored as zoned looks like this
FFFFFFF
0012345
Stored as packed looks like this
0135
024F
Where the F in the last positon is the positive sign if the value is negative the sign = D
0135
024D
The only thing you have to do to make it readable is to place it in a zoned-numeric field.
If you use an export (the right way) then the conversion is done automatically.
you can do the export by system commands or even bij the Excel transfer function.
You placed this question in the mainframe and as/400 zones.
If it is an AS/400 you can copy the file to an CSV or tab delimited file by using the CPYTOIMPF command
Let us know if you need more info
O.K, but x'F1F2C0' is not packed decmial. That is a signed numeric field, also called zone decimal.
If you have access to DFSORT it is data type of ZD, which you should be able to convert to CH using DFSORT.
The difference
120 = x'F1F2F0' in character (CH) forma. In CH format there is no positive or negative.
+120 = x'F1F2C0' in ZD format. If it were negative, the the X'C0' would be come x'D0'
+120 = X'120C' in packed decimal. If it were negative it would become x'120D'
If you have access to DFSORT it is data type of ZD, which you should be able to convert to CH using DFSORT.
The difference
120 = x'F1F2F0' in character (CH) forma. In CH format there is no positive or negative.
+120 = x'F1F2C0' in ZD format. If it were negative, the the X'C0' would be come x'D0'
+120 = X'120C' in packed decimal. If it were negative it would become x'120D'
Yes you are correct,
but if you use a tool within the 400 or mainframe, this tool will solve the difference until you try to read it as character.
but if you use a tool within the 400 or mainframe, this tool will solve the difference until you try to read it as character.
If you convert it from signed decimal (a.k.a. zoned decimal) to normal character, then when you transfer the file to a ASCII system everything will be fine. That is assuming the transfer process is doing a EBCDIC to ASCII conversion:
x'F1F1C0' -- from ZD to CH will become --> x'F1F2F0' -- from EBCDIC CH to ASCII CH will be come --> x'313230'
Although we do use ZD, we do use packed decimal and we do this type of conversion all of the time. Our custom programs convert from PD to CH. Then our file transfer processes do EBCDIC to ASCII.
x'F1F1C0' -- from ZD to CH will become --> x'F1F2F0' -- from EBCDIC CH to ASCII CH will be come --> x'313230'
Although we do use ZD, we do use packed decimal and we do this type of conversion all of the time. Our custom programs convert from PD to CH. Then our file transfer processes do EBCDIC to ASCII.
Yes your description / assumption is right, what is the problem?
I was working with a cobol program recently and it was handling packed decimals. So obviously, i was hitting on values which are not readable.
To me, that implies that a COBOL program on the mainframe was where the problem appeared. (DFSORT implies that an AS/400 is not involved. AS/400s are not mainframes.)
If this is a mainframe programming problem, then ASCII wouldn't seem to be relevant at all. It would seem more likely that something along the lines of a data format exception happened while COBOL was processing a file.
As Murph asked last __ "What is the problem?"
What process is running? Where is the process running? What errors appear? What is the business problem that needs to be resolved?
Tom
To me, that implies that a COBOL program on the mainframe was where the problem appeared. (DFSORT implies that an AS/400 is not involved. AS/400s are not mainframes.)
If this is a mainframe programming problem, then ASCII wouldn't seem to be relevant at all. It would seem more likely that something along the lines of a data format exception happened while COBOL was processing a file.
As Murph asked last __ "What is the problem?"
What process is running? Where is the process running? What errors appear? What is the business problem that needs to be resolved?
Tom
"AS/400s are not mainframes."
Yes I'm aware of that, You are also and all people working on a mainframe also,
but everybody that think that a big-tower is a big computer are not :).
Yes I'm aware of that, You are also and all people working on a mainframe also,
but everybody that think that a big-tower is a big computer are not :).
I guess the author needs to describe what problem he is having. I was assuming he was tranfering the data to a non-EBCDIC host and having issues. The x'F1F2' would translate (assuming a text file transfer), but the x'C0' would have problems.
Now it is possible he is attempting to try and display the data on a 3270 terminal, in which case it would not work.
Now it is possible he is attempting to try and display the data on a 3270 terminal, in which case it would not work.
Simply defining it as zoned decimal in COBOL should supply the appropriate value in the program. But we need to know what the actual problem is in order to suggest an appropriate resolution.
Tom
Tom
ASKER
My apologies for the late reply and confusing question..
it think one simple solution can help me alot.
If I am getting monetary values like "12{" or "12A";
is there any technique in DFSORT to covert these values to +120; and +121 etc...?
it think one simple solution can help me alot.
Value EBCDIC hex Characters ASCII hex
+120 F1, F2, C0 "12{" 31, 32, 7B
+121 F1, F2, C1 "12A" 31, 32, 41
+122 F1, F2, C2 "12B" 31, 32, 42
+123 F1, F2, C3 "12C" 31, 32, 43
If I am getting monetary values like "12{" or "12A";
is there any technique in DFSORT to covert these values to +120; and +121 etc...?
If it helps, you can seton the bit 2 and 3 of the last digit to make it positive,
If there is a diference between the original value and the new value, th number was negative:
Because for the last digit the rule is:
Binary(packed(-1)) : 11110001
Binary(packed(-1)) : 11000001
Binary(packed(+9)) : 11111001
Binary(packed(-9)) : 11001001
Not my preferable solution, but if you don't have the posibilities to use packed to decimal, this will work
Good Luck
Murphey
If there is a diference between the original value and the new value, th number was negative:
Because for the last digit the rule is:
Binary(packed(-1)) : 11110001
Binary(packed(-1)) : 11000001
Binary(packed(+9)) : 11111001
Binary(packed(-9)) : 11001001
Not my preferable solution, but if you don't have the posibilities to use packed to decimal, this will work
Good Luck
Murphey
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
You experts were right. I just had to use ZD to char conversion.
ASKER
Thank you all
That will be difficult or better impossible, Hex values can only be integer positive values.
so in your example -122.68 will give an unpredictable result.
Unless, you are willing to mult the value with 100 or 1000 or wharever you need to get rid of the decimals,
and store the +/- in a seperate position(field).
tell me (us) more about the purpose.
Succes,
Murph