how are PL/I's fixed decimal numbers stored on disk? 
Author Message
 how are PL/I's fixed decimal numbers stored on disk?

Hello,

Can anyone tell me how fixed decimal, FIXED(9) and FIXED(4,2) fields are
stored on disk by PL/I on OS2.
I think the compiler that wrote the file was made by IBM.
I've gotten as far as: 1 hex nibble per digit + 1 'sign' nibble +
padding on the MSB side to an even
number of nibbles ( I think).  The order and meaning of the bits I find
thorougly incomprehensible
to decode, because I have only a couple of examples of encoded and
decoded numbers.

Thanks.

--
[Luuk van Dijk]



Fri, 04 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?

Quote:
>Hello,
>Can anyone tell me how fixed decimal, FIXED(9) and FIXED(4,2) fields are
>stored on disk by PL/I on OS2.
>I think the compiler that wrote the file was made by IBM.
>I've gotten as far as: 1 hex nibble per digit + 1 'sign' nibble +
>padding on the MSB side to an even
>number of nibbles ( I think).  The order and meaning of the bits I find
>thorougly incomprehensible
>to decode, because I have only a couple of examples of encoded and
>decoded numbers.

On IBM/360, /370, /390, packed decimal is one digit per nybble, in BCD
code, with the sign X'C' for plus, and X'D' for minus.  As input to
decimal operations, X'B' and X'D' are minus, X'A', X'C', X'E', X'F' are
plus.  A sign code in a digit position, or digit code in sign position
is illegal, and will result in a data exception (hardware interruption).

I hope this helps.

-- glen



Fri, 04 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?


Quote:
> Can anyone tell me how fixed decimal, FIXED(9) and FIXED(4,2) fields are
> stored on disk by PL/I on OS2.

Refer to Glen's posting concerning IBM/3x0.

The question was on OS2, i.e. the PC platform.
I am just as curious as Luuk.
I'd be surprised if each digit isn't in BCD code, but Intel's backwords may
have messed up the order of the bytes.

Gunnar.



Fri, 04 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?


Quote:


> > Can anyone tell me how fixed decimal, FIXED(9) and FIXED(4,2) fields are
> > stored on disk by PL/I on OS2.

> Refer to Glen's posting concerning IBM/3x0.

> The question was on OS2, i.e. the PC platform.
> I am just as curious as Luuk.
> I'd be surprised if each digit isn't in BCD code, but Intel's backwords
may
> have messed up the order of the bytes.

The representation on both OS/2 and Windows is bit-identical to that on the
host, including byte order.

FIXED DEC (4,2) is stored as FIXED DEC (5,2), but you should look up the
documentation for the
DEFAULT(EVENDEC) and DEFAULT(NOEVENDEC) options for information on when SIZE
is raised.
(This is for VA PL/I V2.1. I believe Personal PL/I doesn't support this
option)

Quote:

> Gunnar.



Sat, 05 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?
Thanks for the swift answer.

Maybe I should have mentioned that I tried BCD nibbles, but there's A's
and B's and F's all
over the place.  I have the following examples of coded FIXED(1) fields:
hex value
--- -----
1F   1
07   2
1A   3
7C   4
22   7
C5   8
FE   9

Unfortunately, this doesn't work for higher order digits.  I thougt
maybe significant
bits are interleaved with garbage padding bits or so.

What I have is a file presumably written by a PL/1 program, and a
hardcopy of a declaration
section in PL/1 source.  The PIC'(7)9' AND PIC'(26)X' fields all work
out well, they're plain ascii.
But these fixed(x) and fixed(x,y) are mysteries, apart from the fact
that they're 1+x nibbles, padded
high order to an integer number of bytes.

On top of that, most fixed(9) fields have been used to encode dates like
19870502.  I've got a couple of
examples of these too:

hex             'date'
------------   --------
016B D71A C5 = 19270208
0171 0026 1F = 19720101
0171 20A6 1F = 19840411
0171 D726 22 = 19870507
0171 D726 C5 = 19870508
0171 D72D 07 = 19870602
0172 1AD7 1F = 19920701

