× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



One of the problems I face here is I'm the only program who knows how to code 
to API's besides my boss.  The other 2 programmers here don't know an API from 
UPS.

Yes, everyone should learn to code to APIs.  Yes, everyone should learn how to 
read programs using APIs.  But let's be realistic, the one ones of us using 
APIs are the ones doing the things out of the ordinary, needing to do thing 
that RPG just can't do natively.  Such as the time I needed to write a program 
to see what network files were waiting (ones sent with SNDNETF).  A few 
questions to the list in MI, a few APIs to read directly from the object on the 
disk and I had the program written.  This can pretty much be defined in the 
realm of system programming.

But your normal application programmer, the ones who write the nifty green 
screen interfaces to the DB2 files, wouldn't be able to make sense of this 
program, nor would I expect them to be able to write one.

But, more and more commonly we need to write and read from the IFS, and it's 
shifting from the realm of system programming to application programming.  This 
is where it needs to be simplified.

I guess what I'm saying is, yes, I use APIs, and I can write prototypes, and it 
takes me longer to do than native RPG programming.  And if we want application 
programmers to use the IFS we are going to have to simplify things a bit to 
make it easier and faster.

As it stands, when we do need to read/write directly to/from IFS files from RPG 
programs I will be writing the prototype wrappers and build a directory and 
include files and etc.. etc..  And when Rochester does come out with native IFS 
reading/writing I'll be able to drop the whole thing and use much easier to use 
native RPG IFS File I/O.

Regards,

Jim Langston

-----Original Message-----
From: Haas, Matt [mailto:Matt.Haas@thomsonlearning.com]

<snip>
As for... "The prototypes... take up about a dozen lines and another 30 
lines...".  So that's 42 additional lines, I was being generous when I said 
25-30.  That just makes my point.
<snip>

But this is no different than having to put together an include file for 
anything else. You only have to do it once.

<snip>
Again, I'm not saying that this is 100% necessary and should be Rochester's top 
priority, I'm just saying it would make it extremely easier to code to IFS 
files than currently, and a lot more people would start coding to IFS.  If I 
ever need to code to the IFS I'll just do the research, write the prototypes, 
etc.., get code samples and do it.  So I'm looking at... 3 to 4 hours the first 
time I want to code to an IFS file.  If they were native RPG it would take me, 
what, 15 minutes to look up the opcodes?
<snip>

If you get the code for the Redbook "Who Know You Could Do That with RPG IV?" 
(http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/a555adfe471ddb288625677c006176c0?OpenDocument),
 it has prototypes and constants included for most of the IFS related API's (or 
at least the ones you would usually use). Chapter 5 goes into pretty good 
detail on how you use them. Yes, you may spend 3-4 hours the first time you use 
the API's but most of that will be reading documentation.

Personally, I don't mind using API's, they're usually pretty straight forward 
to use (big exception being some of the LDAP ones), and I like the power and 
flexibility that comes with them.

Matt


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.