|
I have used both of these technologies extensively, although never together in the way that you have. My first recommendation, since I think it would just be an overall better solution would be to use data queues. In other words, put a layer of Java code in that waits on messages to a data queue, then executes your Java code and puts some return code on a data queue. Your Plex RPG code could then just be modified to call the QSNDDTAQ and QRCVDTAQ API's. This is a better architecture because your Java code stays running and you do not have incur the overhead of starting and tearing down the JVM. A single Java process could probably serve many, many RPG server jobs in this manner, and you could always just start up more Java server jobs listening on the same data queue because the data queue code handles all of that for you nicely. My second suggestion would be to write a small CL program that runs the Java. This could then trap any errors and return them in a variable. You would then just define this CL program as an API function in your Plex model and call it from your RPG. Good luck. Mark PS - I think you would get better answers on the Plex forums at the Edge UserGroup. http://edgeusergroup.pugmarks.net/ java400-l-bounces+markp=softlanding.com@xxxxxxxxxxxx wrote on 01/14/2004 01:14:52 PM: > Hi, > > I am doing calls to Java classes from Advantage Plex programs which > generate and then compile RPG code. I'm doing this by using Format Message > to put the Java command into CommandString, e.g. JAVA CLASS(com.my.class) > CLASSPATH('/My.jar') and then using the ExecuteCommand API to run it. This > all works fine, except that I haven't found a way to get some sort of > success or error code back from the Java program, so the Java program may > throw an exception which gets caught and want to return some sort of error > code back to the Plex/RPG program to say what went wrong but it cannot do > this. Also you can get more serious situations such as if the JAR file is > missing, or the Java program tries to access a class not on the classpath, > which throws a JVA0122 message back to the Plex program, which again cannot > be detected and the Plex program carries on happily assuming the Java > program worked fine. > > So far my best idea on how to handle this is to: > 1) In Plex, use a numerator table to allocate a unique number, lets call it > Java Call Number, to the function call (just allocate the number, don't > write out a record with this number anywhere yet) > 2) Do the call to Java, passing in the Java Call Number as a parameter > 3) The Java program runs and at the very end must at the very end write out > a record using JDBC to a 'Java Call' table, writing out the Java Call > Number and we can also put a return status field on the table which we > would write out as zero/empty if the Java program worked, or > non-zero/not-blank if there was an exception or some other error condition. > 4) After the line which calls the Java program, the Plex program attempts > to read the record back from the 'Java Call' table. If the record is there > then the Java program must have ran successfully and we can read the return > status out to know if there were any problems, and then delete the record > from the 'Java Call' table. If there was no record written out, the call > to the Java program must have failed due to a missing class/JAR, or the > Java program ran but something fundamental failed e.g. the Java program > could not connect to the database. > > This seems completely overkill, surely there must be a better way to handle > this? Has anybody else had this situation? Is there a better way to be > calling Java programs from Plex/RPG than using the JAVA OS/400 command? I > know there are extensions in RPGLE to allow declaring Java classes as > native methods, but Plex unfortunately uses RPG and not RPGLE. I'm by no > means an RPG expert but I gather the two are not compatible? > > Thanks very much, > > Nigel Gay, > Computer Patent Annuities. > > > > > ******************************************************************************** > The information in this message is confidential and may be legally > privileged. It is intended solely for the addressee; access to this > email by anyone else is unauthorised. > > If you are not the intended recipient: (1) you are kindly requested > to return a copy of this message to the sender indicating that you > have received it in error, and to destroy the received copy; and (2) > any disclosure or distribution of this message, as well as any action > taken or omitted to be taken in reliance on its content, is prohibited > and may be unlawful. > ******************************************************************************** > > _______________________________________________ > This is the Java Programming on and around the iSeries / AS400 > (JAVA400-L) mailing list > To post a message email: JAVA400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/java400-l > or email: JAVA400-L-request@xxxxxxxxxxxx > 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 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.