[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3520
  • Last Modified:

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
0
jimsweb
Asked:
jimsweb
  • 7
  • 5
  • 4
  • +1
3 Solutions
 
MurpheyCommented:
Hi jimsweb,

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
0
 
tliottaCommented:
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
0
 
giltjrCommented:
Do you really want hex or do you really want packed decmial?
0
Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

 
jimswebAuthor Commented:
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


    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

Open in new window


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..?

0
 
MurpheyCommented:
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

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

Open in new window


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





0
 
giltjrCommented:
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'
0
 
MurpheyCommented:
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.
0
 
giltjrCommented:
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.
0
 
MurpheyCommented:
Yes your description / assumption is right, what is the problem?


0
 
tliottaCommented:
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
0
 
MurpheyCommented:
"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 :).

0
 
giltjrCommented:
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.  
0
 
tliottaCommented:
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
0
 
jimswebAuthor Commented:
My apologies for the late reply and confusing question..

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

Open in new window


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...?
0
 
MurpheyCommented:
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
0
 
giltjrCommented:
What are you attempting to do with the output?  Is this printed in a batch job report, displayed on a 3270 terminal?

You can covert from ZD to character in Cobol, why not just do that?

Have you read the DFSort manual?  I am faily sure you can convert from ZD to CH (ZD and CH are both DFSort options for identifying what form the data should be in).
0
 
MurpheyCommented:
I found what you looking for (I Think)

http://ibmmainframes.com/about39503-15.html
0
 
tliottaCommented:
Yes, it's not clear why DFSORT is involved at all if this is really a COBOL problem. Is COBOL actually involved here? Why is DFSORT involved? Why is it necessary to convert to a different data definition since zoned is a native format? Why not just use zoned? That is, what is the problem?

Are you needing to send the file to a different system? Is a program (COBOL?) having a problem? What problem? Do you simply need to know how to sort signed zoned fields? Conversion isn't needed if you just want to sort. What purpose is driving a conversion of data types? Maybe all you need is a little background on handling signed zoned fields.

Tom
0
 
jimswebAuthor Commented:
You experts were right. I just had to use ZD to char conversion.

0
 
jimswebAuthor Commented:
Thank you all
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 7
  • 5
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now