Thorbjørn Ravn Andersen wrote:
I'd like to hear your opinion on calling stored procedures as opposed to
doing ProgramCall's. Advantages beyond having easy access through SQL,
disadvantages, ease of debugging.
This is because I am considering if it would be an advantage for us to
investigate this more.
You've heard a lot of opinions, and this really is an opinion issue so
I'll just give you mine without trying to argue anybody else's opinion
(well, except maybe Aaron's, but that's just because he's a nice guy and
he's fun to pick on <grin>).
I did a whole course on calling RPG from Java. There are a number of
ways, some you might not even think of. For example, database triggers
allow you to easily invoke RPG programs just by writing to a file using
ANY database access technique.
But in the case of bidirectional data calls, the two easiest solutions
are stored procedures and JTOpen ProgramCall calls. To me, which one to
use depends on the business requirements. No big surprise there - Joe
says that it's a business decision. But really, the decision is this:
if you need to expose the business logic to people without strong Java
skills, then stored procedures are the way to go. JDBC is pretty easy
for just about any Java programmer. And stored procedures become
especially attractive if you may need to expose the same logic to
non-Java environments, such as .NET.
On the other hand, if you're looking for the highest performance and the
most control over your environment, ProgramCall is the way to go. With
JTOpen, it's quite easy to create a persistent connection to the host,
which means that you will have a dedicated QZRCSRVS job running on the
System i which you can then control to the tiniest detail. You can set
the library list, you can call programs that don't set on *INLR, you can
leave files open and SQL cursors, all kinds of things that lead to a
much higher performance than a non-persistent (stateless) connection.
So, to me the question is simple: am I writing a high-performance
application for authenticated users, or am I willing to give up a little
performance in return for a little more flexibility in access methods?
If neither is the case, then it comes down to the data: it's easier (in
my opinion) to pass complex data with ProgramCall than with stored
procedures because ProgramCall supports data structures very nicely. So
in the end, I tend to favor the ProgramCall technique.
Joe
midrange.com
