RE: cannot fork: too many processes error using qp2runpase()

I had a similar problem but used qsyswrk which is *nomax and that solved it.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Hall
Sent: Sunday, September 23, 2012 11:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: cannot fork: too many processes error using qp2runpase()

I think I found the answer to this. Well, I hope so, anyway. The job is running in a subsystem that only allows 10 jobs to run at a time, which would account for the "couldn't fork" error. Found some old conversations about similar issues. I've moved the job to the same subsystem where I run our tomcat server, which should easily be able to accommodate 50 or so threads. I'll find out for sure tomorrow, but it looks promising.

On Sun, 23 Sep 2012 20:39:57 +0000, Pete Hall wrote:

I have a shell script process that executes a java upload client. It
is executed from an RPGLE program via the qp2runpase API. The
QIBM_USE_DESCRIPTOR_STDIO environment variable is set to Y. The shell
script is the target of the qp2runpase API. It is executable and
contains #!/bin/sh in the first line. Of course, it works fine in the
test LPAR.

The script process breaks down like this 1. Main script is executed by
qp2runpase, and overrides stdout and stderr to files.
2. Main script starts a background process to monitor the stderr file.
a. The monitor script enters a sleep loop.
b. It checks the stderr file for messages every so often.
c. If anything bad appears in the stderr file
i. It signals the main script.
ii. It exits normally.
3. Main script starts a background process to run the java upload.
a. The upload script executes the java client in-line.
4. Main script enters a sleep loop and waits for a signal from either
of the background processes.

In production it never gets far enough to start java. I have a "verbose"
mode, which writes messages every time any of the scripts do
something, so I can tell what it did.

I see 2 messages in the stderr file.

The first is from the main script, where it attempts to load a small
library file (possibly file handle not available?). The message says
"<scriptname>[51]: cannot fork: too many processes" Line 51 in that
script contains . <library name> The library file contains two small
functions that don't do anything at all initially, but one of the
functions is used to write time-stamped messages to the stdout file,
and there are a couple of timestamped messages in it, so it looks as
though the library script is loaded. I can tell it came from the main
script, because of the message content.

The 2nd message is from the monitor script. It's the same message,
regarding the line where it loads the same library.

Here's the library script. Is there something wrong with it?
#!/bin/sh #
-------------------------------------------------------------------
# Set required environment variables for execution via the Qp2RunPase
API # ---------------------------------
initEnv() {
if [ -z "$TZ" ] ; then
export TZ='<CST>6<CDT>,M3.2.0,M11.1.0'
fi

if [ -z "$PATH" ] ; then
export PATH='/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/
bin/X11:/usr/sbin:.:/usr/bin:/usr/local/sbin:'
fi
}

# -------------------------------------------------------------------
# Send a timestamped message to STDOUT or STDERR #
---------------------------------
# $1 is the message text # If $2 is present, send to STDERR. Otherwise
send to STDOUT printMsg () {
TS=`date +'%F %T %z'`
if [ -n "$2" ] ; then
printf "${TS}: $1">&2
else
printf "${TS}: $1"
fi
}

I've tried adding the ALWMLTTHD(*YES) parameter to the SBMJOB command
for the RPGLE program that runs this mess. Somewhere I saw a hint that
it may make a difference, but I'm not very hopeful, as it works in
test without that. I'll find out Monday night at zero dark 30. I also
changed the timestamp assignment to explicitly specify the location of
date, but it's located in the first directory in $PATH, and the
initEnv() method call is the first executable line in the main script.

There are supposed to be 200 file handles available by default.
There's no way it's using more than that.

Anyone have a clue why this is happening?

I'm thinking things to try are running DosSetRelMaxFH(),
pthread_setcanceltype() and pthread_setcancelstate() before executing
qp2runpase(). I'm not sure what the cancel type and state could have
to do with this, but the docs hint that it might do something beneficial.

Thanks