Re: IFS in RPG

Hi Doug,

You make a good argument that the field parsing should be separate from the
file i/o and record parsing.  But I still would like to have the IFS file
i/o standardized by IBM, not by hundreds of different service programs
wrapping the API's.  Since you and other API proponents seem to agree that
using the API's is easy to do, why can't the compiler team do it for us
under the covers, thereby standardizing it?

And actually, I think Hans answered that awhile back, pointing out that even
adding simple things can be a big project for them.  Still, if we don't keep
them (the compiler team) busy, they'll all drift away to play with Perl,
AWK, Java, etc. since RPG will be boring again.  While adding the IFS file
i/o might be boring, I'd think a %SPLIT, %UNSTRING, or %MATCH bif would be a
bit more interesting.

Regards,
Peter Dow
Dow Software Services, Inc.
909 793-9050 voice
909 522-3214 cellular
909 793-4480 fax



----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
Sent: Friday, July 12, 2002 12:35 PM
Subject: Re: IFS in RPG


> >Lets say Barb/Hans/George allowed us to have an F-Spec  for a stream
file.
> >And lets say that they even gave us an I/O opcode that would parse a
comma
> >delimited file automatically into an externally defined D/S.

> To be useful, you'd want keywords to set the record separator and
especially the
> field separator or field pattern.  And  they would need to accept regular
> expressions to define them.  You'd use either the field separator or the
field
> pattern, but not both.  A field separator may be a simple value like a tab
or
> pipe, but commas generally need field patterns rather than separators.  In
other
> words, you define the pattern of characters which comprise a single field,
> rather than what separates the fields in the record.


> >This is the thing to keep in mind.    I would code a Ext. D/S to match
the
> >layout of a Comma delimited file that I "Knew" very well.    There would
be
> >NO mismatches.

> That would work in some instances but certainly not be flexible enough.
It is
> extremely common for text files to have "multiple formats" in them.  Say a
ACH
> type file with batch headers followed by one or more transactions and a
summary
> record.  The whole lot of which can repeat numerous times, possibly
enclosed
> within other control headers or footers, etc.
>
> In other words, while it may be possible for a given file to establish a
line
> (ie record) terminator, and while the same field pattern may work for an
entire
> file, a single external DS only works for very simple files such as
CPYFRMIMPF
> already handles.
>
> Perhaps one could name the DS to be used any given I/O operation -- like a
> program-described READ to a DS -- but that presumes you know what format
will be
> read next.  An alternative would be to read a "record" into a single
varying
> length character field.  Based on the contents you could then use a select
group
> to pass the line of text plus one of various DS names to a routine which
could
> parse the fields and populate the DS subfields.  (Like the UNSTRING
operation
> Peter mentions.)
>
> But at that point, the UNSTRING-like opcode really has nothing to do with
the
> IFS.  It just becomes another opcode which works with characters fields
and DS
> of any origination.
>
> Thus my contention is that the parsing shouldn't be done at the F-spec
keyword
> level.  Text file input should be done into a single varying length field,
and
> then parsed based on the contents of the record.  Or we could use record
> identifying indicators in the input specs, and code different input
layouts
> based on the contents of some column!  Should make all the old-timers feel
right
> at home! :)
>
> And once all the read operation does is find the next line terminator,
then we
> are back to doing very little more than putting a wrapper on the Posix
APIs.
> You could just use the routines in "Who Knew You Could Do That with RPG
IV?".


> >WE NEED THIS

> Do we?  This to me falls in the camp of just needing a open/clse
statements, and
> a ReadLine statement.  And those are simple enough to do with the existing
APIs.
>
> Beyond that we could use something like COBOL's UNSTRING or AWK's SPLIT(),
but I
> see that as being more of a generic string opcode or BIF and not part of
IFS
> support per se.
>
> And it could be done with a service program now too, so I remain
unconvinced the
> compiler team needs to spend their time doing it.
>
> More than IFS open/close/read support, I'd like to see BIFs for
sophisticated
> regex operations, say a %LIKE or %MATCH, or to have %SCAN enhanced to
accept
> regular expressions.
>
> Having a %SPLIT or whatever which parses a varying length string into an
array
> of varying length strings (one element per "field") or directly into DS
> subfields would seem more useful to me than IFS operations.