|
On Sun, 2005-08-21 at 09:59 -0400, Steve Richter wrote: > I want to use Java in place of RPG. For green screen and sql > programming. To read and write from a display file I would use JNI to > call ILE procedures that used the "C" based recio functions to read > and write display files. Should work great right? > > Talking about this with the Java guru where I am working I am told it > cant be done. Java on the 400 is multithreaded. The interactive > subsystem and display file i/o on the 400, either by design or because > or operating system bugs, cannot be used in a multithreaded setting. > Hence, Java cannot be used, no way no how, for display file > programming on the 400. Is this correct? This assertion seems to be substantively correct. IBM warns that calling functions that are not threadsafe from a multithreaded application is potentially bad for your health. I would have included the link, but the InfoCenter doesn't seem to want to give out proper links, so I've included the text: Begin quote: Using global mutexes to run functions that are not threadsafe One alternative you should consider when you need to call a function that is not threadsafe is using a global mutex to run these functions. You might try locking a mutual exclusion (mutex) that you call the FOO MUTEX whenever you call foo(). This works if you know everything about the internal parts of foo(), but for general operating system functions, this still is not a completely safe solution. For example, application program interface (API) foo() is not threadsafe because it calls API bar(), which calls threadUnsafeFoo(). The threadUnsafeFoo() function uses certain storage and control blocks in an unsafe way. In this example, those storage and control blocks are called DATA1. Because the API threadUnsafeFoo() is unsafe, any application or system service that uses foo() is not threadsafe because using it with multiple threads may result in corrupt data or have undefined results. Your application also uses a threadsafe API or system service that is called wiffle(). Wiffle() calls waffle(), which accesses storage and control blocks DATA1 in a threadsafe manner. (That is waffle() and a group of other APIs use an internal DATA1 MUTEX). Your application does not know the underlying DATA1 connection between foo() and wiffle() system services. Your application therefore does not lock the FOO MUTEX before calling wiffle(). When a call to foo() (holding the FOO MUTEX) occurs at the same time as a call to wiffle(), the application's use of the not threadsafe function foo() causes DATA1 and whatever it represents to be corrupted. As complex as this scenario is, consider how complex resolving failures is when you do not know the internal details of all the functions involved. Do not try to make operating system services or functions threadsafe by using your own serialization. End Quote I thought that perhaps the "Dynamic Screen Manager" or "User Interface" API's might perhaps be threadsafe, but they indicate quite clearly on their documentation that they are not. Therefore, it's probably not a good idea to create a 5250 application in java. If you think about it, 5250 has been around for a very long time compared to the multithreading capability in i5/OS. I suspect it would be a big project to go back and make all of the internal code that runs 5250 sessions threadsafe. Regards, Rich
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.