On Thu, Jul 6, 2017 at 9:35 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
The power of IBM i is the seamless interoperability between the various
parts. I can embed SQL in my RPG and I can embed RPG in my SQL - with
very, very little plumbing. I can embed Java in my RPG and RPG in my
Java - again, very little plumbing. I can embed C in my RPG and RPG in
my C. Each can send parameters to the other and get results back.
Directly. Not via an intermediate storage medium like a data area, user
space, scratch file, data queue or anything other than CALL/PARM.
I appreciate what you're saying. At least what I believe you're
saying. But I think it's slightly muddled. You've mentioned
"embedding" and CALL/PARM. I don't think these amount to the same
thing. At least, you've given several examples that have notable
differences.
The most "embedded" of your examples is SQL in RPG. Because we have
SQLRPGLE. SQL code literally goes in-line with your RPG code.
Embedding RPG in SQL. I guess by this you mean you can write SPs and
UDFs in RPG, and then use the SPs and UDFs in your SQL. OK.
C in RPG and vice versa. Hm. Are you now talking about the fact that
both generate ILE modules and are thus cross-linkable?
Java in RPG and vice versa. I'm the most hazy about this. I know
there's JNI, but I don't know much about it. I also know Java runs in
PASE. I get this vague feeling that Java does hold some kind of
privileged position among PASE languages, but I'm not sure I would
consider this tantamount to CALL/PARM. I also have this nagging sense
that JNI isn't symmetrical. That is, either "Java in RPG" is a tighter
integration than "RPG in Java", or the reverse. One way is "along the
grain" and the other isn't.
Whichever way is against the grain is, I would argue, getting pretty
far from CALL/PARM and pretty close to whatever trickery Aaron was
talking about with the VLANG project.
Maybe we should first clarify the VLANG project. It wasn't that clear
to me from what little I skimmed, but my impression was that the goal
is to be able to pass parameters in AND get parameters (or return
values) out. On the call. So as far as the programmer is concerned,
it's CALL/PARM. If so, maybe we have to quibble about efficiency or
type safety. And this is where I'm saying I think at least one of the
directions involving Java and RPG integration suffers from the same
limitations.
CALL/PARM is immensely powerful. I can build function calls which are
easily, independently testable. Those tests form a suite which gets run
for every change, verifying that the integrity of all the prior work
wasn't affected by the latest mod. Those suites form a living
dictionary of the business functions, the rules, the bounds, the edge
cases that we guarantee are correct.
Testing individual functions can be done in any language. The rest of
what you're describing... I'm not sure depends on CALL/PARM. Maybe I'm
just not understanding well enough.
For me, PASE is like invoking functionality via RPC. It's better than
nothing, but it's not better than CALL/PARM, and it's not equal either.
OK, this is a nice statement. I definitely agree with you on the
hierarchy, pending learning something about the IBM i architecture
that revises my understanding of how PASE fits in. As far as I know,
by their very nature, communication between PASE and the QSYS.LIB
environment necessarily involves crossing some kind of barrier, or
bridging some kind of gap. Which can sort of be generalized as
RPC-like.
But to me, RPC is so much nicer than those "intermediate storage
medium" methods you mentioned earlier. I mean, you've got sockets.
You're sending something over a wire, and that wire isn't even on a
different machine or a different partition. (Plenty of programs use
sockets to communicate with other programs running in the *same*
environment.)
So, as nice as CALL/PARM? No. Certainly not as nice as ILE-flavored
CALL/PARM. But perhaps not as far behind OPM-flavored CALL/PARM as you
seem to be giving it credit for. After all, the 'PC' in RPC stands for
"procedure call".
For anyone who is thinking of refuting what I'm saying:
Please understand that I know my knowledge is very sketchy. Please
understand that I based a lot of my positions on guesses. If you can
refute my guesses (for example, the relationship between PASE and
QSYS.LIB, the goals or mechanisms behind VLANG, or the nature of JNI),
you are more than welcome to do so. I just ask that you don't go and
refute all my positions that depended on those guesses. If you show
that the foundation is unsound, we all understand that the rest of the
edifice is unsound. No need to point out, brick by brick, all the
bricks that have fallen over.
John Y.
midrange.com
