Use this information if you are having problems starting
or using the wsadmin tool.
What kind of problem are you having?
If you do not see your problem here:
- If you are not able to enter wsadmin command mode,
try running wsadmin -c "\$Help wsadmin" for help in verifying
that you are entering the command correctly.
- If you can get the wsadmin command prompt, enter $Help help to
verify that you are using specific commands correctly.
- wsadmin commands are a superset of Jacl (Java Command Language),
which is in turn a Java-based implementation of the Tcl command language.
For details on Jacl syntax beyond wsadmin commands, refere to the
Tcl developers' site, http://www.tcl.tk. For specific details relating
to the Java implementation of Tcl, refer to http://www.tcl.tk/software/java.
- Browse the install_dir/profiles/profile_name/logs/wsadmin.traceout
file for clues.
- Keep in mind that wsadmin.traceout is refreshed (existing log
records are deleted) whenever a new wsadmin session is started.
- If the error returned by wsadmin does not seem to apply to the
command you entered, for example, you receive WASX7023E, stating that
a connection could not be created to host "myhost," but you did not
specify "-host myhost" on the command line, examine the properties
files used by wsadmin to determine what properties are specified.
If you do not know what properties files were loaded, look for the
WASX7326I messages in the wsadmin.traceout file; there will be one
of these messages for each properties file loaded.
WASX7016E, WASX7017E, or WASX7209I:
Jython scripting language error
The following errors may
occur when you run this Jython script:
Jython script
"profile_root/bin/wsadmin.sh
-lang jython -profile profile_name -host host_name -f script_file.py"
Error
Messages
WASX7209I: Connected to process "server1" on node
node_name using SOAP connector; The type of process is:
UnManagedProcess
WASX7016E: Exception received while reading file
"script_file.py"; exception information:
sun.io.MalformedInputException
WASX7017E: Exception received while running file
"script_file.py"; exception information:
com.ibm.bsf.BSFException: exception from Jython: Traceback
(innermost last): File "<string>" line 89, in ? NameError: log
These
errors can occur because there are UTF-8 characters in the file that
are not valid. The default codepage for RHEL 3 is UTF-8 (en_US.UTF-8).
When doing a text file read through Java™ code, the program assumes
all characters are UTF-8 encoded. There might be one or more characters
in the file that are not part of the UTF-8 specification, causing
the load to fail. An easy way to determine if a character that is
not valid is causing the error is to enter export LANG=C and run the
script again. If you determine that the problem is a character that
is not valid:
- Open a new text reader on the file.
- Read it one character at a time.
- Print the character that is not valid.
- When you press the back characters, you get the exception and
will then know which of the characters is causing the error.
- Remove any characters that are not valid, then run the script
again
"WASX7023E: Error creating "SOAP" connection
to host" or similar error trying to launch wsadmin command line utility
By
default, the wsadmin utility attempts to connect to an application
server at startup. This is because some commands act upon running
application servers. This error indicates that no connection could
be established.
To resolve this problem:
- If you are not sure whether an application server
is running, start it by entering startserver.sh server
short name from the command prompt. If the server is
already running, you will see an error similar to "ADMU3027E: An instance
of the server is already running".
- If you are running a z/OS configuration,
you will first need to start the deployment manager by issuing the
following command from a command prompt on the MVS console:
START dmgr_proc_name,JOBNAME=server_short_name,
ENV=cell_short_name.node_short_name.server_short_name
Note: This command must be entered on a single line. It is split
here for display purposes.
Then you can launch wsadmin immediately
to connect to the deployment manager, or start a node and application
server to connect to.
- If an application server is running and you still get this error:
- If you are running remotely (that is, on a different machine from
the one running WebSphere® Application Server), you must use the -host hostname option
to the wsadmin command to direct wsadmin to the right physical server.
- If you are using the -host option, try pinging the server machine
from the command line from the machine on which you are trying to
launch wsadmin to verify there are no issues of connectivity such
as firewalls.
- verify that you are using the right port number to connect to
the WebSphere Application Server process:
- If security is enabled, verify that the TSO or
telnet userid that invokes the scripting client has a keyring by the
name that is specified in the ssl.client.props file. The
keyring must be correct to establish the SSL connection. The default
name for the keyring is WASKeyring. This keyring contains the certificate
authority certificate for the administrative server.
"com.ibm.bsf.BSFException: error while
eval'ing Jacl expression: no such method command name in
class com.ibm.ws.scripting.AdminConfigClient" returned from wsadmin
command.
This error is usually caused by a misspelled command
name. Use the $AdminConfig help command to get information
about what commands are available. Note that command names are case-sensitive.
WASX7022E
returned from running "wsadmin -c ..." command, indicating invalid
command
If the command following -c appears to be valid,
the problem may be caused by the shell attempting to do variable substitution.
Variable substitution can occur on Unix System Services if wsadmin
-c invokes a command that is enclosed in double quotes and includes
dollar signs. To confirm that this is the problem, check the command
to see if it contains an unescaped dollar sign, for example: wsadmin
-c "$AdminApp install ....".
To correct this problem, escape
the dollar sign with a backslash. For example:
wsadmin -c "\$AdminApp
install ...".
Note: When the command is enclosed in
single quotes, the shell does not attempt to do variable substitution.
Therefore, you do not need to escape the dollar sign. Example: wsadmin.sh
-c '$AdminApp install ...'
com.ibm.ws.scripting.ScriptingException:
WASX7025E: String "" is malformed; cannot create ObjectName
One
possible cause of this error is that an empty string was specified
for an object name. This can happen if you use one scripting statement
to create an object name and the next statement to use that name,
perhaps in an "invoke" or "getAttribute" command, but you don't check
to see if the first statement really returned an object name. For
example (the following samples use basic Jacl commands in addition
to the wsadmin Jacl extensions to make a sample script):
#let's misspell "Server"
set serverName [$AdminControl queryNames type=Srever,*]
$AdminControl getAttributes $serverName
To correct this error, make sure that object name strings
have values before using them. For example:
set serverName[$AdminControl queryNames node=mynode,type=Server,name=server1,*]
if {$serverName == ""} {puts "queryNames returned empty - check query argument"}
else {$AdminControl getAttributes $serverName}
For details on Jacl syntax beyond wsadmin commands, refer
to the Tcl developers' site, http://www.tcl.tk.
WASX701E: Exception received while running
file "scriptName.jacl"; exception information: com.ibm.bsf.BSFException:
error while evaluating Jacl expression: missing close-bracket
This
error is caused by a mix-up between the code page that the scripting
client expects to see and the code page in which the Jacl script was
written.
To fix this problem, set the
-Dscript.encoding=script
codepage option in the wsadmin.sh or wsadmin.bat file to
the code page of the Jacl script. The following guideline will help
you to determine the code page of the script:
- If the script was written in the OMVS interface using the OEDIT
editor, the code page is IBM-037. In this case, set the option to
the following: -Dscript.encoding=Cp037
- If the script was written in a telnet session to the OMVS interface
using the VI editor, the code page is IBM-1047. In this case, set
the option to the following: -Dscript.encoding=Cp1047
- IF the script was written on a personal computer, or any other
ASCII machine, and was transferred to the host as a text file, the
code page is IBM-1047. In this case, set the option to the following: -Dscript.encoding=Cp1047
- If the script was written on a personal computer, or any other
ASCII machine, and transferred to the host in binary format, the code
page is ISO-8859-1 (ASCII). In this case, you do not need to set the
option because the default is ASCII. You should review other possible
reasons for this error.
Unexpected error CWSIV0806E in WebSphere
log following deletion of an outbound service
This error
occurs when an exception is issued for destination MPOutBoundServicePortDestination,
on messaging engine trueliesNode01.server1-FVTSIBus01, on bus FVTSIBus01,
for endpoint activation:
com.ibm.websphere.sib.exception.SINotPossibleInCurrentConfigurationException:
CWSIP0111E: The destination with name MPOutBoundServicePortDestination
is being deleted on messaging engine {1}.
You can ignore
this error; it is benign.
Separator exception
You must
use forward slashes (/) as your path separator. Backward slashes (\)
will not work.
Enabling authentication
in the file transfer service
The file transfer service provides
role-based authentication. Two versions of the file transfer web application
are provided. By default, the version that does not authenticate its
caller is installed. This default supports compatibility between
the WebSphere Application Server, Network Deployment, Version 5.0 and
Version 5.0.1 or later. Turning the file transfer authentication
on is recommended to prevent unauthorized use of the file transfer
application. However, if you have any Version 5.0 clients in your
WebSphere Application Server, Network Deployment environment, they
will not be able to communicate with the secured file transfer application
if global security is turned on.
In WebSphere Application Server
Version 6.x, mixed cells are supported and file transfer has become
a system application. If all of the nodes in the cell are of Version
5.0.1 or later, you can activate authentication in the file transfer
service by redeploying the file transfer application at the deployment
manager. The compatible version is shipped in the ${app_server_root}/systemApps/filetransfer.ear
directory. The secured version is provided in the ${app_server_root}/systemApps/filetransferSecured.ear
directory.
Also in WebSphere Application Server Version 6.x,
the file transfer service is also supported for WebSphere Application Server, Express as long as the node
is not federated into a managed cell. If this node becomes federated,
it will make use of the deployment manager file transfer.
A
wsadmin Jacl script is provided to help you redeploy file transfer.
The script is redeployFileTransfer.jacl and you can find it in the
${app_server_root}/bin
directory. After the deployment manager and all the nodes are at
Version 5.0.1 or later, you can deploy the secured file transfer
service by running the script. The syntax for running the script from
the bin directory includes the following:
wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationXxx
cell_name node_name server_name
where "Xxx"
is "On" or "Off".
For example, when running the script to enable
use of the filetransferSecured.ear, the syntax is similar to the following
example:
wsadmin -profile redeployFileTransfer.jacl -c
"fileTransferAuthenticationOn managedCell managedCellManager dmgr"
or
wsadmin -profile redeployFileTransfer.jacl -c
"fileTransferAuthenticationOn baseCell base server1"
If
you want to go back to run the file transfer service without authentication,
you can run the script as shown in the following example:
wsadmin -profile redeployFileTransfer.jacl -c
"fileTransferAuthenticationOff managedCell managedCellManager dmgr"
or
wsadmin -profile redeployFileTransfer.jacl -c
"fileTransferAuthenticationOff baseNodeCell baseNode server1"
You are not prompted for user ID
and password after applying V6.0.2 service if you use an existing
6.0 profile
If security is enabled, executing a .bat file
requires a user ID and password. On V6.0.2, a new feature is introduced
to prompt you for a user ID and password if they are not supplied
in the command line. However, this feature is not available for profiles
that were created at the 6.0 level.
Property files for profiles
created at the V6.0 level are not updated after applying the V6.0.2
refresh pack.
There are two solutions to this problem:
- Create a new profile after applying the V6.0.2 service. This new
profile contains all the updated property files and you will then
be prompted for a user ID and password.
- If you want to keep the existing V6.0 profile and use the new
prompt feature, you must manually update three files:
- for app_server_root/properties/soap.client.props,
add the following line:
com.ibm.SOAP.loginSource=prompt
- for app_server_root/properties/wsjaas_client.conf,
add the following lines:
WSAdminClientLogin {
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy required del
egate=com.ibm.ws.security.common.auth.module.WSAdminClientLoginModuleImpl;
};
- for app_server_root/bin/setupCmdLine.bat add
the following line:
SET JAASSOAP=-Djava.security.auth.login.config=app_server_root/properties/wsjaas_client.conf
When running the $AdminApp searchJNDIReferences
command with the Java Naming and Directory Interface (JNDI) name of
a message destination, the message destination reference is not returned
This
problem occurs when the command $AdmnApp searchJNDIReferences is run
with the JNDI name of a message destination. The command cannot collect
the message destination reference that is defined in the application
deployment descriptor. The message destination that you configured
for the application server is defined with a message destination link
on not one element, but two: both a message-driven bean (MDB) and
a message destination reference.
Currently there is no workaround
for this problem. The $AdmnApp searchJNDIReferences command cannot
return a reference for a message destination that is defined on two
elements.
AWXJR0006E: The file,
{0}, was not found.
This problem occurs when you attempt
to configure a JACC provider for the Tivoli Access Manager using the
wsadmin tool in a deployment manager environment with or without nodes
added. You enter a deployment manager node name, for example,
t54Manager,
instead of an asterisk (
*) for all nodes. The wsadmin command
finishes successfully but when you try to add a new node and start
the node, or start an existing node, you receive an error in the nodeagent
SystemOut.log file similar to the following:
[12/7/05 17:09:51:266 CST] 0000000a SystemOut O AWXJR0006E The file,
C:\cc_was602\WebSphere\AppServer\profiles\AppSrv01\etc\tam\amwas.t54Node01_.amjacc.pr
operties, was not found.
[12/7/05 17:09:51:266 CST] 0000000a distSecurityC E SECJ0391E: Error when setting
the Policy object to the providers policy implementation {0}. The exception is
{1}.
[12/7/05 17:09:51:281 CST] 0000000a distSecurityC E SECJ0324E: Error during Java
2 Security and Dynamic Policy initialization.
To workaround
this problem, unconfigure the existing Tivoli Access Manager configuration
and configure it again using an asterisk (
*) for the node
name, for example:
wsadmin.bat -user wsadmin -password pw1 -f enableTAM.jacl "*" TAMHostName:7135"
TAMHostName:7136:1" "cn=wsadmin,o=ibm,c=us" "o=ibm,c=us" "sec_master"
sec_master pw1 "9990:9999"
WASX7017E: Exception received
while running file "<application stopping script>"; exception
information: javax.management.MBeanException com.ibm.ws.exception.RuntimeWarning:
Application <appname> not started
While using scripting,
this error is issued when you stop an application that is already
stopped or start an application that is already running.