Re: IFS files and VARPG

Hi Rob,
 
<snip>Thank you. My basic question was going to be something like if VARPG
bangs out local file support with no major tricks then why can't RPGLE get
to the IFS without api's? However it looks like you'd have to rewrite all
the current F specs to use DB2 files if IBM was going to adopt the VARPG
methodology. And that would be a major blow to backward compatibility.
</snip>
 
The way VARPG allows access to stream files via F-specs is probably the
crappest implementation of any unix-type functionality I have seen since the
clever idea of storing HTML files within database source members. You have
to think of open(), close(), read(), and write() not as APIs but as built-in
support for using file descriptors - you don't need any special library
list, or binding directories to use them - they are just there. It is like
using a standard library of functions. The only pain is the fact that you
have to prototype them yourself, rather than simply /include (vis <include>
) a standard copy member.
 
IMHO, if we are going to get into the habit of using file descriptors then
we need to use them "properly". By that I mean we need to follow the already
well-trodden Win32/unix/linux route. To implement it as some unholy F-spec
b*stard-child was a big mistake. (again, IMHO). VARPG should have natively
implemented support for open(), close(), etc.. without any F-spec nonsence.
This would have allowed healthy cross-fertilisation of ideas between VARPG
programmers, RPG programmers, C programmers, and the lucky few multilingual
programmers.
 
Controversial? Maybe. But I like the fact that I can google on such things
as open(), read(), opendir(), readdir(), etc... and find useable examples in
many languages. They are telling the same story, it is just the language
which differs. But you can't translate a C or C++ opendir() into a RPG
*LOCAL F-spec. They just don't relate. You need to understand how F-spec
support for these functions work before you can compare/contrast. But once
you know it - well, you already know it. :-)
 
Google results:
C++    DIR * opendir(const char * path);            From C++ Reference Guide
(example used <dirent.h> and <dir.h> includes)
C        DIR * opendir (const char *dirname)        From GNU C library
 
>From infocenter API finder - which we use to translate into RPG prototypes:
DIR *opendir(const char *dirname)  

I like the way RPG is becoming less like the estranged relative, and is
coming into the fold. I like that I can read a nice bit of C code and think
"that would work really well, if not better, in RPG". I just couldn't do
that if RPG constantly insisted on doing it's own thing.
 
Just my thoughts.
 
Larry Ducie
 
 
P.S. This discussion has been around for a looong time - Cue a response by
Jon Paris to a similar question on this forum (well midrange-l anyway) way
back in October 1997 - that's over eight years ago:
 
>Right now we can't get AS/400 data to a *STMF in the IFS without doing
>it manually(File Tranfer via CA/400)  or copy to QDLS then copy to a
>named directory/stream file.   Why not just let us "Read & Write"
>to a named directory we created on the IFS like VARPG(hence RPGIV
compiler)?


John, you don't need us to add any extensions to the compiler - you can
already do this by prototyping the IFS APIs. Ray Bills from Rochester
gave sessions at Common on using these from RPG and COBOL, and I also
"stole" his RPG example and handed it out with my "Free-Stuff" handout.
It's so easy to do I don't see that there's any point in extending the
language to include it. Besides, the way to handle it would surely be to
have the OS extended to allow an OVR to be issued to 'point' a regular
database file at the IFS file - RPG shouldn't need to care.
 
(source:  <http://archive.midrange.com/midrange-l/199710/msg00086.html>
http://archive.midrange.com/midrange-l/199710/msg00086.html)