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



Yep, except I don't recommend RUNJAVA. Use QSHELL because you can capture and process STDOUT and return data from the Java call.

IE: Simulating call parm across process boundaries when calling Java.

To answer Justin's question, a single CL job stream can make multiple QSH calls to different JVM versions with different classpaths for each call.

In practice I don't usually recommend this, but it demonstrates the relative flexibility of writing simple Java programs and the possibility of actually making calls to multiple JVM versions in the same CL job.

Also performance mileage will vary depending on the number of Jar files you're using andn 32 vs 64-bit, etc., etc....

Always test as with any app 😊

Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------

message: 6
date: Mon, 22 Jan 2018 13:40:39 -0500
from: Mark Murphy <jmarkmurphy@xxxxxxxxx>
subject: Re: Java extensions directory vs Excel generation

The limit is one JVM per job. Once you start a JVM, you can't change the
classpath or any environment variables for that job no matter how you call
it. You can call RUNJVA as many time as you want from CL because RUNJVA
does not stay in the same job. It runs in a Batch Immediate job just for
that call. I use Java from RPG to produce Excel spreadsheets and Word
documents. Mostly spreadsheets. It is best, in my opinion to submit these
to batch. That way they can run as the please, and do not consume too much
in the way of system resources. I can also have a different classpath or
Java version for each report as each one is submitted to it's own job.

On Mon, Jan 22, 2018 at 1:08 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Unless Java via QSH re-uses a single JVM, I'd call that the opposite of
efficient. If it does re-use a single JVM, then it suffers from all the
same issues.


"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."
Please explain. AFAIK, the one JVM per job is an OS restriction.




-----Original Message-----
From: Richard Schoen [mailto:Richard.Schoen@xxxxxxxxxxxxxxx]
Sent: Monday, January 22, 2018 12:00 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Java extensions directory vs Excel generation

"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."

Until the JVM crashes or runs out of memory, then your job has to be
restarted. Seen that a bit. Ouch..

If you want to keep Java resident. Better to create a Java based simple
app server then to call and consume Java stuff via REST. Queue Dieter...

That keeps Java in memory but also out of process so RPG can do it's thing
by sending data queue entries possibly or using REST calls to the Java
process which is much easier than mapping Java methods to RPG. Yuk...

BTW: Calling Java via QSH is pretty efficient these days but I agree you
want to limit too many simultaneous calls depending on the app needs.

Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
----------------------------------------------------------------------

message: 1
date: Mon, 22 Jan 2018 14:34:17 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: Java extensions directory vs Excel generation

I assume by "single instance issues", you mean the fact that each job only
gets a single JVM, which can't be changed or restarted.

Using Java as your driving language is a viable option, but (for
performance reasons) you certainly won't want a ton of RUNJVA from RPG/CL.

"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."
Please explain. AFAIK, the one JVM per job is an OS restriction.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.