|
> 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 +---
As an Amazon Associate we earn from qualifying purchases.
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.