Administrative scripting problems

Administrative scripting problems

+
Search Tips | Advanced Search
WASX7016E, WASX7017E, or WASX7209I: Jython scripting language error

"WASX7023E: Error creating "SOAP" connection to host" or similar error trying to launch wsadmin command line utility.

"com.ibm.bsf.BSFException: error while evaluating Jacl expression: no such method "<command name>" in class com.ibm.ws.scripting.AdminConfigClient" returned from wsadmin command.

WASX7022E returned from running "wsadmin -c ..." command, indicating invalid command.

com.ibm.ws.scripting.ScriptingException: WASX7025E: String "" is malformed; cannot create ObjectName.

"The input line is too long" error returned from the wsadmin command on a Windows platform.

WASX701E: Exception received while running file "scriptName.jacl"; exception information: com.ibm.bsf.BSFException: error while evaluating Jacl expression: missing close-bracket

WASX7015E: Exception running command: "source c: ..."; exception information: com.ibm.bsf.BSFException: error while evaluating Jacl expression: couldn't read file "c: ..."

Unexpected error CWSIV0806E in WebSphere log following deletion of an outbound service

Separator exception

Enabling authentication in the file transfer service

The format of "$AdminConfig list" output has changed for V6.0

You are not prompted for user ID and password after applying V6.0.2 service if you use an existing 6.0 profile

Required ports not defined when a new V5.0/V5.1 server is created

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

AWXJR0006E: The file, {0}, was not found.
WASX7022E: Problem running command "import sys" -- exception information: com.ibm.bsf.BSFException: unable to load language
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/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.

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.

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 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 appserver at startup. This is because some commands act upon running appservers. This error indicates that no connection could be established. To resolve this problem:

If you are not sure whether an appserver is running, start it by entering startserver servername 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 Network Deployment configuration, you will first need to start the deployment manager by running "startManager" or "startManager.sh" from the install_dir/bin directory. Then you can launch wsadmin immediately to connect to the deployment manager, or start a node and appserver to connect to.

If an appserver is running and you still get this error:

If you are running remotely (that is, on a different machine from the one running WAS), 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 you are not specifying a port number (using the -port option) when you start the wsadmin tool, the wsadmin tool uses the default port specified in install_dir/profiles/profile/properties/wsadmin.properties file, property name=com.ibm.ws.scripting.port (default value =8879).
The port that wsadmin should send on depends on the server process wsadmin is trying to connect to. For a single-server installation, wsadmin attempts to connect to the appserver process by default. To verify the port number:

Look in the file profile_root/config/cells/node/nodes/node/serverindex.html for a tag containing the property serverType="APPLICATION_SERVER".

Look for an entry within that tag with the property endPointName="SOAP_CONNECTOR_ADDRESS".

Look for a port property within that tag. This is the port wsadmin should send on.

In a ND installation, wsadmin launched from the bin directory on the ND installation attempts to send requests to the deployment manager by default. To verify the port number:

Get the hostname of the node on which the Deployment Manager is installed.

Use that hostname, look in profile_root/config/cells/cell/nodes/node/serverindex.html file for a tag containing the property serverType="DEPLOYMENT_MANAGER".

Within that tag, look for an entry with a property endPointName="SOAP_CONNECTOR_ADDRESS".

Within that tag, look for a "port" property. This is the port that the wsadmin tool should send on.

"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 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... wsadmin -c "$AdminApp install ....".
To correct this problem, escape the dollar sign with a backslash. For example: wsadmin -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.

"The input line is too long" error returned from the wsadmin command on a Windows platform

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. For example, if the product resides in the app_server_root directory, edit the app_server_root\bin\setupCmdLine.bat file as follows:
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:

...
...
Then edit the setupCmdLine.bat file residing in the bin directory of your profile as follows:
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 WAS installation. After editing the file, rerun the Profile Management Tool. If the same problem persists, reinstall WAS 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.

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.

WASX7015E: Exception running command: "source c: ..."; exception information: com.ibm.bsf.BSFException: error while evaluating Jacl expression: couldn't read file "c: ..."

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:
DeploymentManager WASX7029I: For help, enter: "$Help help" wsadmin>source c:/temp/test.jacl
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

In WAS Network Deployment V5.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 WAS ND, V5.0 and V5.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 V5.0 clients in your WAS ND environment, they will not be able to communicate with the secured file transfer application if global security is turned on.
In WebSphere Application Server V6.x, mixed cells are supported and file transfer has become a system application. If all of the nodes in the cell are of V5.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 WAS V6.x, the file transfer service is also supported for WAS 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 node server
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"
The format of "$AdminConfig list" output has changed for V6.0

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 WAS V6.0 to reflect changes to the output format.

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.
To keep the existing V6.0 profile and use the new prompt feature, 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
Required ports not defined when a new V5.0/V5.1 server is created

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. Add the following two entries to the serverindex.xml file in the profile_root/config/templates/servertypes/APPLICATION_SERVER/ directory:
<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.

When running the $AdminApp searchJNDIReferences command with the 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 appserver 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 wsdamin 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...
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"
WASX7022E: Problem running command "import sys" -- exception information: com.ibm.bsf.BSFException: unable to load language

This problem may be caused by a limitation on some UNIX platforms, for example, Linux, when attempting to use the Jython language. To workaround this problem, perform the following steps:
Check the number of open files that you are allowed to have on the machine, for example:
ulimit -a
Check the number of open files that you have set on your machine. The default value is 1024.
Change it to a higher number...
ulimit -n 2048
Try to use the wsadmin tool again with the Jython language.
Related concepts
Troubleshoot_and_support3240.html

Related tasks
Troubleshooting administration