RE: IFS in RPG

Hah.  You're introducing new keywords; that's not fair. <g>  AFAIK you can't
use string variables as record format names or file names for database files
without a select statement that translates.

I don't see much value in being able to have a stream file name on an F
spec.  I may be short sighted. <g>  If everyone writes different procedures
to do the things that the Unix Type file APIs do, it just means we're
becoming like C programmers who ignore library functions.  The only thing
I'd like to see would be bifs or standard prototypes for copying.  There's
also opportunity for people to do the sort of thing David Morris is doing
with utilities.  I've never understood why there are so few utility
libraries available for RPG.  Might even be possible to sell them.





> -----Original Message-----
> From: Peter Dow [mailto:maillist@dowsoftware.com]
> Sent: Thursday, July 11, 2002 2:14 PM
> To: rpg400-l@midrange.com
> Subject: Re: IFS in RPG
>
>
> Hi Joel,
>
> Why would I lose the ability to use string variables for file
> names?  How
> about
>
>     fXYZ    ipe  i                 disk  usropn path(fldname)
>
> then
>
>     c            eval    fldname='/home/abc.txt'
>     c            open    XYZ
>
>
>
> One point of all this is to avoid having ten thousand
> programmers all write
> different procedures that do essentially the same thing.
>
> Another point is that every example people give of how easy
> the API's are is
> an example of output, i.e. writing to the IFS.  Show me a
> simple example of
> reading a line of text (i.e. data followed by carriage return
> line feed)
> using the API's.  Then compare it to
>
>     d Data1        ds
>     d  TextFld                1024a     varying
>
>     c            read    XYZ        Data1
>
>
> Now imagine you want to read a .csv file with lots of numbers
> in them, e.g.
>
>     123,456.78,23,104568.20-,134.4343,134234,08797,0789.99
>
> Would you rather use the API's or something like the following:
>
>     d Data1        ds
>     d  Nbrs                   31p 9     dim(20)
>
>     c            read    XYZ        Data1
>
> Now imagine you have 5 different programmers trying to solve the same
> problem.  How many different procedures would you get?
>
> Having the native I/O routines handle the data parsing and
> conversion for us
> would go a long way towards answering your 2nd concern about
> handling the
> data once it's been read.
>
> Peter Dow
> Dow Software Services, Inc.
> 909 793-9050 voice
> 909 522-3214 cellular
> 909 793-4480 fax
>
> ----- Original Message -----
> From: "Joel Fritz" <JFritz@sharperimage.com>
> Sent: Thursday, July 11, 2002 1:49 PM
> Subject: RE: IFS in RPG
>
>
> > Seems to me that bifs to wrap the Unix Type file APIs
> wouldn't be a bad
> > thing.  It would standardize things nicely.  OTOH, the
> prototypes aren't
> > arcane.  I don't think being able to put the file name on
> an F spec would
> be
> > as helpful as it may sound.  One thing you lose immediately
> is the ability
> > to use string variables for file names.  I've always found
> that to be the
> > only annoying tradeoff in RPG file I/O.
> >
> > Stream files are harder to deal with than database files.
> There's no way
> > around it.  Opening, closing, reading, and writing are the
> easier parts.
> > The harder part is parsing and manipulating the data once
> you get your
> hands
> > on it.
>
>
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L)
> mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise
recorded by The Sharper Image corporate e-mail system and is subject to
archival, monitoring, review by and/or disclosure to Sharper Image security
and other management. This message is intended only for the use of the
addressee and may contain information that is privileged and confidential.
If you are not the intended recipient, dissemination of this communication
is prohibited.