× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Pete Hall


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.