× 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.



Jon:

I recently (and amazingly) seriously considered using JNI in a real project
to call back from ILE/RPG into native java applications. The project was
canned (in favor or WebFacing(!)) however, and so I cannot justify spending
any more time on JNI right now.

The situation that prompted use of JNI was unique in that the 'mandated'
architecture for a browser-based application involved using ILE/RPG on the
iSeries for all back-end database access and business logic (due to a
plentiful supply of in-house RPG skills).

On paper, JNI would have given us a low-level tight coupling between an
implemented 'adapter' (perhaps conforming to the JCA interface for
portability across platforms) and RPG procedures in the mandated RPG 'data
access layer'. This would give us good performance and fine-grained access,
with the added benefit of some exposure of Java to the RPG programmers. (We
considered PCML to be too slow for fine-grained access. JDBC stored
procedures were considered to be too cumbersome as they would mandate use of
bound programs for every possible entry point to the 'RPG layer'.)

Anyway, the idea behind using JNI was that the Java 'Data Access
Object/Bean' is constructed in the application server and a java native
method calls directly into to the relevant RPG Procedure. The RPG procedure
now has a handle to the object and calls the setters in the DAO by using the
%THIS built-in-function and assigning the data from the database, and maybe
a bunch of other procedural stuff. On return from the RPG procedure, the
java DAO is now fully populated with data and can be accessed by the Session
Bean.

You mention that you have used the method call support and that you are
aware of the pitfalls. I am aware of the garbage collection issue, the use
of static/global variables in the RPG as a pitfall, and the issue of
translation of data when not calling via methods. What other pitfalls are
there?

Thanks in advance.

Chris Jewell

-----Original Message-----
From: java400-l-admin@midrange.com
[mailto:java400-l-admin@midrange.com]On Behalf Of Jon Paris
Sent: Wednesday, May 29, 2002 3:16 PM
To: java400-l@midrange.com
Subject: Calling Java from RPG/COBOL


I'd like to hear from those of you with more "real world" experience than me
of the pros and cons of different methods of invoking a Java app from RPG
and/or COBOL.  One specific item that I'm interested in is parameter
passing - and returning results from the Java code.  I've used the new RPG
method call support and am aware of the pitfalls there, but that is not
applicable to COBOL and JNI is just to darned ugly to want to consider
unless the alternative is a lobotomy!

Jon Paris
Partner400


_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.