Java and RPGLE

[Guest.Visitor]

Tom, My understanding is that any program (module) in the call stack needs to have been compiled with Thread(*Serialize) or "unpredictable" results may occur (which I believe rules out CL programs). That's why data queues are so attractive. It's a clean hand off. Java writes to the data queue, RPG pulls it off the data queue and vice versa. Chris

[nandelin]

Well, if that's what the manual says, I guess you should use thread(*serialize) when calling Java methods from RPG, but it sounds backwards to me. I would have only used thread(*serialize) for RPG procedures being called from Java.

[Tom Daly]

Data queues are nice, I agree. But in this case that's probably not going to be an option. (a different story for a different day) I have no problem with the THREAD(*SERIALIZE). If that's the requirement then that's all there is to it, no prob. What's confusing me is this "any modules that might be called during interactions with java." Interactions... what exactly does this mean? Within the job? the program ? the service program? an activation group? Whaaat? I'll keep hunting the manuals for something definitive. Thanks for the feedback though. Tom D.

[Guest.Visitor]

I misread the question. I thought it said Java calling RPG. I would think that only the RPG module calling the Java method would need Thread(*Serialize). And regarding modules, every program and service program is comprised of modules. Do a DSPPGM or DSPSRVPGM and take a look. Even if you do a CRTBNDRPG, the system creates a module and then a program and then deletes the module behind the scene. H-Specs can apply to both the module and program objects. Chris

[R.Daugherty]

There was a pretty good thread on this awhile back where Barbara ended up answering those sort of questions. Any RPG called from Java (or any potentially multiple threaded environment) has to be serialized due to non-reentrant cycle code in RPG programs. The interaction I think is a broad term that refers to the possibility of RPG code being caused to be executed more than once within a job by multiple Java threads. My vague recollection is that it doesn't really enable multiple simultaneous execution of RPG code but is a safety measure to ensure that the code is not incorrectly accessed by another thread while currently executing, as in a second thread is on hold until an RPG program called from the first thread terminates. I don't recall the reason for the RPG calling Java to be serialized unless it's needed to setup the environment properly for transferring execution to a threaded environment or just the reverse of requiring called RPG to be threaded for the return. rd

[Guest.Visitor]

Since RPG is designed to be a single threading program, the primary purpose of "Thread(*Serialize)" inside RPGLE is to protect global variables you define from simultaneous accessed coming from different Java threads. These global variables includes File you defined in F-specs which will have file pointers data fields etc in addition to all the variables you defined globally. There are also hidden global variables in which RPGLE compiler is using at runtime such as instruction (code) pointers and data (variable) pointers. In Java "Thread(*Serialize)" syntax is equivalent to keyword "synchronize". Hope this helps. Gio

[Tom Daly]

In the Websphere Development Studio: ILE RPG Programmer's Guide there is a caution that all RPGLE modules that contain calls to Java methods must specify THREAD(*SERIALIZE). It then goes on to say that this also applies to "any modules that might be called during interactions with java." This is where things get hazy. Where is the boundary where multithreading is required? If serialized modules are in a service program must all other modules in the service program also be serialized? Does a program using the service program also require serialization? Thanks. Tom D.

[Guest.Visitor]

FYI. I've heard RPG in V6R1 has "Multi-threaded Support". Not sure what that means, but sounds intriguing. Chris