Wsadmin

The wsadmin tool is a command shell for the purpose of performing systems administration on all the artifacts in a IBM WebSphere Application Server (WAS) cell. It gets its name from the name of the shell script that invokes this command shell. This command shell can execute connected to a WAS cell or completely disconnected from a WAS cell (local mode). The wsadmin tool can be used to execute scripts written in Jacl and Jython, or it can be used interactively to execute individual commands. These scripts and commands perform administrative tasks like application deployment, configuration changes and run-time monitoring and control of IBM WAS.

wsadmin and wscp

The wscp stands for WebSphere Control Program. It was used in older versions of WebSphere Application Server like Version 4.0 and Version 3.5. It was used for configuration as well as run-time operations. The wsadmin tool replaced wscp in WebSphere Application Server Version 5.0 and all subsequent versions. The wsadmin tool can perform almost all of the tasks which can be done through the browser based administrative console, and it can perform some tasks that the administrative console cannot do.

Invoking wsadmin

There is a copy of the shell script that executes wsadmin in the bin directory of WAS install root and in the bin directory of every profile. With the exception of stand alone installations of WAS, wsadmin is almost always invoked from the bin directory of the deployment manager's profile. To invoke wsadmin in interactive mode,

1. Open the command line window of the machine in which IBM WebSphere Application Server is already installed.
2. Change directory to: <IBM WebSphere Profile Path>/bin/ (This will almost always be the bin directory of the deployment manager's profile)
3. Execute the file named wsadmin.[sh |bat] . See invocation syntax for available options.
4. You will see a wsadmin command line. Any commands you type will execute immediately. If you make configuration changes, those changes will not take effect unless you invoke the save command of the AdminConfig script object.

Invocation syntax

After invocation of wsadmin the command-line window will show the following text:

wsadmin [-h(help)] [-?] [-c <commands>] [-p <properties_file_name>] [-profile <profile_script_name>] [-profileName <profile_name>] [-f <script_file_name>] [-javaoption java_option] [-lang language] [-wsadmin_classpath classpath] [-conntype SOAP [-host host_name] [-port port_number] [-user userid] [-password password] RMI [-host host_name] [-port port_number] [-user userid] [-password password] NONE]

Options

The text written between squared brackets ([...]) are called options of the wsadmin tool.

• -? is used to get help for the particular syntax.
• -c assigns to run a command, there may be more than one -c exist for multiple command assignments.
• -p describes the Java properties file.
• -profile denotes a profile script. It executes before the command. For example, first the profile script would run then the -c runs.
• -profileName denotes the name of profile for which the wsadmin tool would run. This will help to access the wsadmin tool of a profile other than the profile you are currently in.
• -f assigns name of a script. The -f must be used once.
• -javaoption designates a Java non-standard or standard option. The -javaoption could be more than one.
• -lang specifies scripting language. It may be Jacl or Jython.
• -wsadmin_classpath is used to assign additional classes for scripting operation.
• -conntype assigns connection type. It may be SOAP, RMI or NONE.

     *If SOAP or RMI, then give relevant host_name, port_number, userid and password.
     *If NONE, then it will run in local mode.

• -jobid is used for keeping track of invocation of wsadmin. It is situated at the beginning of wsadmin log file.
• -tracefile assigns log file name and location for the log output.
• -appendtrace: If true, then it will append the trace at the end of a log file. If false, then it will override the log file for the invocation of wsadmin.

Five script objects of wsadmin

The wsadmin has five script objects to execute various administrative operations: AdminControl, AdminConfig, AdminApp, AdminTask and Help.

• AdminControl is used for operational control of all of the different kinds of running objects throughout an IBM WAS cell. AdminControl interfaces with MBeans (for Managed Bean). It is used to start or stop servers, to initiate synchronization with the master repository, to purge connection pools, to interface with diagnostic providers, and many other tasks. The AdminControl object is not available when wsadmin is run in local mode. It cannot control any WAS artifact that has not yet started.
• AdminConfig is related to configuration-oriented part of the IBM WAS. Creating new node and renaming the node are an example of AdminConfig related work.
• AdminApp is related to application-oriented part of the IBM WAS. It deals with applications. Installing, uninstalling, modifying and administering the applications are related to AdminApp.
• AdminTask was Introduced with IBM WAS V6.1. It has simplified the administration (though wsadmin). For example, It is very trouble-free to change Multiple Virtual Storage system name directly from the node which was very difficult without AdminTask.
• Help is very helpful to decide syntax problem related to above mentioned objects.

Two Modes of wsadmin

The wsadmin could be operated by two modes; a Remote mode and a Local mode.

• Use: The Remote mode is used when IBM WAS's Deployment Manager (Dmgr) is running. The Local Mode is used when the server is in down status.
• How to enable: The Remote mode is connected through TCP network connection while the Local mode does not need TCP connection.
• Advantages:
  • Remote mode: It can be accessed from the same or other LPAR. Two Remote mode clients will never face conflict. Their respective changes will be intellectually handled by the IBM WAS.
  • Local mode: It would not have any problems related to SSL certificates. It can work even when the server is down.
• Disadvantages:
  • Remote mode: The IBM WAS must not be in down status. There may be an issue of SSL certifications conflict.
  • Local mode: It will not work efficiently with multiple access because in the multiple access through Local mode the synchronization of changes may create a serious issue. The Local mode is weaker than Remote mode in respect of the security.

Scripting languages: Jacl and Jython

The wsadmin supports Jacl (an alternate implementation of TCL written in Java) and Jython (Java, Python) scripting languages. The choice of Jacl or Jython may depend on the programmer's comfortability. The Java/Java EE or C programmer may be more comfortable with Jython whereas Tcl experts may prefer Jacl. Though the script syntax is different, Jacl and Jython are equally powerful. The IBM Jacl to Jython Conversion Assistant program is used to convert wsadmin Jacl scripts into Jython.

Changing default language

In IBM WebSphere Application Server Version 6.1, the Jacl is deprecated. To use Jython as the scripting language, either of the two following ways.

• You may mention Jython in the option -lang of wsadmin invocation syntax. This is not a permanent change because it remains effective for that particular session only. As the wsadmin invoked again it will take Jacl as a scripting language.
• The other way is, to change default language as the Jython instead of Jacl.

To change default language, consider the following steps: (It is for Unix based systems.)

• Be in the following directory: <IBM WebSphere Profile Path>/DeploymentManager/profiles/properties
• Edi the file wsadmin.properties
• open it and you will find: com.ibm.ws.scripting.defaultLang=jacl. Just write jython instead of jacl.
• FTP that modified file and the changing default language is completed.
• Keep in mind that this method would change scripting language permanently to Jython.

Basic difference between Jacl and Jython syntaxes

Here, five basic commands (for getting help for the relevant objects) are written in their particular syntaxes. The case-sensitiveness in the scripting must be the crucial thing to be taken care of.

Jacl	Jython
$Help help	print Help.help()
$AdminConfig help	print AdminConfig.help()
$AdminTask help	print AdminTask.help()
$AdminControl help	print AdminControl.help()
$AdminApp help	print AdminApp.help()

Proficiency in scripting

Points to keep in mind

• The case-sensitiveness of the script syntax.
• It is a good practice to assign commands in a script and run that script using wsadmin -f <scriptfile> rathen than running each commands individually using wsadmin -c <command>. So, prefer wsadmin -f <scriptfile> to get faster execution.
• Always remember to save your changes. To save the changes, you need to validate those changes then save it. If the changes are not validated then the message will be popped out. In this case, there may be several reasons those have generated the conflicts. For example, you have created an application server profile and you have given some name and if there is another Application Server with a same name already exists, then the validation will not be completed successfully and the error message will be generated. If you have assigned same port numbers then also this kind of problem would occur.
• Use the command, AdminConfig.save ( ) (If Jython is used.) or $AdminConfig save ( ) (If Jacl is used.), periodically for persisting updates of configuration.

External links

• WebSphere Application Server v6.1 Documentation
• WebSphere Application Server v7 Documentation
• WebSphere Application Server Administration using Jython