Node:Command-line, Next:, Previous:Layout, Up:Top


Command-line

The WAS command-line programs which every WAS Administrator should know.

serverStatus.sh

TYPICAL USAGE
serverStatus.sh server1
HELP
serverStatus.sh -help

startServer.sh

TYPICAL USAGE
startServer.sh server1
HELP
startServer.sh -help
This is a good script, with a couple important exceptions. It very nicely tells you what it's doing and where it's sending output to, and the script returns when the app server is running successfully (unlike startup scripts for some other App servers).

Be aware that if you are running a default instance, you don't need your environment set up at all ($WAS_HOME will be determined by location of the startup script). However, if you are running a non-default instance, you need to set $WAS_HOME and then source $USER_INSTALL_ROOT/bin/setupCmdLine.sh (not $WAS_HOME/bin/setupCmdLine.sh!).

BEWARE! Many of the messages about the environment printed to the startup log (.../logs/server1/startServer.log) are WRONG. If you edit the IBM scripts, be aware that some variables (including $WAS_CLASSPATH) are obsolete and are not used at all.

If you have Oracle data sources, be aware that the Oracle JDBC drivers will not work unless you have $LD_LIBRARY_PATH and $ORACLE_HOME set and exported properly when startServer.sh is invoked.

If you run startServer.sh using sudo, then be sure to get the patched version of startServer.sh (as documented in the Installation HOWTO), otherwise your $LD_LIBRARY_PATH setting will be lost when you use sudo.

stopServer.sh

TYPICAL USAGE
stopServer.sh server1
HELP
stopServer.sh -help
The stopServer.sh program connects to the WAS SOAP service hostname that you supplied when you installed the WAS software. If stopServer.sh fails with a complaint that it can't access the SOAP service, then it is very likely because your IP address or host name or DNS has changed. If you supplied a name as hostname during installation, then make sure that that name resolves to the right IP address. Make sure that your server is accessible by using that IP address (like by telnet 1.2.3.4 5678, where 1.2.3.4 is the IP address and 5678 is the WAS SOAP port for your instance (see the installation HOWTO for how to determine and set your WAS port numbers).

dumpNameSpace.sh

Dumps all JNDI names.

TYPICAL USAGE
dumpNameSpace.sh -port 1234
OR
dumpNameSpace.sh For default instance running on default bootstrap port.

Where 1234 is your "BOOTSTRAP_PORT" (defaults to 2809). See the file $WAS_HOME/bin/wsinstance/<NODE>_<INST>_portdef.props if you are running an alternate instance and don't know your bootstrap port.

HELP
dumpNameSpace.sh -help
Don't expect dumpNameSpace to show you any reference names, i.e., what is coded in your .java. Only the JNDI names themselves are dumped.

ivt.sh

Verify server health. This command works only for the default instance. Even with the default instance, it will only work if you have the ivtApp.ear application installed and running.

TYPICAL USAGE
ivt.sh
HELP
None

ejbdeploy.sh

Builds all skeleton and stub classes needed for ejb-jar file(s).

TYPICAL USAGE
ejbdeploy.sh original.jar /tmp/z new.jar -cp a/lib.jar -quiet
OR
ejbdeploy.sh original.ear /tmp/z new.ear -cp a/lib.jar -quiet
HELP
ejbdeploy.sh -help

This program doesn't deploy anything. For each ejb-jar file, generates skeleton and stub class and inserts them into a copy of the ejb-jar. The generated skeleton and stub class files are of the form EJS*.class, _EJS*class, *_Stub*.class, *Tie.class. (The .java files for these classes are also created in the work area).

wsadmin.sh

wsadmin.sh gives you a JACL shell from which you can perform nearly any WAS administration interactively or with scripts. This is an advanced tool. See the separate section on wsadmin below.

ws_ant

TYPICAL USAGE
ws_ant
HELP
ws_ant -help
This gives help for the underlying ant, not for ws_ant.
This is a wrapper for whatever ant library lives in $WAS_HOME/lib (the name of the jar file doesn't matter). It makes available to you the ant targets documented at http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/javadoc/ae/com/ibm/websphere/ant/tasks/package-summary.html. Be aware that, for the most part, these targets suck. These targets are ant interfaces for wsadmin, but unlike wsadmin, these targets are not powerful at all because, in most cases, you can not change settings.

Most of the tasks will not work with alternative configuration instances. The classpath mechanism does not work for WsEjbDeploy, making it worthless.

The validation task is useful for ear files, but usually not for ejb jar files, since the mechanism for setting a class path does not work. This target also suffers from the same failing as that of validation by ejbdeploy.sh and assembly.sh-- often it complains of an internal error for no known reason.

ws_ant sets $WAS_HOME if it is not already set. So, if you are using the default instance (i.e., there is no $USER_INSTALL_ROOT), you can invoke ws_ant like /path/to/ws-home/bin/ws_ant without setting up your environment at all.

To use our Nextel ant build file, see my WAS Ant Builds at Nextel HOWTO.

If you have not upgraded Ant to 1.5, then definitely upgrade it (it has many important features )

To upgrade the version of ant used by WAS, get rid of the ant.jar in $WAS_HOME/lib (WAS) or $WSAD_SOFTWARE_ROOT/runtimes/base_v5/lib (WSAD), and put the following files into that directory. Make sure that you either remove ant.jar, or move it out of that directory (renaming it in that directory won't work because it will continue to be used).

  1. ant-153.jar, base jar file for Ant v. 1.5.3.
  2. optional-153.jar, optional jar file for Ant v. 1.5.3.
  3. ant-contrib-0.3.jar, v. 0.3 of the Ant contributed jar.
You can, of course, download these products direct from the authors at http://ant.apache.org/bindownload.cgi and http://sourceforge.net/project/showfiles.php?group_id=36177.

ps and kill

These are UNIX commands, not WAS commands. Like it or not, sometimes WebSphere gets stuck. In those cases, ps and kill can get you unstuck. 

     ps -eo pid,ppid,args | grep java     # Solaris
     OR
     ps axo pid,ppid,args | grep java     # Linux
     # Look for a process like ".../java -Xbootclasspath..." with ppid of 1.
     kill 1234    # Where 1234 is the desired pid
     kill -KILL 1234    # If the default signal (INT) fails to stop it.
Repeat until all the target java processes are gone. Do give it a little while to quit after a signal. If you are running multiple instances, then supply different args to ps in order to differentiate the desired instance's processes.

You should run the ps command right now so that you know what the processes look like when things are healthy. (Don't use the kill command unless stopServer.sh won't work).