Re: IFS in RPG

Hi Hans,

Answers in line -- or more questions...


----- Original Message -----
From: "Hans Boldt" <boldt@ca.ibm.com>
Sent: Thursday, July 11, 2002 12:28 PM
Subject: Re: IFS in RPG


> Peter Dow wrote:
> > I think the questions should be "what's the best way to integrate the
IFS
> > with RPG's file handling?"
> >
> > I'll throw out a few ideas and you can all shoot holes in them:
> >
> > On the Filespec:
> >     1. Only allow Input or Output on the file spec.
> >     2. Don't put a record length.
> >     3. Add a keyword for the external file name similar to the member
name
> > now available in v5r1.
>
> In other words, you end up with a file spec that has next to nothing
> in common with other forms of file spec.

What difference does it make what it has in common with other file specs?  I
mean, is that a technical argument against it?  Does a WORKSTN filespec with
a subfile have a lot in common with a DISK file spec?  Does it have to in
order to be a part of RPG?  Besides, let's see, they both have an F in
pos.6, an internal file name, a I or O in pos. 17, pos.18 (File Designation)
could be I for IFS, or you could use pos.35 (File Organization) to indicate
it's an IFS file, keywords could be used as I said for the external file
path/name and other things that might be useful.

    fPATSELD   cf   e             workstn indds(PATSELDind)
    f                                     sfile(PATSELS1:S1RRN)

    fUB92s     ipe  f  133        disk

    fUB92i     o    e             disk

    fXYZ       ii   v             disk    path('/home/test/XYZ.txt')

So how much in common do all the above file specs have?



> > For the Calculation specs:
> >     1. Use the READ into DataStructure format.  This could work a couple
of
> > ways:
> >         a. Read delimited -- read the input stream into a separate DS
> > subfield, using EVAL rules, up to user-specified delimiter.
> >         b. Read by size -- read x characters into the DS, where x is the
> > size of the DS.
> >     2. Use the WRITE from DataStructure format.  Again:
> >         a. Write delimited.
> >         b. Write by size.

> A better approach would be to read into and write from varing length
> character variables.

That's easy -- the data structure could simply have variable length
subfields.  RPG should be able to handle it either way.  With an overflow
error if the stream data overflows a particular subfield (either fixed or
variable length).


> In other words, you'd end up with I/O opcodes that have next to
> nothing in common with other forms of I/O opcodes.

This "nothing in common with" argument is really irritating, and has nothing
to do with whether this is possible, desirable, feasible or even a good or
bad idea.  Nevertheless, what's in common with the following?

    c                   write     UIREC

    c                   read      XYZ         IFSds

    c                   read(E)   FILEA       DATA1

    c      "Enter nbr"  dsply                 ABC

    c                   exfmt     FMTabc


Should they not be used if they have nothing in common with each other?
Perhaps removed from RPG?



> > It doesn't have to handle every possible way to read/write a stream
file,
> > just the most common.


> But when you have to handle some less common case, you'd still end
> up having to call the Posix routines directly anyways.  And face it,
> those routines aren't all that difficult to deal with.

How often will I have to handle a less common case?  What case couldn't be
handled by the above suggestions?


> What's the
> difference between learning some new RPG function and learning how
> to call some API?  (Well, there's one difference - if you learn the
> API, you'll also be able to use it when programming in some other
> language as well!)

Given that some API's can be quite complex (see Scott Klement's explanation
of the API that he says requires a PhD in pointers to understand), I'd have
to say "it depends".  Or you could take Scott's tack and dump RPG's file i/o
altogther, since it can obviously be done using the Posix API's.  Although
Scott doesn't actually do it because it makes his code difficult for other
programmers.  Isn't that a clue?

Sure, every programmer out there can write their own procedures and service
programs to handle the most common IFS I/O requirements.  They could also
write their own routines to do date & time handling.  Would that be a good
thing?  Or is your real objective here to talk us out of using RPG
altogether?

Actually, when I have the time, I do want to learn Perl and Java.  For now,
the demand is for RPG, CL, and VB.  Maybe when I retire, or figure out how
Simon Coulter manages to find the time to do it all.

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