I'm running RUN14 and changing only the JZOS_HOME variable. Everything else seems correct as it stands. The file libjvm.so is sitting there in /usr/lpp/java/J1.4/bin/classic, but it's not being found.
Setting LOGLVL=+I (the letter I) causes no additional output except one line in SYSOUT stating that "log level has been set to: I".
What to do?
...Ed
libjvm.so STILL not found
-
Guest
Here's a follow-up to my query:
This is the SYSOUT output:
JZOSVM14(N): log level has been set to: I
JZOSVM14(N): Copyright (C) 2004 Dovetailed Technologies LLC. All ri...
JZOSVM14(N): JZOS Version 1.2.1
JZOSVM14(I): Region requested = 32M, Actual below/above ...
CEE3501S The module libjvm.so was not found.
From entry point JzosVM::initializeVMArgs() at compile unit offset +0
address 0B50252C.
The first part of the JCL is unchanged from the sample except for JZOS_HOME:
//JAVA EXEC PROC=EXJZOSVM,VERSION='14',LOGLVL='+I',
// JAVACLS='com.dovetail.jzos.testing.HelloWorld'
//STDENV DD *
. /etc/profile
export JZOS_HOME=/u/cybsv01/jzos
export JAVA_HOME=/usr/lpp/java/J1.4
export PATH=/bin:"${JAVA_HOME}"/bin:
LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin
LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic
LIBPATH="$LIBPATH":"${JZOS_HOME}"
export LIBPATH="$LIBPATH":
CLASSPATH=
for i in "${JZOS_HOME}"/*.jar; do
CLASSPATH="$CLASSPATH":"$i"
done
export CLASSPATH="$CLASSPATH":
...
...Ed
This is the SYSOUT output:
JZOSVM14(N): log level has been set to: I
JZOSVM14(N): Copyright (C) 2004 Dovetailed Technologies LLC. All ri...
JZOSVM14(N): JZOS Version 1.2.1
JZOSVM14(I): Region requested = 32M, Actual below/above ...
CEE3501S The module libjvm.so was not found.
From entry point JzosVM::initializeVMArgs() at compile unit offset +0
address 0B50252C.
The first part of the JCL is unchanged from the sample except for JZOS_HOME:
//JAVA EXEC PROC=EXJZOSVM,VERSION='14',LOGLVL='+I',
// JAVACLS='com.dovetail.jzos.testing.HelloWorld'
//STDENV DD *
. /etc/profile
export JZOS_HOME=/u/cybsv01/jzos
export JAVA_HOME=/usr/lpp/java/J1.4
export PATH=/bin:"${JAVA_HOME}"/bin:
LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin
LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic
LIBPATH="$LIBPATH":"${JZOS_HOME}"
export LIBPATH="$LIBPATH":
CLASSPATH=
for i in "${JZOS_HOME}"/*.jar; do
CLASSPATH="$CLASSPATH":"$i"
done
export CLASSPATH="$CLASSPATH":
...
...Ed
Ed -
I had thought that the +I level would dump the environment prior to creating the JVM, but this is not true! You will need to use the trace level (+T) to see the environment prior to creating the JVM. I apologize for causing this confusion, I will look into changing this in a subsequent release.
If you verify that the environment variables look good, then here are a few things that you might check -
1) verify that your job's userid has read access to the to libjvm.so file (and all enclosing directories) and that its marked executable.... this file should have access '755'. Also, make sure that the userid has a USS segment; verify this by using the id to log into a USS shell.
2) Check for messages in the job log AND system log that might help figure out why the loader couldn't use the libjvm shared library. If you have somehow marked the JZOSVM14 load module as APF authorized (AC=1 and authorized library), then the .so libraries must match. Under this condition, later levels of z/OS will write messages to the system log that will help you figure out what's wrong.
3) Verify that the 'java' command-line launcher for JDK 1.4 works under a USS shell. Use the 'java -version' command from a USS shell to see what maintenance level you have applied and check that that is up-to-date and that you have the necessary IBM-recommended prereqs for Java 1.4 installed. Here's a link to a forum entry that might help:
http://www.jzos.com/forum/viewtopic.php?t=129
I hope this helps.... its normally not this hard
I had thought that the +I level would dump the environment prior to creating the JVM, but this is not true! You will need to use the trace level (+T) to see the environment prior to creating the JVM. I apologize for causing this confusion, I will look into changing this in a subsequent release.
If you verify that the environment variables look good, then here are a few things that you might check -
1) verify that your job's userid has read access to the to libjvm.so file (and all enclosing directories) and that its marked executable.... this file should have access '755'. Also, make sure that the userid has a USS segment; verify this by using the id to log into a USS shell.
2) Check for messages in the job log AND system log that might help figure out why the loader couldn't use the libjvm shared library. If you have somehow marked the JZOSVM14 load module as APF authorized (AC=1 and authorized library), then the .so libraries must match. Under this condition, later levels of z/OS will write messages to the system log that will help you figure out what's wrong.
3) Verify that the 'java' command-line launcher for JDK 1.4 works under a USS shell. Use the 'java -version' command from a USS shell to see what maintenance level you have applied and check that that is up-to-date and that you have the necessary IBM-recommended prereqs for Java 1.4 installed. Here's a link to a forum entry that might help:
http://www.jzos.com/forum/viewtopic.php?t=129
I hope this helps.... its normally not this hard
-
Guest
Thanks for the quick feedback.
Using "+T" does work, and it tells me that I don't have access to the /etc/profile script, and indeed I have no access whatsoever to that file.
The USS guy is back in the office on Monday, and he might be willing to give me execute access to it. What is this for, by the way?
...Ed
Using "+T" does work, and it tells me that I don't have access to the /etc/profile script, and indeed I have no access whatsoever to that file.
The USS guy is back in the office on Monday, and he might be willing to give me execute access to it. What is this for, by the way?
...Ed
/etc/profile sets up default environment variables for USS.
You can eliminate calling from your //STDENV script if you make sure that you have all of the standard/required environment variables set. In fact, USS admins tend to throw everything in there and you end up running a huge script for setting up things only required by Websphere, so sometimes its best not to call it anyway
Standard environment variables that you need (that I know of) are:
export PATH=/bin:/usr/sbin
export LIBPATH=/lib:/usr/slib
export NLSPATH=/usr/lib/nls/msg/%L/%N
export LANG=C
export TZ=CST06CDT (or whatever you use)
These should be sufficient for running Java batch. Others may be required if you use sockets or DB2.
You can eliminate calling from your //STDENV script if you make sure that you have all of the standard/required environment variables set. In fact, USS admins tend to throw everything in there and you end up running a huge script for setting up things only required by Websphere, so sometimes its best not to call it anyway
Standard environment variables that you need (that I know of) are:
export PATH=/bin:/usr/sbin
export LIBPATH=/lib:/usr/slib
export NLSPATH=/usr/lib/nls/msg/%L/%N
export LANG=C
export TZ=CST06CDT (or whatever you use)
These should be sufficient for running Java batch. Others may be required if you use sockets or DB2.
-
Guest
(Re: z/OS Java storage usage)....
Java allocates its storage above the line, and when you say REGION=32M, you may not actually get 32M above the line... installation exists can often change this. This is why, when the JZOS launcher starts, it prints a little report saying what you requested and got above and below the line. You can also set the LE option RPTSTG(ON) to request a storage report when your job finishes, which will give you details on what you actually used.
And BTW, SDK 1.4 uses alot more storage than SDK 1.3 on z/OS.
Java allocates its storage above the line, and when you say REGION=32M, you may not actually get 32M above the line... installation exists can often change this. This is why, when the JZOS launcher starts, it prints a little report saying what you requested and got above and below the line. You can also set the LE option RPTSTG(ON) to request a storage report when your job finishes, which will give you details on what you actually used.
And BTW, SDK 1.4 uses alot more storage than SDK 1.3 on z/OS.