Re: java and the interactive subsystem

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