| Date: | Thu, 21 Oct 2004 12:21:39 -0400 |
| Reply-To: | sashole@bellsouth.net |
| Sender: | "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU> |
| From: | "Paul M. Dorfman" <sashole@BELLSOUTH.NET> |
| Organization: | Sashole of Florida |
| Subject: | Re: Unsigned Packed Data - How to Read |
|
| In-Reply-To: | <7730B3FE2184A5499A4A8601F598BB1B073514DA@ALPMLVEM01.e2k.ad.ge.com> |
| Content-Type: | text/plain; charset="us-ascii" |
Tom,
Two things. First, from your
13000013510190
24100024605038
(I assume hex) representation of 1234010000001234561005109308, it appears
that the datum is stored as if the PK14. informat. It is used to read packed
decimal data with NO nibble containing a sign at all (which is not exatly
the same as Unsigned packed-decimal, where the lowest nibble is F).
Second, there is a caveat. PK will read the data, but as you know all too
well, SAS cannot store such a number in a numeric variable exactly. But
since this is an account number, it MUST be stored exactly, which, simply
put, bars you from using ANY numeric informat.
For me the simplest solution would be to keep the account just the way it
is, that is read it as $char14. This way, you do not lose any account info.
If, however, you would like to unroll the packed number into a 28-byte digit
string, it can be done by reading pieces of the datum that do fit in the SAS
integer numeric precision, then sticking them together to form the string
(the following assumes tha ta numeric variable N contains the starting
column):
Input @n s1 pk5. @(n+5) s2 pk5. @(n+10) s3 pk4. ;
acct_no_28 = put (s1, z10.) || put (s2, z10.) || put (s3, z8.) ;
HTH.
Kind regards,
----------------
Paul M. Dorfman
Jacksonville, FL
----------------
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On
> Behalf Of Mendicino, Thomas E (GE Consumer Finance)
> Sent: Thursday, October 21, 2004 11:14 AM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Unsigned Packed Data - How to Read
> Importance: High
>
> We need to read in the following file but are not having
> success with any of the standard informats. Any suggestions? Thanks.
>
> --Tom Mendicino
>
>
> > 05 CNM-ACCT-CARD-KEY.
> CCRDNMST
> > 10 CNM-FULL-ACCT-NO.
> > CCRDNMST
> > 15 CNM-SYSTEM-BANK.
> > CCRDNMST
> > 20 CNM-SYSTEM-NO PIC X(2).
> > CCRDNMST
> > 20 CNM-BANK-NO.
> > CCRDNMST
> > 25 CNM-PRIN PIC X(2).
> > CCRDNMST
> > 25 CNM-AGENT PIC X(2).
> > CCRDNMST
> > 15 FILLER REDEFINES CNM-SYSTEM-BANK.
> > CCRDNMST
> > 20 CNM-SYSTEM-PRIN PIC X(4).
> > CCRDNMST
> > 20 FILLER PIC X(2).
> > CCRDNMST
> > 15 CNM-ACCOUNT-NO PIC X(8).
> > CCRDNMST
> >
> >
> >
> The vendor is using a packed-unsigned format to reduce the
> number of bytes to store the full account number. It's just a
> way to compress the
> 28 digit full account number to a 14 byte full account number.
>
> > Example: Full account number stored as 28 bytes (System: 1234 Prin:
> > 0100
> > Agent: 0000 Acct: 1234561005109308):
> >
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFF
> 1234010000001234561005109308
>
> > Full account number stored as 14 bytes as in the Additional Names
> > file:
> >
> > 13000013510190
> > 24100024605038
> >
> >
>
|