Re: RUNJVA performance question

I did a little investigation on this, and RUNJVA creates a Batch Immediate
job with it's own JVM. Thus the result is a new JVM for each RUNJVA
execution.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Charles Wilt <charles.wilt@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Charles Wilt <charles.wilt@xxxxxxxxx>
Date: 03/16/2016 04:51PM
Subject: Re: RUNJVA performance question


One correction, the JVM is only started once per job. There is no way to
end and restart it.

Charles

On Wed, Mar 16, 2016 at 4:47 PM, Keith McCully <keithmccully@xxxxxxxxx>
wrote:

RUNJVA isn't a great way to run java on the i if you have to run it many
times from the same job, as each call will create a new JVM complete with
overheads.

Assuming that you call a specific java method for each record read then

it

would be better to control the java from within the RPG as you mention.

Call the Class Constructor during initialisation to invoke just one
instance of the JVM then go ahead and read your records and, for each
record, call the java processing methods via your defined prototypes. JVM
will terminate when the RPG program ends.

Alternatively you could run everything in java including the table read
from one RUNJVA call as you suggest - that would be a quicker development
if you're familiar with java. You choice might be governed by the nature

of

processing required but either way is way better than calling RUNJVA many
times.


On 16 March 2016 at 17:58, tim <iseriesstuff@xxxxxxxxx> wrote:

Hope this is the correct forum for this question.

I have a process where i read records from a table and call a java

program

using the runjva command. This process can evoke RUNJVA several

thousand

times.

Is there a performance issue doing it this way? Am i better off maybe
calling the java program using RUNJVA once and having the java program

read

the iseries table run the process?

i know i can run a java program using EXTPROC(*JAVA also, but not sure
again about perforance.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.