Re: Excel/POI - Please Help The Drowning Man -- RPG400-L

Hi Barbara,

I brought this up as a possible solution to Arthur's problem, but when Ichecked my notes, it was for a different problem. I was having aproblem with a CL program that did a QSH 'ls /home' command and gettingerrno 3489.


When I googled it (with site:midrange.com), I found this:

> This sounds like the problem I was having a year or so ago, althoughit was> with V4Rx. When Qshell runs a Java program it creates a new job torun it

> in; if the subsystem it was running in already had its maximum number of

> jobs running, an error like this one occurred. (The "resource" inquestion

> was a job slot in a batch subsystem.)  Eventually I got tired of being
> called about this error and just did CHGSBSD MAXJOBS(*NOMAX) on all the
> batch subsystems.  This could be your problem, I suppose.
> - Paul Clapham http://archive.midrange.com/java400-l/200303/msg00060.html

Although my program didn't use java, I was running the CL program in asubsystem with maxact(1), and switching to a different subsystem solvedmy problem. That was back in February, and with the passage of time,the reference to Java stuck in my mind, but I forgot the part about Qshell.

So now I'm wondering about my problem back in February. If a CL programrunning in batch uses the QSH command, is that alone enough to startanother job? Or does the actual command being executed within Qshellmatter?


*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Barbara Morris wrote:

Jon Paris wrote:

That requirement relates to the RPG runtime not being threadsafe Bob.  So I
think it is only relevant when you are setting up an RPG procedure to be
called as a native method or when you are calling a Java method which may
subsequently call an RPG native method.

When you are simply calling Java methods I don't think it is an issue.


Thread issues can go beyond the static storage in an RPG module,
although that's all that THREAD(*SERIALIZE) protects from multi-thread
access.  I think it's a good idea to be aware of thread issues when
calling Java, and coding that keyword should raise the consciousness a
bit.  But you are right that if the called Java methods will _never_
call back to any native method, then there is no need to protect the
static storage in the module from access by multiple threads.

I do think the single threading in the job stream may be an issue though - I
think the JVM is effectively run in a separate job.


Not sure what you mean here, Jon.  If RPG calls Java using
EXTPROC(*JAVA), the JVM is in the same job as the RPG program.