I am pretty sure that I posted this before, when you were having issues
with Tomcat 7 initially. I do two things with Tomcat (regardless of
version). I issue this CL command (or similar) to invoke the shell script:
SBMJOB CMD(QSH +
CMD('/Apache/Tomcat/apache-tomcat-6.0.33/bin/catalina.sh
start')) JOB(TOMCAT) +
JOBQ(QSYSNOMAX)
And I have the following lines in the catalina.sh shell script :
# Java 6 settings if needed
export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
export -s CATALINA_HOME=/Apache/Tomcat/apache-tomcat-6.0.33
export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true
-Djava.version=1.6 -Xms256m -Xmx512m"
I am curious as to what led you down the path of changing the other
environment variables in CL since it is the shell script in catalina.sh
that will control (and override) all the other Java settings. It has
always seemed cleaner and easier to make the modifications in the shell
script and then invoke that script in your CL. At least that has been
my experience.
Sure, you *could* change the values through CL. Something like:
ADDENVVAR ENVVAR(CLASSPATH) +
VALUE('YourClassPathSettingsHere') LEVEL(*JOB) REPLACE(*YES)
ADDENVVAR ENVVAR(QIBM_RPG_JAVA_PROPERTIES) +
VALUE('-Djava.awt.headless=true;-Dos400.awt.native=true;')
REPLACE(*YES)
ADDENVVAR ENVVAR(JAVA_HOME) +
VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit') +
REPLACE(*YES)
But I prefer to change the shell script because it allows me to start
QSHELL, navigate to the folder containing the executable script and run
it knowing it will execute the same when invoked from CL. There is no
technical reason to do it except the QSHELL command line will show
errors and raise issues interactively which can head off debugging a CL
program that invokes the PASE environment (which I have always found
difficult to debug)
Did you have difficulty with that approach? The only other place that I
will occasionally tweak is my .profile in my home directory where I can
set the default environment for Java and other PASE invoked executables
but that is just so I don't have to monkey around with the environment
before starting QSHELL.
Pete Helgren
Value Added Software, Inc
www.petesworkshop.com
GIAC Secure Software Programmer-Java
On 6/18/2012 3:36 PM, James Lampert wrote:
You may recall that last week, I was going to great lengths to try and
get a CL to automatically locate a Java 1.6 JVM, and set it in the
job-level JAVA_HOME environment variable.
This is for a CL that starts Tomcat 7 (which requires Java 1.6 at minimum.
In resolving the crisis over the customer box on which Tomcat wasn't
starting, I found that the "catalina.sh" script for Tomcat needed these
lines (preferably in a separate "setenv.sh" file, rather than directly
in "catalina.sh"):
# Java 6 settings if needed
export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
export -s CATALINA_HOME=/wintouch/tomcat
export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true -Djava.version=1.6 -Xms256m -Xmx512m"
But it seems that the very first line of this block is overriding the
JAVA_HOME environment variable I'd so laboriously set in the CL program.
Which makes me wonder (1) if there's any actual reason to set JAVA_HOME
both places, and (2) if I could set CATALINA_HOME and JAVA_OPTS in the
CL, instead of the shell script, which would greatly simplify the
installation.
Can anybody either shed some light on this, or point me to an
appropriate document that would do so?
--
JHHL
midrange.com
