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.