Multi threading problem calling RPG program from Websphere

[Guest.Visitor]

Do a DSPSRVPGM on both copies of that service program. Is the working one using ACTGRP(*NEW) and the bad one using something else besides *NEW? Do you see any differences? Just a guess. Chris

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Thanks , but it is the same object residing in different libraries, for the different environments. All other service programs also run under the main websphere application server job in the offending environment, it does not run under the spawned websphere jobs as it is suppose to do. Regards

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

How is it possible to have the same exact physical object in two libraries? I think what you really have is 2 distinct objects with the same name in 2 libraries. How did copy create the 2nd copy? CRTDUPOBJ? Compiled from same source code? That's why I'm saying to a DSPSRVPGM, because you really have 2 distinct objects, not one. Does one module not contain "H Thread(*Serialize)" ? What I'd REALLY like to know, is in what context is the service program being called? From a java servlet instance (IE: probably not threadsafe)? From a servlet request session object? etc. Saying the WAS is calling the service program is like saying "wine from California". It's a pretty big state, can you be more specific? Chris

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Yes, sorry, it is compiled from the same source. ( i did recompile it, everywhere, to make sure it is the same , when we were busy trying to figure out the problem) It does not contain "H Thread(*Serialize)" Spoke to the java programmers. The RPG prgram is called via a "JCI connector" in a J2EE environment (using PCML) Regards

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Yes, sorry, it is compiled from the same source. ( i did recompile it, everywhere, to make sure it is the same , when we were busy trying to figure out the problem) Ok, I'll ask one more time...then I give up. Is a DSPSRVPGM on each service pgm object indentical except for the library name? Check the activation group, user profile, modules, etc... And, it's my understanding that any RPG program that interacts with java should use "H Thread(*Serialize)". Chris

[B.Morris]

Multi threading problem calling RPG program from Websphere

deonfourie wrote: > > Yes, sorry, it is compiled from the same source. > ( i did recompile it, everywhere, to make sure it is the same , when we were busy trying to figure out the problem) > > It does not contain "H Thread(*Serialize)" > If you are running RPG in multiple threads, you must code thread(*serialize) in _every_ RPG program that might be called. There are no exceptions. You cannot use OPM RPG. You must also ensure that everything you do is thread-safe. Read all the information about threads in the ILE RPG Programmer's Guide (look under "thread" in the index), then read the information in the iSeries Info Center about threads.

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Thanks for the help ! "*Serialize" solved my transactional problems ! The initial problem, of the service programs running under the main Websphere job, instead of the spawned jobs, still occurs. This happens on any of the various RPG service program requests serviced by the one Websphere application server instance.The other Websphere instance works perfectly ?! I'm a bit worried about it, as it might cause performance problems,as it now waits for the one thread to complete. I'm also worried that it might cause the main Websphere job to crash, if any of the RPG service programs falls over for some reason. Thanks again for the help.

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Hi, we are experiencing problems when a RPG service program is called from Websphere application server (version 6.0.2).I'm no expert on WAS, If somebody can point me in the right direction , it would be much appreciated. We got two instances of WAS running on the same machine. One for testing and one production version. We got an internal and distributed environment sending in transactions that are being serviced by Websphere application server. As I understand it the main server job( Websphere application Server job- QEJBSVR) , will spawn servicing jobs (qzrcsrvs), according to the workload. The RPG service programs would then run under the spawned jobs. This works as described above in our one WAS environments. In the other environment, the servicing jobs are being spawned, but the RPG service programs are running under the main Websphere application server job, instead of the spawned jobs. I tested this by storing the job number in my RPG service program (and debugging the main WAS job via STRSRVJOB). It stores the different spawned job numbers in the one environment, but the other it stores the main server job's number. This creates problems, if an error occurs in one transaction, the whole websphere application server comes to a standstill. It also creates other transactional problems. We compared the Websphere setup between the two environments, we could't find anything different.Is there something we missed during setup of the environment? Any help would be appreciated. regards

[Guest.Visitor]

Multi threading problem calling RPG program from Websphere

Hi Barbara, What about Java calling a CL or CLLE program directly (IE: through ProgramCall class)? How is that made threadsafe? Thanks! Chris

[B.Morris]

Multi threading problem calling RPG program from Websphere

Chris Ringer wrote: > > What about Java calling a CL or CLLE program directly (IE: through ProgramCall class)? How is that made threadsafe? Thanks! > CLP and CLLE are thread-safe as long as the commands they use are thread safe. See http://publib.boulder.ibm.com/infoce...rzahwsafco.htm I'm pretty sure that when using the ProgramCall class, the called program runs in a different job from the Java program. I think (but don't know) that at least by default, the called programs would all run in same thread of the called program's job. I don't know if there are ways to use ProgramCall to call in different threads of the called program job.