× 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: Thu, 28 Dec 2000 09:05:24 -0800
  • Organization: Pacer International

I think the problem came in from using the %Trim function on the input
buffer.  You can't do that.  When you read the file you do not want to
modify the location of the characters at all.  Also, using Eval you will
get trimmed data if you are not careful.

When you use the read APIs you have to think of it as a buffer.  What you
want to do is lay out a Data Structure with the format of the file you are
reading.  Then call the API reading into this Data Structure, and everything
should be okay.

Look at this line from your snippet:

C      eval      data = %trim(data) +       
C                %subst(dataRead:1:bytesRead)
 
Say your data now contains '1234   567   '
and you want to add ' 890  123'
Your record when you put it together should be:
'1234   567    890  123'
but, since you are using %trim it comes out to:
'1234   567 890  123' 
and that is where your alignment problem is coming in.  
Also, using eval even if you don't use %trim, it will anyway!

So how do you fix this?  The easiest way, by far, is just to
read one record at a time.

D                 ds          
d dataRead                 1  119A
d dbrec                    1  117A
d endOfLine              118  119A

c      eval      bytesRead = read(fileDesc
c                : %addr(dataRead)
c                : 117)

c      select
c      when      bytesRead <> 117
c* Throw no data exception here
c      when      endOfLine <> x'0D25'
c* Throw out of alignment exception here
c      other 
c      eval      dbrec = dataRead
c      endsl

Note: This is untested code, and was typed in here without even an attempt
to compile.

That is normally the way I handle it this type of thing.  You *can* do it
the way you are trying, but you can NOT use eval to concatenate the strings,
unless you use %Subst or pay very close attention to what you are doing with
spaces.

Richard Jackson wrote:
> 
> I think that strtok wants a delimiter list containing blank, comma,
> parenthesis, and so forth.  Parsing a database record where a character
> column might contain any or all of those delimiters or no delimiters at all
> might be unreliable.
> 
> When I made my suggestion, I was assuming that the string fields were
> null-terminated and that other data types were recognizable within the rules
> of fscanf.
> 
> If the columns don't meet that specification then Phil will have to do all
> the work himself using arrays and so forth.  I suggest that functions be
> created to read each data type and that the mainline should be coded to pick
> out the fields in order.  Something like this:
> 
> * read record from file
> GetRecord();
> * extract fields
> next = 0;
> next = GetIntField(next,addr(field1),4,0); /* get an int field 4 bytes long
> */
> next = GetCharField(next,addr(field2),10); /* get a char field */
> ...
> * write out the new record
> PutRecord();
> 
> In this case, GetIntField would accept a starting location, a pointer
> specifying where to store the data, data length, and decimals.  It would
> read the value from the input buffer, convert the value that it finds to the
> defined output format spec, and write it to the output buffer location.  It
> returns next, the input buffer byte offset for the byte one past the end of
> the field that it just processed.  In other words, GetIntField tells
> GetCharField where to start in the buffer.
> 
> This design has a couple of interesting characteristics.  First, it is
> trivial to use the components in another program that extracts the data for
> another file.  It is almost trivial to write a generator that uses a DSPFFD
> outfile.  It is a little more complex to write a general purpose program to
> read data from any file using a DSPFFD outfile as input and write any other
> file containing columns in a different order or a subset of rows or columns.
> 
> I wish that I had retained all the versions of this that I have ever
> written.  I used the first one in a softcoded EDI translator in the middle
> '80s.  It was written in RPG for the System 38.  The second one went into a
> generic file copy routine - stream files to AS/400 database files and the
> other way 'round.  This version was written in C for either the PC or
> AS/400.  I seem to recall a version in PL/I in the early 90s but I don't
> remember what it was for.
> 
> I hope that you can use either fscanf or strtok.  If not, build good
> architecture and test thoroughly.
> 
> Richard Jackson
> 
> -----Original Message-----
> From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
> Behalf Of Anton Gombkötö
> Sent: Thursday, December 28, 2000 3:52 AM
> To: RPG400-L@midrange.com
> Subject: RE: Unix API read()
> 
> At 18:14 27.12.00 -0800, you wrote:
> >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.
> 
> You do not need a C-compiler to use "C"-functions.
> 
> You'll find valuable information here:
> 
> redbook "Who knew you could do that with RPG?":
> http://www.redbooks.ibm.com/abstracts/sg245402.html
> 
> Maybe you'll find the strtok example interesting...
> A savf with the examples is available by clicking on "additional material".
> 
> Mit freundlichen Grüssen / best regards
> 
> Anton Gombkötö
> 
> Avenum Technologie GmbH
> Wien - Mattsee - Stuttgart
> e-mail Office   :       mailto:Anton.Gombkoetoe@avenum.com
> Homepage        :       http://www.avenum.com
> 
> Lest das Redbook / read the redbook "Who knew you could do that with RPG?":
> http://www.redbooks.ibm.com/abstracts/sg245402.html
> 
> +---
> | 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
> +---
+---
| 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:
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.