× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Unix API read()
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Tue, 26 Dec 2000 13:26:44 -0800
  • Organization: Pacer International

Okay, let me see if I got this straight...
You have a file that is supposed to be fixed width columns.  
Field A starts from 1, goes to 10.
Field B starts from 11, goes to 20.
Field C starts from 21, goes to 30.

For some reason, though, when Field A was written instead of whatever
writing it padding it to the full 10 chars, it didn't pad it at all.
Say, for example, the data in Field A is only 5 characters long.  So
that means that now Field A foes from 1 to 5, and Field B goes from
6 to 15, and Field C goes from 16 to 25.

Is that correct?

By the time you get the file in this situation, there is nothing you
can do about it.  You do not know if the first 10 bytes of the file are
all field A, or field A and half of field b.  What I would do in this
situation is get the size of the record I just read.  If it is not the
full length I expected I would throw out an exception.

As you said, you have no control over generating this file, right?  This
was generated by someone else.  You can try to build some logic into the
file and see if you can determine where the fields start if they are 
truncated like that.  But it is not something that you could guarantee
to be accurate if they are giving you bad data.

Regards,

Jim Langston

Phil Groschwitz wrote:
> 
> Thanks for all the input!
> 
> I don't think this is my problem, though.
> 
> It is a stream file that I'm reading.  I read 1024
> bytes at a time, and scan for x'0D25'.  I then
> substring the 1024-byte string so that I get one
> "record" which I then parse.  The length between
> x'0D25' should be 119.  The problem is apparent upon
> reading the stmf - before moving it to a db file
> format: There are sometimes fewer spaces within the
> record (prior to the x'0D25') although it should be
> fixed width. For example, assume position 5 contains a
> 10 position string and position 20 also contains a 10
> position string.  This means position 15 to 19 should
> contain blanks.  Usually does, but occasionally there
> are fewer blanks, causing the 10 position that starts
> at 20 to begin at 17.  How do I handle that?  In
> notepad and edtf, the format is correct so I am
> hopeful that there is a way to handle it - just have
> to find it.
> 
> Here's some snippets of what I'm doing:
> 
> D bytesRead       s             10I 0
> D data            s           2048
> D dataRead        s           1024
> D dbrec           s            200
> 
> C      eval      bytesRead = read(fileDesc
> C                : %addr(dataRead)
> C                : %size(dataRead))
> -------
> C      eval      data = %trim(data) +
> C                %subst(dataRead:1:bytesRead)
> C      eval      length = %scan(x'0D25':data:offset)
> -------
> C      eval      dbrec = %subst(data:offset:
>                  length-offset+2)
> 
> Thanks again,
> Phil
> 
> --- Ken.Slaugh@cm-inc.com wrote:
> >
> > Jim, you're right. The OS/400 native data base
> > supports variable length
> > strings. Compile a file with a DDS member with the
> > following line of code:
> >
> > D    VARDTA    5000 A         VARLEN
> >
> > =-=-=-=--=
> >
> > Does the Unix API return the length of the data
> > returned up to a maximum
> > buffer length? Most do. If so, then substring the
> > data in RPG with some
> > thing like:
> >
> > c    eval VarDta = %subst(APIData: 1: APIDataLen)
> >
> >
> >
> > Ken Slaugh  (707) 795-1512 x118
> > Chouinard & Myhre, Inc.
> > AS/400 Professional Administrator/MSE
> > Client Access Specialist
> > http://www.cm-inc.com/
> >
> >
> >
> >
> >                     Jim Langston
> >
> >                     <jimlangston@conexfr        To:
> >    RPG400-L@midrange.com
> >                     eight.com>                  cc:
> >
> >                     Sent by:
> > Subject:     Re: Unix API read()
> >                     owner-rpg400-l@midra
> >
> >                     nge.com
> >
> >
> >
> >
> >
> >                     12/26/00 09:49 AM
> >
> >                     Please respond to
> >
> >                     RPG400-L
> >
> >
> >
> >
> >
> >
> >
> >
> > It seems from the data that it is being padded
> > *before* the
> > OD 25.  So each record would be a different length.
> >
> > DB2 files all have records of the same length.
> > There are no
> > variable length records (don't take that as an
> > absolute, as I'm
> > sure someone could come up with a SQL file that has
> > variable
> > length records).
> >
> > Try creating the record length on the read function
> > to longer
> > than the records are.  That is, if you are expecting
> > 176 length
> > records, actually ask the unix read function to read
> > 255 length
> > records.  The end of the record should be padded
> > with spaces (x40)
> > or maybe nulls (x00).
> >
> > I think the error is probably coming from you
> > specifying 176 length
> > records, and since the record is longer than 176 the
> > call is complaining
> > that it didn't read the entire records, which it
> > didn't.
> >
> > Regards,
> >
> > Jim Langston
> >
> > Phil Groschwitz wrote:
> > >
> > > Do you mean it pads within the record in order to
> > > align the data with the prior record?  Or pads
> > after
> > > the crlf?  How does edtf display these two hex
> > > examples exactly the same when one has fewer
> > blanks
> > > before the crlf than the other?
> > >
> > > Thanks for your help.  I want to be able to read
> > in
> > > this file and parse it but this is causing
> > trouble!
> > >
> > > Thanks,
> > >
> > > Phil
> > >
> > > --- Rolf Mittag <rm@r-m-e-d-v.de> wrote:
> > > > I think Notepad and EdtF are simply padding the
> > > > records which have
> > > > different lengths with blanks. The EBCDIC "0D"
> > and
> > > > "25" stand for
> > > > carriage return = end of line = end of record. I
> > > > marked them with "^"
> > > > (caret).
> > > >
> > > > Rolf
> > > >
> > > > C1F0F1F2 F0F1F1F6 F0F0F440 F3F4F0F4   :A012 0116
> > 004
> > > >  3404:
> > > > F6F04040 4040F1F1 61F2F161 C1F04040   :60     11
> > > > /21/ A0  :
> > > > 40F0F1F0 F0F1F0F1 F0404040 40404040   : 010 0101
> > 0
> > > >      :
> > > > 40404040 40404040 40404040 40F0F0F0   :
> > > >   000:
> > > > F0F0F0F0 F0F0F0F0 F9F34BF1 F2404040   :0000 0000
> > > > 93.1 2   :
> > > > 40404040 40404040 40404040 404040F0   :
> > > >     0:
> > > > F0F0F0F0 F0F0F0F8 4BF0F040 40404040   :0000 0008
> > .00
> > > >      :
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 0D254040 40404040 40404040 40404040   :
> > > > 40404040 40404040 40404040 40404040    ^^
> > > >         = CR CR
> > > > 40404040 40404040
> > > >
> > > >
> > > >
> > > > C1F0F1F2 F0F1F1F6 F0F0F440 F3F4F0F4   :A012 0116
> > 004
> > > >  3404:
> > > > F6F04040 4040F1F1 61F2F461 C1F04040   :60     11
> > > > /24/ A0  :
> > > > 40F0F1F0 F0F1F0F1 F0404040 40404040   : 010 0101
> > 0
> > > >      :
> > > > 4040F0F0 F0F0F0F0 F0F0F0F0 F0F9F34B   :  00 0000
> > > > 0000 093.:
> > > > F1F24040 40404040 40404040 40404040   :12
> > > >      :
> > > > 40404040 F0F0F0F0 F0F0F0F0 F84BF0F0   :     0000
> > > > 0000 8.00:
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 40404040 40404040 40404040 40404040   :
> > > >      :
> > > > 40404040 400D2540 40404040 40404040   :
> > > >      :
> > > > 40404040 40404040 40404040 40404040          ^^
> > > >        = CR CR
> > > > 40404040 40404040 40404040 40404040
> > > > 40404040 40404040
> > > >
> > > > Dipl.Inf.(FH) Rolf P Mittag
> > > > IBM Partner In Development
> > > > Leipziger Str. 50
> > > > D-69214 Eppelheim
> > > > eMl: rm@r-m-e-d-v.de
> > > > Fon: +49 (6221) 76 78 60
> > > > Fax: +49 (6221) 76 80 26
> > > >
> > > > +---
> > > > | This is the RPG/400 Mailing List!
> > > > | To submit a new message, send your mail to
> > > > RPG400-L@midrange.com.
> > > > | To subscribe to this list send email to
> > > > RPG400-L-SUB@midrange.com.
> > > > | To unsubscribe from this list send email to
> > > > RPG400-L-UNSUB@midrange.com.
> > > > | Questions should be directed to the list
> > > > owner/operator: david@midrange.com
> > > > +---
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> >
> === message truncated ===
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.