Use this information if you are having problems starting or using the wsadmin tool.
If none of these steps fixes your problem, check to see if the problem has been identified and documented by looking at the available online support (hints and tips, technotes, and fixes). If you don't find your problem listed there please contact IBM support.
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
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.
The port that wsadmin should send on depends on the server process wsadmin is trying to connect to.
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.
If the command following -c appears to be valid, the problem may be caused by the fact that on Unix, using wsadmin -c to invoke a command that includes dollar signs results in the shell attempting to do variable substitution. 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 ...".
#let's misspell "Server" set serverName [$AdminControl queryNames type=Srever,*] $AdminControl getAttributes $serverName
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.
This error indicates that the Windows command line limit of 2048 characters has been exceeded, probably due to a long profile path used within the wsadmin.bat command. You may get this error when running wsadmin in a Windows command prompt or calling wsadmin from a .bat file, an ant build file, or Profile Management Tool. If this error results in running wsadmin other than from the Profile Management Tool, avoid the problem by using the Windows subst command, which allows you to map an entire path to a virtual drive. To see the syntax of the subst command, enter help subst from a Windows command prompt.
SET CUR_DIR=%cd% cd /d "%~dp0.." SET WAS_HOME=%cd% cd /d "%CUR_DIR%" @REM add the following two lines to workaround Windows 2K command line length limit subst w: %WAS_HOME% set WAS_HOME=w: ... ...
SET WAS_USER_PROFILE=... SET USER_INSTALL_ROOT=... SET WAS_HOME=app_server_root SET JAVA_HOME=app_server_root\java @REM add the following three lines to workaround Windows 2K command line length limit subst w: %WAS_HOME% set WAS_HOME=w: set JAVA_HOME=%WAS_HOME%\java ... ...
If this error occurred while running the Profile Management Tool, you have to rerun the Profile Management Tool to provide a shorter profile path with a shorter profile name. If this does not fix the problem, follow the same instructions above to edit the setupCmdLine.bat file in the bin directory of your WebSphere Application Server installation. After editing the file, rerun the Profile Management Tool. If the same problem persists, reinstall WebSphere Application Server with a shorter installation root directory path.
IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM Support page.
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.
This error is caused by using a backslash ( \ ) instead of a forward slash ( / ) when running the wsadmin command to source a Jacl script in a Windows® environment. The file path cannot contain the backslash ( \ ); for example, wsadmin> source c:\temp\test.jacl. The file path must use the forward slash ( / ) as the path separator; for example, wsadmin> source c:/temp/test.jacl.
To correct this problem use the forward slash ( / ) in the file path when using the wsadmin command to source a Jacl script in a Windows® environment:
app_server_root\bin>wsadmin WASX7209I: Connected to process "dmgr" on node sunCellManager01 using SOAP connector; The type of process is: Manager WASX7029I: For help, enter: "$Help help" wsadmin>source c:/temp/test.jacl
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.
You must use forward slashes (/) as your path separator. Backward slashes (\) will not work.
In WebSphere Application Server, Network Deployment Version 5.0.1 or later, the file transfer service was enhanced to provide role-based authentication. Two versions of the file transfer Web application were 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 and 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_namewhere "Xxx" is "On" or "Off".
wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationOn managedCell managedCellManager dmgr"or
wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationOn baseCell base server1"
wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationOff managedCell managedCellManager dmgr"or
wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationOff baseNodeCell baseNode server1"
If you have a script that parses the output of $AdminConfig list, such as $AdminConfig list Node, you might receive errors, such as "Node not found." Scripts should not parse the output of $AdminConfig; however, if you have a script that does this parsing, it must be updated for WebSphere Application Server V6.0 to reflect changes to the output format.
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.
com.ibm.SOAP.loginSource=prompt
WSAdminClientLogin { com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy required del egate=com.ibm.ws.security.common.auth.module.WSAdminClientLoginModuleImpl; };
SET JAASSOAP=-Djava.security.auth.login.config=app_server_root/properties/wsjaas_client.conf
Required ports not defined when a new V5.0/V5.1 server is created
You create a new V5.0 or V5.1 server using a default template in a mixed cell environment, and all of the required ports are not defined for the newly created server.
<serverEntries xmi:id="ServerEntry_3" serverName="default_5X" serverType="APPLICATION_SERVER"> <specialEndpoints xmi:id="NamedEndPoint_25" endPointName="BOOTSTRAP_ADDRESS"> <endPoint xmi:id="EndPoint_25" host="$(node.host.name)" port="2809"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_26" endPointName="SOAP_CONNECTOR_ADDRESS"> <endPoint xmi:id="EndPoint_26" host="$(node.host.name)" port="8880"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_27" endPointName="SAS_SSL_ SERVERAUTH_LISTENER_ADDRESS"> <endPoint xmi:id="EndPoint_27" host="$(node.host.name)" port="0"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_28" endPointName="CSIV2_ SSL_SERVERAUTH_LISTENER_ADDRESS"> <endPoint xmi:id="EndPoint_28" host="$(node.host.name)" port="0"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_29" endPointName="CSIV2_ SSL_MUTUALAUTH_LISTENER_ADDRESS"> <endPoint xmi:id="EndPoint_29" host="$(node.host.name)" port="0"/> </specialEndpoints> </serverEntries>
<serverEntries xmi:id="ServerEntry_4" serverDisplayName="default ZOS_5X" serverName="defaultZOS_5X" serverType="APPLICATION_SERVER" serverUniqueId="BB80B67909190083000000DC0010200209390F08"> <specialEndpoints xmi:id="NamedEndPoint_31" endPointName="BOOTSTRAP_ADDRESS"> <endPoint xmi:id="EndPoint_31" host="$(node.host.name)" port="2809"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_32" endPointName="SOAP_CONNECTOR_ADDRESS"> <endPoint xmi:id="EndPoint_32" host="$(node.host.name)" port="8880"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_33" endPointName="ORB_SSL_LISTENER_ADDRESS"> <endPoint xmi:id="EndPoint_33" host="*" port="0"/> </specialEndpoints> <specialEndpoints xmi:id="NamedEndPoint_34" endPointName="ORB_LISTENER_ADDRESS"> <endPoint xmi:id="EndPoint_34" host="*" port="0"/> </specialEndpoints> </serverEntries>
The xmi:ids must all be unique within this file.
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.
[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.
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"