"Packed decimal" format depends on the machine it came from. This may not be the old IBM 360/370 Packed Decimal, but based on your description: Each digit is stored as a "nibble", four bits of a byte with a sign byte preceeding them. If all the numbers are 6 bytes long as in your example, then if you read in six bytes into a string variable S, you could decode the value into Y as:

Y = 0
for  I = 2 to 6
   C = asc(substr(S,I,1))
   Y = (Y * 10 + bitrshift(C,4)) * 10 + bitand(C,255)
endfor
Y = Y / 100
if  left(S,1) = chr(01)
   Y = - Y
endif

There may be a more elegant solution, but that one should work for brute force.

...Jim
Long-standing member of BPA (Bit Pickers Anonymous)

>>I don't know what format it's but it's not Cobol Comp-3 packed format. See http://digilander.libero.it/foxes/Packed_Decimal.htm
>
>I understand that now :)
>That is one of the pages I got from Google today.
>
>I called the creator of the data and they shed some light. They are restricting numbers and "simplifying" it a bit. The amounts are in dollars, and I misunderstood, as they tell me will have two decimals.
>

>02 00 00 00 31 05
>

>The above example in Hex means positive (the '02') then the next five bytes the amount with two decimals. As they just told me on the phone, there is no conversion required. This example means $31.05
>
>The 5-byte compressed format from their mainframe means I can hold 10 bytes uncompressed. That is 99,999,999.99 as the max amount the system supports (commas and decimal point added for clarity).
>
>My job now is to translate each string as it comes into a dollar amount I can use. So, I guess I would have to read byte-by-byte, from left to right with CHR() and use the number returned straight as it is.