×
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.
Hello Dieter,
... the better is the enemy of the good, why starting a JVM in every Job
needing access to a remote database, why writing cumbersom embedded Java in
RPG, when embedded SQL is supported, as it works with every remote database?
I considered writing an ARD when I first started designing JDBCR4, and I
chose not to. I understand your reasoning, and I feel that your ArdGate
is an interesting tool that will help people, but it's not the panacea
you seem to make it out to be.
I choose a srvpgm approach because:
1) It's been my experience that each job having it's own resources and
not having to worry about a client/server architecture, or jobs sharing
resources, makes things simpler to maintain.
2) I do not feel that using JDBCR4 involves "embedding Java in RPG". I
think it's easy to call JDBCR4 from an RPG program without using any
Java code.
3) ARD does not support LOB columns. Something that was important in my
environment.
4) ARD does not support result sets from a stored procedure call.
Something that is absolutely central & critical to the architecture in
my environment.
5) ARD does not support scrollable cursors.
6) ARD does not support passwords longer than 10 characters. (Used
often in my environment.)
I certainly understand that your solution can achieve a performance
improvement because the JVM can be prestarted. And I certainly
understand that many RPGers are already familiar with embedded SQL, and
that makes it a bit easier to use an ARD... they don't have to learn
something new.
Your solution is a good one. But please don't put mine down.
midrange.com
