Re: Java extensions directory vs Excel generation

[Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>]

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.