Date:         Mon, 15 Sep 2003 22:43:15 +0200
Reply-To:     Tine Andersen <tine.andersen@POST3.TELE.DK.INVALID>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Tine Andersen <tine.andersen@POST3.TELE.DK.INVALID>
Organization: Customer of Tiscali A/S
Subject:      Re: Packed Decimal Dilemma

"Dan T Keating" <keatingd@WASHPOST.COM> skrev i en meddelelse
news:OF81F1AE4F.B0FDD060-ON85256DA2.0068899C@washpost.com...
>       I received a data dump from an IBM DB2 application that
automatically
> turned the text into ASCII but left the numeric fields as packed decimals.
> I'm getting contradictory signals on the packed decimal format.
>        I'm having no trouble reading the character fields as per the data
> layout, and the files were pk-zipped and FTP'd directly from the
mainframe,
> so I don't believe anyone trashed the fields by opening the data and
saving
> it as text.
>       The numeric fields are described as S9(09)V9(02) COMP-3.
>       To me, that means I should use S370FPD5.2 informat.  The layout
> indicates that the field occupies six positions. When I view it in a text
> editor, I can see the text in positions before and after the unprintable
> characters that occupy the six positions for the number.
>       So I' tried reading it with S370FPD6.2.  Still garbage.
>
>       Here's a part of the input statement
>       @40 GRS_AMT_VOUCHERED s370FPD6.2  @46 NET_AMT_VOUCHERED s370FPD6.2 @
> 52 FC_GRS_AMT_VOUCHER s370FPD6.2 @58 FC_NET_AMT_VOUCHER s370FPD6.2
>
>       Here's a snippet of the corresponding log
> NOTE: Invalid data for GRS_AMT_VOUCHERED in line 2 40-45.
> NOTE: Invalid data for NET_AMT_VOUCHERED in line 2 46-51.
> NOTE: Invalid data for FC_NET_AMT_VOUCHER in line 2 58-63.
> RULE:
> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----
+----8----+---
>
> 2   CHAR  AA0D9000005 AA0     19981210
> DVVTP...юд....юд..........юд.19981202FREDDIE OWENS
>     ZONE
>
443433333332443222223333333322222245555000CC1000CC1000000000CC13333333345444
442454452222
>     NUMR
>
11049000005011000000199812100000004664000104C00104C00000C00104C1998120262544
950F75E30000
>
>       Note that it read a zero for the third number above
> (fc_grs_amt_voucher in positions 52-57), which shows all 0's in the NUMR
> line.  Following that NUMR line, the value from positions 40-45 should be
> 00104C, which is repeated in positions 46-51.  And C would mean a positive
> number, right? So why isn't it reading correctly?
>
>       I'm sure this makes much more sense to the jocks out there who are
> used to moving data in and out of mainframe systems. Any help greatfully
> appreciated. TIA.
>
> Dan

When I read data from a (mainframe) db2 database with sas (on a mainframe) I
use plain PD6.2.  Have you tried 5.2 but with the same positions as with
6.2? (I'm guessing here but until you have something better you might try)
Like in

      @40 GRS_AMT_VOUCHERED s370FPD5.2
      @46 NET_AMT_VOUCHERED s370FPD5.2
      @52 FC_GRS_AMT_VOUCHER s370FPD5.2
      @58 FC_NET_AMT_VOUCHER s370FPD5.2

And try without the s370f.

Tine