Invoking Java method from RPG and sharing QTEMP
Ali
I am working towards coding an ILE RPG program that should do the
following:
1. Invoke a prototyped Java method. This java method does some
processing and writes a file to QTEMP.
2. Read the data written into the QTEMP file by the Java method.
My question is : Will the RPG program have the same QTEMP as the one
that the Java program accessed. Or is it that the java method runs in
its own job and the QTEMP is not the same.
Thanks
Ali
Barbara Morris
>
> 1. Invoke a prototyped Java method. This java method does some
> processing and writes a file to QTEMP.
> 2. Read the data written into the QTEMP file by the Java method.
>
> My question is : Will the RPG program have the same QTEMP as the one
> that the Java program accessed. Or is it that the java method runs in
> its own job and the QTEMP is not the same.
>
The Java method will run in the same job as the RPG program.
If the Java method using JDBC to write the file, then using QTEMP might
not work; I think that JDBC runs in a separate job.
Thorbjoern Ravn Andersen
> The Java method will run in the same job as the RPG program.
This is very interesting.
Just as a theoretical exercise fron a non-RPG guy - would it be possible
to write an RPG program that prototypes a given class but with a
classpath determined at runtime, so that class could potentially be
started in any program.
I am looking at building a java launcher which can communicate better
with our OPM-Cobol system than the current RUNJVA which we cannot see
any obvious way to get anything else than a return code from. Could
this be a better approach?
--
Thorbjørn Ravn Andersen
Barbara Morris
>
> Just as a theoretical exercise fron a non-RPG guy - would it be possible
> to write an RPG program that prototypes a given class but with a
> classpath determined at runtime, so that class could potentially be
> started in any program.
>
The classpath can be determined at runtime, but it can't be changed once
the JVM has been created, and there can only be one JVM per job.
walker.l2
> with our OPM-Cobol system than the current RUNJVA which we cannot see
> any obvious way to get anything else than a return code from. Could
> this be a better approach?
> --
> Thorbjørn Ravn Andersen
DTAQs and UserSpaces can be good methods to exchange data between Java
and OPM. (For performance (of JVM startup) reasons, a common set-up is
to have a long-running Java job that accepts messages from OPM
programs via a DTAQ, and sends keyed replies back to another DTAQ for
the OPM program to read.)
As Barbara says, the Java classpath can be set at runtime (via the
CLASSPATH environmental variable - have a look at the ADDENVVAR
command).
Thorbjoern Ravn Andersen
> DTAQs and UserSpaces can be good methods to exchange data between Java
> and OPM. (For performance (of JVM startup) reasons, a common set-up is
> to have a long-running Java job that accepts messages from OPM
> programs via a DTAQ, and sends keyed replies back to another DTAQ for
> the OPM program to read.)
Thank you for your response.
The major problem here is the JVM warmup time - sigh - but that is an
issue everywhere. The problem with dataqueues in our setting is that
all the information present like user, library list, etc etc is lost
unless communicated across the data structure, which then opens the risk
of forged data queue entries. (You may call me overly cautious but we
have to be very careful with this).
> As Barbara says, the Java classpath can be set at runtime (via the
> CLASSPATH environmental variable - have a look at the ADDENVVAR
> command).
We have for logistic reasons settled on executable jars which moves the
whole classpath setting issue inside the java engine. This works well
for us.
--
Thorbjørn Ravn Andersen
walker.l2
> issue everywhere.
>
the impact a little (it defaults to 2000 calls before compilation). We
have our Java job auto-start when its containing subsystem starts; by
the time any application wants to do anything, the JVM is fully
active.
> The problem with dataqueues in our setting is that
> all the information present like user, library list, etc etc is lost
> unless communicated across the data structure, which then opens the risk
> of forged data queue entries. (You may call me overly cautious but we
> have to be very careful with this).
>
Your security issues could perhaps be solved by an OPM wrapper in
front of the DTAQ - your main OPM program calls the OPM wrapper,
passing the necessary data / message as a parameter. The OPM wrapper
generates and adds some header information (like calling user, library
list etc. - or possibly the id / location of a UserSpace that holds
this information), writes a message (generated header + passed
parameter) to the DTAQ (the wrapper could use adopted authority to
prevent anyone else from passing spoofed messages direct to the DTAQ),
and performs a key read on the response queue (job number, threadid,
userid, timestamp etc. could be used as good keys).