These examples lead me to believe that I got the byte order right.
On top of that there are a couple of fields that encode a month rather
than a date and should be
decoded as follows
hex             'date'
------------   --------
0171 D79E FE = 19870599
0171 D7AC FE = 19870699
0172 1A60 FE = 19920799

For all these dates, the last digit is consistent with what I got from
the fixed(1) examples, but the rest I can't figure out.

A clue anyone?

Luuk van Dijk



Sat, 05 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?


Quote:
>I have the following examples of coded FIXED(1) fields:
> hex value
> --- -----
> 1F   1
> 07   2
> 1A   3
> 7C   4
> 22   7
> C5   8
> FE   9

I think that you didn't told us the whole story, or maybe you didn't know.
I am quite certain that this is a file transferred from a mainframe using
EBCDIC to ASCII translation (text).  That doesn't work for packed decimal
fields.

"FIXED(1) DECIMAL" in PL/I is like "PIC 9 COMP-3" in Cobol and "PL1" in
assembler.
In IBM/390 hardware it is described as "packed decimal".

The number 19270208 is represented as hex 01 92 70 20 8F (padded to bytes)
When transferred to PC as text each byte is translated.

Your example of FIXED(1) fields contained 1 2 3 4 7 8 9
which will be represented as hex 1F 2F 3F 4F 7F 8F 9F
and after transfer to PC as text with translation becomes 1F 07 1A 21 22 F1
5D here.
The difference from your results is probably due to different codepages
language differences).

If you want to transfer packed decimal data from mainframe to PC, then
either turn off translation (by not specifying ASCII), or convert to
character format before transfer.

Hope this helps.

Gunnar.



Sat, 05 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?

Quote:

> I think that you didn't told us the whole story, or maybe you didn't know.
> I am quite certain that this is a file transferred from a mainframe using
> EBCDIC to ASCII translation (text).  That doesn't work for packed decimal
> fields.

Fantastic, thanks for the clue. The people that gave me the file didn't
tell me that.
Probably they didn't know either.  I'll just write something to map the
bytes back.
( I presume nothing is lost in transliteration from ebcdic->ascii, ie.
it is reversible)

Thanks again!
Luuk



Sun, 06 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?


Quote:
> I'll just write something to map the
> bytes back.
> ( I presume nothing is lost in transliteration from ebcdic->ascii, ie.
> it is reversible)

Unfortunately that may be not so.

If transferred as text, usually the options ASCII and CRLF apply.
That means EBCDIC to ASCII translation of each byte, and appending 0D 0A to
each record (presenting them as lines).  The translation table includes
translating 25 to 0A, so that one. at least, will conflict with the line
ending.  Also, 0D goes straight to 0D.  And trailing 40's in a record will
be stripped off.

To be certain, you should have both ASCII and CRLF turned off when
transferring, and interpret the file you get (which now is continuous, not
broken into lines).  This would be difficult if the original file had
variable-length records.

If the file has been transferred with both ASCII and CRLF you may have a
problem.

Gunnar.



Sun, 06 Jan 2002 03:00:00 GMT  
 how are PL/I's fixed decimal numbers stored on disk?

Quote:

> If the file has been transferred with both ASCII and CRLF you may have a
> problem.

I did. It's an unreadable mess. Thanks for the advice,
End of this episode.

Luuk van Dijk



Mon, 07 Jan 2002 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. CLIPWKS and fixed number of decimals

2. Fixed point math in asm -HELP ME I 'am dying here

3. fixed point vs fixed decimal

4. It's not PL/1, it's PL/I

5. It's not PL/1, it's PL/I

6. exponentiation of fixed point or decimal

7. Easytrieve - handing fixed decimal point

8. How to store numeric array in disk

9. storing data on disk (for pc)

10. How can I store data on disk?

11. best CL type for fixed decimal values

12. Printing floats as fixed decimal values

 

 
Powered by phpBB® Forum Software