Re: Calling a java pgm from RPG IV

Its a little better...we actually did "thread safe" the RPG runtime,
enabling JNI calls between RPG and Java...but not at very granular level.
Only one thread actually gets to execute RPG code at a time, the others are
blocked.


Greg Hoffa


Fred Kulack/Rochester/IBM@IBMUS@midrange.com on 11/22/2000 02:24:03 PM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   JAVA400-L@midrange.com
cc:
Subject:  Re: Calling a java pgm from RPG IV




> Could you explain a little bit in detail about RPG & java threading
> problem.
Ok...  Bear with me. It'll get a bit verbose...

I was one of the developers of the AS/400 kernel thread model and have a
pretty good grasp of the Java side too.
HOWEVER.... I don't pay much attention any more to the changes
in RPG related to threads. So, someone correct me if I'm wrong or
seriously out of date on the RPG issues (I'd actually like to know) 8-)

AS/400 Kernel Threads:
======================
When providing kernel threads support, we needed to make some
incompatible changes in the process model. This caused us to use a
switch at the job level that indicates if the job can create threads or
not.
the switch can be turned on a couple of ways.
 The simplest... SBMJOB CMD(***) ALWMLTTHD(*YES)

This means by default some jobs cannot create threads and
will get an error when they attempt to.
There are some categories of OS/400 that create what're called
'system threads'. System threads are priveleged and bypass
the limitation, and are allowed in any job.

Similarly, large chunks of what we considered legacy
parts of the operating system were not made thread safe.
We focused pretty heavily on Unix type/ILE APIs, plus
database in an effort to get the Websphere, Lotus,
HTTP server sort of applications.

Some 'legacy' parts of the operating system had very
aggressive but simplistic locking inserted that could
stop concurrency cold in a threaded application (but
would be safe).

Some 'legacy' parts of the operating system were
blocked completely from access because they might
corrupt the system or customer data.
Some other parts that weren't viewed as critical
or dangerous were simply not addressed at all..

I defend all these decisions as necessary to get
kernel threads support in place. However, not all
of them were probably 100% correct or unbiased. 8-)

Java threads
============
Java is implicitly threaded. When you start the JVM, there's
like other threads (garbage collector and finalizer) that get created.
I'm too lazy to check OS/400 right now, but on my WinNT box,
there are 3 of them.
   "Finalizer" (TID:0x1919320, sys_thread_t:0x83cdd0, state:CW, native
ID:0x21a) prio=8
       at java.lang.Object.wait(Native Method)
       at java.lang.ref.ReferenceQueue.remove(Unknown Source)
       at java.lang.ref.ReferenceQueue.remove(Unknown Source)
       at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
   "Reference Handler" (TID:0x19193b0, sys_thread_t:0x83b960, state:CW,
native ID:0x25c) prio=10
       at java.lang.Object.wait(Native Method)
       at java.lang.Object.wait(Unknown Source)
       at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
   "Signal dispatcher" (TID:0x19193e0, sys_thread_t:0x83b180, state:R,
native ID:0x1f4) prio=5

At one time, there was discussion about making the Os/400 JVM
use system threads. I don't know the status of this, but by
default (using the CL command or QSH), the system ensures that
a job that runs Java code is multi-thread capable before
starting the JVM. Which is why you seldom have to worry
about it AND why you get what could be perceived as 'extra' jobs

???
Anyone know if the JVM changed to use system threads or not for
its internal threads?
How about threads created by Java application code?

Obviously (or maybe not) if you use the JNI APIs to start your
own JVM, you are starting the JVM within your own process, and
you must take responsibility for ensuring that process is in
the correct state from a threading perspective (threads enabled
or not)

In addition, it seems much more common for Java code to utilize
threads than other languages because its just so much easier to
do correctly in Java.

RPG threads
===========
The nature of RPG is very much one that utilizes global storage
within the RPG module. There were some additions discussed
at one point of some enablers for RPG and threads.
1) An extension to declaration of variables such that
they would be similar to automatic variables in other
languages instead of global.
2) Restructuring of some of the RPG runtime control
structures and variables to allow thread safe access
to those features.
3) Compile time switches that cause the modules to perform
a big 'hammer lock' that would prevent more than one thread
from executing (or having on the call stack) the same module
at the same time.

Note that #3 basically defeats the purpose of threading
in my mind, because you probably DO want multiple
threads running the same code at the same time.

That said, I don't know what sort of changes have
occurred, or if you can modify your RPG code in
ways that help the above issues.

Summary
=======
So....
Basically, all that information combines into what I see as
pretty serious complexity __IF__ you try to mix traditionally
non-threaded application code with traditionally threaded
code.
Then, as you get further into the application design and test
more issues become apparent (like program startup/ending,
activation group issues, and hard core thread safety concerns).

If you stick to one or the other mode (traditionally threaded
code or traditionally non-threaded code), things tend to work
_surprisingly_ well...

Whew....



"Do you believe that my being stronger or faster has anything
 to do with my muscles in this place?" ... "Free your mind."
Laurence Fishburne as Morpheus in 'The Matrix'.

Fred A. Kulack  -  AS/400e  Java and Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@bresnanlink.net
AOL Instant Messenger: Home:FKulack  Work:FKulackWrk


Chanh_Le@countrywide.com@midrange.com on 11/22/2000 01:16:41 PM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   JAVA400-L@midrange.com
cc:
Subject:  Re: Calling a java pgm from RPG IV




I think we can call a CLP which only has a java command inside - wrapper.
Or we might create a string and call "QCMDEXC" inside an RPG.

According the thread issues:

>> Because of some RPG versus Java threading issues, I'd probably try the
CL
>> command first.

Could you explain a little bit in detail about RPG & java threading
problem.

Thanks.
CL

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---