Re: IFS in RPG

["Peter Dow" <maillist@xxxxxxxxxxxxxxx>]

Hi Buck,

It's amazing the amount of resistance to a new idea I'm seeing <g>.  And
it's not even that new -- it's been suggested before by John Carr.  Nor do I
believe it is very radical -- very little syntax change, and some new F-spec
keywords.

My first response is that I'm not looking for a universal file transfer, I'm
looking for a simple implementation that would handle most cases --
comma-separated-values (.csv) files was the closest to a decoder that I
suggested -- and be the basis for more complex stream file processing.

My 2nd response is -- great idea!  Add a keyword that specifies the name of
a decoder program.  These could be written by IBM or a 3rd party.  No need
for extensions, but some need for the RPG program to know what it's
expecting.  Which I believe is already an expectation, hence the CPF4131
message if expectations are not fulfilled.

As Joel Fritz said yesterday, "The harder part is parsing and manipulating
the data once you get your hands on it."  Having a standard way of doing a
large part of that would let application programmers get to the application
part instead of fiddling with parsing routines.

If it's too traumatic to combine file i/o and parsing (i.e. reading into a
data structure), how about an opcode like COBOL's UNSTRING?  Then I could
use the API's to read the entire file, and use UNSTRING to put it into a
externally-defined data structure.  Still not as nice as having the compiler
do it.  For those unfamiliar with COBOL's UNSTRING opcode, it takes a string
and parses it into multiple receiving fields.  You can specify a starting
point in the input string, delimiters, and what to do if an error occurs.
However, afaik, it does not do data conversions (e.g. character-to-numeric).

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

----- Original Message -----
From: "Buck Calabro" <Buck.Calabro@commsoft.net>
Sent: Friday, July 12, 2002 10:36 AM
Subject: RE: IFS in RPG


> Presume that the compiler can dynamically open any stream file we have.
> Presume that the compiler can use OPEN/CLOSE/READ/WRITE and even UPDATE to
> change the pseudo-records size. (why not, it's my fantasy!)
> Presume that the runtime has decoders for all the popular formats, and
even
> allows me to register a decoder for formats that aren't (yet) included
with
> OS/400.
> Presume that the compiler can dynamically call the proper runtime decoder
> and throw errors when the program's receiver variable/structure/new data
> type can't match the decoded file at runtime.
> Presume that everything I said about 'decoder' applies to 'encoder' as
well.
>
> What did I miss.... let me see now...  Oh.
>
> How do we tell the runtime what kind of file we're looking at?  Do we want
> OPEN to examine the first 10kb of the file and deduce it's proper decoder?
> No, that won't work... too many chances for overlap.  Oh, wait; how about
> using part of the file NAME to tell us what decoder, let's call it a file
> EXTENSION!  We can simply DISREGARD those Unix people or (heaven forefend)
> telephone switches and other devices that don't use Windows naming
> conventions.  And never mind that Microsoft use the same extension to mean
> different things as well as the same INCOMPATIBLE thing depending on
version
> of Excel you must target.
>
> Work that one out and we have a winner.
>
> Would I like to be able to issue a READ against any version of MS Excel
and
> fetch one row and decode each column or that row into a data structure?
Who
> could possibly answer no to that request?
>
> Would I like to be able to dynamically shrink and grow my HTML by simply
> doing a CHAIN then an UPDATE?  Um.  Yes.
>
> Do I want a way to automatically transform my switch records in any of
> dozens of formats AUTOMATICALLY into my own database structure?  What a
> dream... no more file transformation issues.  Ever.  XML?  Don't need no
> fancy schmancy XML parser.  Use READ.  It'll be able to go out and fetch
the
> appropriate XSLT, DTD or schema and run with it.  Oh, wait - are there
> stream files that span 'records' delimited by CR/LF?  Icky.  No matter;
> we'll posit a DYNAMIC record delimiter so that we can tell each READ when
to
> stop reading.  Glad that's fixed.  Word document and embedded formatting?
> Pffft.  Have an option to simply strip out the formatting leaving only the
> text behind.  EDI/multi-format physical files?  Simple as can be - we'll
> just add a file descriptor file to aid the decoder/encoder, just as if we
> were mapping to an actual EDI program.  WRITE and you get the PO850 and
all
> associated elements.  Binary formatted variable data like IOCA or 5250
data
> stream or switch records could be handled with a series of linked mapping
> files, so that one "keyword" triggers one decoding table, whilst another
> "keyword" triggers another.  Sounds like a finite state machine to me.
>
> It's a noble goal; universal file transfer.  It'll be quite wonderful to
see
> iSeries and RPG as the first platform to achieve it.  Ever.
>
> Submit those PMRs today and let your needs be known.  If we don't tell the
> powers that be, the work will never get scheduled, that's certain.  Until
> then, decoding transferred files remain firmly in the realm of clever
> application programmers.