× 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: Phil Groschwitz <sublime78ska@xxxxxxxxx>
  • Date: Wed, 27 Dec 2000 18:14:04 -0800 (PST)

Richard,

This looks good.  Can I call this from an rpg pgm?  It
isn't one of the UNIX-like api's.  The 400 I'm using
doesn't have a c compiler.  Without that I don't know
if I can some how prototype it.

Phil


--- Richard Jackson
<richardjackson@richardjackson.net> wrote:
> Please look at fscanf().  That should help you
> properly locate those
> strings.
> 
> Richard Jackson
> 
> -----Original Message-----
> From: owner-rpg400-l@midrange.com
> [mailto:owner-rpg400-l@midrange.com]On
> Behalf Of Phil Groschwitz
> Sent: Tuesday, December 26, 2000 1:01 PM
> To: RPG400-L@midrange.com
> Subject: Re: Unix API read()
> 
> 
> 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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.