Alternatively, if the java program doesn't effect the interactive job, you can make the java app a server job and create a native program (RPG, Cobol, or CL) can send requests to.
This way you only have a single instance of the java app running.
Data queues are my choice for communicating between java & native apps.

Running Java in a Serverjob, communicating asynchronous with RPG/CL and other native stuff is anyway the fastest, best scalable and most stable implementation for interaction between these two worlds. I have written an Open Source solution for this (AppServer4RPG), it's avaalable at SourceForge and it's acting as a base layer for the two OpenSource applications ArdGate (universal database bridge driver for SQL connects from DB2/400 to all JDBC capable databases) and RunJavaRun (the fast way to call Java commandline tools from RPG/CL).
To plug in a new application, you would only have to write an (Java) EventHandler and two Pords2Pojo Beans for the translation of the Parameterdata. adding 1 line to the configuration of AppServer4RPG and throwing all needed jars of your app into the lib directory of your AppServer4RPG installation and the job is done. AppServer4RPG will do all other parts (assemmbling the class path, sending the data in packets between the native part and the Java part, keeping statefull information at sessin level, running the requests in multiple threads...)


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.