Date:         Fri, 20 Mar 2009 10:11:50 -0400
Reply-To:     Gerhard Hellriegel <gerhard.hellriegel@T-ONLINE.DE>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Gerhard Hellriegel <gerhard.hellriegel@T-ONLINE.DE>
Subject:      Re: COBOL to sas layout error
Content-Type: text/plain; charset=ISO-8859-1

Why don't you look at the raw data with the SAS - list statement? With
that you could see the hex-representation of that what you read and you
see the right offset. With one or two examples of that you might be able
to find the right informat.

What I often saw is a construct which uses a kind of template - a simple
structure with one large char-field over the whole length which is
initialized with blanks. The real structure with a complexe structure
(binary fields and other types) redefine that large blank-structure. That
might be a problem, because the SAS numeric formats don't expect blanks
and fire some error messages.
Very often you have a kind of header for those structures which tells you
something about the type of data which follow. If you cannot trust that (I
often saw, that missing fields are simply not written - not a good idea,
but happens) you might first read that field as char by keeping it in
buffer with a trailing § or @, analyze (test for " ") and reread it with
the right informat.

If you list some records you could cut the part out which makes trouble
and paste it here (especially the hex-part). Somebody might be able to
tell you, what might be the right informat to get it.

Gerhard



On Fri, 20 Mar 2009 09:54:58 -0400, Paul Dorfman <sashole@BELLSOUTH.NET>
wrote:

>Amy,
>
>That would be then
>
>10 RRTSCR-SCRD-ID PIC 9(N) COMP-4.
>
>(instead of comp-4, it can be also BINARY or COMPUTATIONAL-4), where N can
>range from 5 to 9 because your real field byte length (as determined by
>Insync) is 4.
>
>As to you other question in the thread, viz., how to read
>
>10 XXXXXX PIC X(09).
>
>you are stating that the informat $9. has failed. A $char9. informat never
>fails in the sense that it never produces "invalid data" messages for the
>simple reason that it reads input characters as is. Neither does $9., but
>it does not read the data as is (read on that in the docs). If you mean
>that the variable XXXXXX contains not what you expect, the reason can be
>
>1) you should use $char9. instead of $9.
>2) you told SAS to read it from a wrong position in the record
>3) you told SAS to read it from the right position, but the record is too
>short, and the file pointer went to the next line, thereby reading from
>wrong position. Use TRUNCOVER option on the infile statement to prevent
>this.
>2) you file has been moved from a mainframe as binary, in which case you
>should read the field as $ebcdic9. However, this seems to be not your
case,
>since, as you state, IB4. worked. If the file were EBCDIC it would not
have
>(you would have to use s370fib4.).
>
>As to cob2sas, it is too old and does not handle many things which are the
>very reason to use a layout translation program in the first place, for
>instance, nested OCCURS, nested REDEFINES, 88- and other special levels,
>etc., let alone combinations of the above.
>
>Kind regards
>------------
>Paul Dorfman
>Jax, FL
>------------
>
>On Thu, 19 Mar 2009 20:42:29 -0700, houhou <amywang11790@YAHOO.COM> wrote:
>
>>On Mar 19, 2:32 am, sash...@BELLSOUTH.NET (Paul Dorfman) wrote:
>>> =20
>>> Amy,
>>>
>>> I have no clue what Insync is. What is the realCOBOLpicture
>of=C2=A0RRTSC=
>>> R-SCRD-ID field=C2=A0you
>>> are trying to read?
>>>
>>> Kind regards
>>> -------------
>>> Paul Dorfman
>>> Jax, FL
>>> ------------- =C2=A0 -------------- Original message from score
><tina.li@TD=
>>Paul, Thank you .
>>I tried IB2. it worked. sorry. I don't have COBOL picture right now.