I know you didn't direct that question at me, but at my previous employer we
went down that route for a .NET front end to a DB2/RPG back end. In the end
it worked, but it was an optimal approach to a software stack as far as
maintenance goes. For instance, when using stored procedures to call RPG
programs, and when the parm list changes, there are three locations instead
of two to change your code - .NET, stored procedure, and RPG. The other
challenge was change managing the stored procedures. We had to work with
Aldon to get their package to work in our scenario as it didn't feel like
they had done a lot of stored procedure change management at that point.
With stored procedures you can't just move an object from development to
test to QA to production, you have to retain the source and have "variables"
in it so it can be recreated in the correct library for each environment in
the change management stack.
The other part that stunk about the multi-language environment is that it
took a minimum of two people to solve a problem (one .NET and one RPG). In
the end you have to determine which pieces should remain in RPG and which
should be able to be written in Java. For example, don't include RPG in a
call back to the database just because that's how the last call worked.
Instead, evaluate multiple approaches and keep a few of them as "allowed
practices" so developers can choose what will make the most sense moving
forward. The alternative to the example I just stated would be to allow the
Java developer to go direct to the database vs. going through an External
Stored Procedure and RPG.
Complexity in a software stack is the killer of being able to move forward
with your application fast. Another reason I find EGL appealing :-) (though
I am still proceeding with caution)
HTH,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of Thorbjørn Ravn Andersen
Sent: Tuesday, February 05, 2008 11:31 PM
To: Websphere Development Studio Client for iSeries
Subject: Re: [WDSCI-L] Something to read over lunch: Eclipse IDE in
thebrowser
dnitke skrev den 06-02-2008 04:38:
a Rich Client product. The business logic is mostly RPG Stored procedures
mostly because its more effecient (current OS400 of course since V6.1 from
what I have read has more JVM memory for SQL) and it allowed us to re-use
existing logic (some). We use both JDBC to call the stored procedures and
JT400
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.
midrange.com
