RE: **IFS**

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Thu, 11 Jul 2002, Bob Cozzi wrote:
>
> I have a question...
> Does anyone want to access IFS files from within RPG?
> I don't just mean by prototyping the C/Unix APIs, but in a robust
> RPG-like manner?

First of all, the APIs are quite robust.
If by "RPG-like" you mean by using F, I and O specs, then ABSOLUTELY NOT.

1) F/I/O spec files do not work well with variable length data.  You
     could work around this by making "length" be one of the fields
     that you read/write, but it would be awkward.  (Though, I've
     already done that with ICF...)

2) F/I/O specs have to be hard-coded at compile time.  This is already
     something awkward with database files, but it would be 10 times
     worse with stream files.   Usually with stream files you want
     to ask the user for a filename to open, and a filename to save as,
     etc.  You don't necessarily know at runtime how many files you'd
     have open at once...

3) F/I/O specs cannot be made local to a subprocedure.

4) Stream files need to be given longer filenames than would logically
     fit on an F-spec.   I'd really hate to see someone create an
     OVRSTMF command that has to be executed to specify the filename
     before opening the file on the F-spec.   I mean, this is already
     awkward with databases, let's not make it this way with stream
     files, too!

In fact, I'd LOVE to see the native database access move away from the
nasty F/I/O support, and instead use an API similar to what we have with
stream files.   (Yes, I know I could call the C _Ropen() style functions
for this, but then other RPG programmers complain about my code being
hard to follow.  If it were part of the language, they wouldn't complain!)


> Is this something that is important? A survey I took recently indicated
> that most people store HTML files as well as some type of data in the
> IFS.

This is VERY important.  In the future, it'll be much more important than
data areas, control files or simple HTML documents.

However, a much better solution would be for IBM to distribute prototypes,
structures, and constants for the UNIX-type APIs in the QSYSINC library as
they do for other APIs, rather than make IFS access limited and awkward by
putting it on the F, I and O specs.

If they are going to add op-codes or BIFs, they should make them similar
to the APIs, rather than similar to the existing RPG file support!!