RE: IFS in RPG

One thing about the Unix Type File APIs is that they're identical (at the
interface level) to the standard C library functions for low level file I/O.
RPG is one of the few languages that makes file handling simple.  Seems to
me that a good deal of that comes from the integration of the database with
the operating system.  AFAIK, stream files are a lower level thing.  The
good and bad part is that you can impose any structure or lack thereof on a
stream file.  The closest thing I can think of in AS/400 terms is a
sequential file.

I think it's a good thing that we have simple and reliable utilities like
cpyfrmimpf to translate delimited stream files into database files.
Considering IFS vs QSYS.LIB file I/O performance in RPG, it's probably a
good thing to use the QSYS.LIB file system for anything involving database
work.

I'd rather do it that way than use RPG when dealing with records and fields.
OTOH it's not very hard using the examples from the RPGIV redbook to get
going with the stream file APIs.  I think they're pretty cool for doing
things like generating dynamic e-mail messages.

> -----Original Message-----
> From: Tom Daly [mailto:tdaly_2002@yahoo.com]
> Sent: Friday, July 12, 2002 11:33 AM
> To: rpg400-l@midrange.com
> Subject: IFS in RPG
>
>
> This is great!  Between this and some of the other
> ideas in this thread (Peter Dow, Jim Langston) I'm
> getting pretty psyched!  Unfortunately this will
> probably not come to pass.  It will likely be
> poo-pooed by some (IBMer who shall remain nameless) as
> being a waste since we can do this via API.  Well why
> waste time with EXFMT when the DSM APIs will do just
> fine.  In fact why not just chuck it all and go back
> to assembler?  We don't need no stinking HLL!
>
> Recently on MidrangeComputing's forum I floated the
> idea of a "Move Corresponding" type operation for RPG
> data structures.  This was brushed aside... even
> though COBOL has had this functionality for decades.
> This would be nice for loading/unloading to/from
> screen and DBfile buffers (externally defined DS)...
> one operation, done.
>
> I suppose we will have to create our own SRVPGM for
> this.  How about opensource but no GNU no nothing,
> free to anyone with no strings?  What do you all thing
> about that?
>
> JMO -
> Tom
>
>
>  |  -----Original Message-----
>  |  From: Buck Calabro
> [mailto:Buck.Calabro@commsoft.net]
>  |  Sent: Friday, July 12, 2002 13:36
>  |  To: rpg400-l@midrange.com
>  |  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.
>  |    --buck
>  |  _______________________________________________
>  |  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.
>  |
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
> _______________________________________________
> 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.