You can use the wsadmin tool to configure and administer application servers, application
deployment, and server runtime operations.
About this task
The wsadmin tool provides the ability to automate configuration tasks for your environment by
running scripts. However, there are some limitations for using the wsadmin tool, including:
- The wsadmin tool only supports the Jython and Jacl scripting languages.
The Version 6.1 release of WebSphere Application Server represented the start of the deprecation process for the Jacl syntax that is associated with the wsadmin tool. The Jacl syntax for the wsadmin tool continues to remain in the product and is supported for at least two major product releases. After that time, the Jacl language support might be removed from the wsadmin tool. The Jython syntax for the wsadmin tool is the strategic direction for WebSphere Application Server administrative automation. The application server provides significantly enhanced administrative functions and tooling that support product automation and the use of the Jython syntax.
Deprecated feature: Jacl is deprecated and
Jython is the default
scripting language.
Avoid trouble: Not all of the
WebSphere® Application Server component classes are packaged in the same
.jar file. If you are going to be using the wsadmin tool to run Jython scripts,
include the jython.package.path system property on your wsadmin command to ensure that all of the
required JAR files are set to the jython package path during wsadmin
startup.
./wsadmin.sh -lang jython -javaoption
"-Djython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar"
If
you want to invoke WebSphere Application Server functions from different WebSphere Application Server classes that are packaged in
.jar files other than runtime.jar and
admin.jar, you can include multiple jar files in the path specified for the
jython.package.path system property, and separate them with a semicolon
(;).
./wsadmin.sh -lang jython -javaoption
"-Djython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar;com.ibm.ws.wccm.jar"
If
you want to invoke WebSphere Application Server functions in a jython script
using ws_ant, you can create a .prop text file, and include the following line
in this
file:
jython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar
Then
include the property file in the ant script xml file. For
example:
<taskdef name="wsadmin" classname="com.ibm.websphere.ant.tasks.WsAdmin"/>
<target name="main" >
<wsadmin conntype="NONE" lang="jython" failonerror="true" properties="/tmp/jython.prop"
script="/home/fsgapp/MSTWasBuild/project/scripts/socr/socr/jython/configure.py">
</wsadmin>
</target>
- The wsadmin tool manages the installation, configuration, deployment, and
runtime operations for application servers, deployment managers, administrative agents, and job
managers that run the same version or a higher version of the product. The wsadmin tool cannot
connect to an application server, deployment manager, administrative agent, or job manager that runs
a product version which is older than the version of the wsadmin tool. For example, a Version 7.x
wsadmin client cannot connect to a Version 6.x application server. However, a Version 6.x wsadmin
client can connect to a Version 7.x application server. This limitation exists because new
functionality is added to the wsadmin tool in each product release. You cannot use new command
functionality on application servers running previous product versions.
- The wsadmin tool operates at the deployment manager node level in a mixed-cell
environment. Do not run wsadmin at the application server node level to ensure that all command
functionality is available.
The wsadmin launcher supports several scripting objects, including the
AdminConfig, AdminControl, AdminApp, AdminTask, and Help objects. Scripts use these objects for
application management, configuration, operational control, and for communication with MBeans that
run in product processes. You must start the wsadmin scripting client before you perform any other
task using scripting.
Before starting the wsadmin tool with security enabled, review the topic SSL
considerations for WebSphere Application Server administrators and the topic Defining SSL security
for clients and servers.
In a flexible management environment, you can connect the wsadmin tool to a base
application server, deployment manager, administrative agent, or job manager process. If you do not
specify the port of the base application server or the profile name assigned to the job manager, the
wsadmin tool automatically connects to the administrative agent.
Avoid trouble: The application management design does not allow you to
install an EE specification level EAR or module that is at a higher level than the client. Client
code that runs in wsadmin reads the EAR file and uses introspection of the content to generate the
deployment configuration options that are applicable to that application. The client side code
cannot process a specification level that is higher than what that client supports.
Results
The wsadmin returns the following output when it establishes a connection to the server
process:
Jython example
output:
Applications currently installed:
DefaultApplication
ivtApp
query
WASX70311: For help, enter: "print Help.help()"
wsadmin>
Jacl example
output:
Applications currently installed:
DefaultApplication
ivtApp
query
WASX70311: For help, enter: "$Help help"
wsadmin>
If you receive the
message:
[ Unable to allocate an initial java heap of 268435456 bytes. ]
[ **Out of memory, aborting** ]
[ *** panic: JVMST016: Cannot allocate memory for initial java heap ]
CEE5207E The signal SIGABRT was received.
the
wsadmin scripting client was unable to start because the region size on your login is not large
enough to allocate the minimum heap size (-Xms ) that is specified on the Java Virtual Machine (JVM)
that is created when wsadmin starts. The default value for the -Xms option, as specified in the
wsadmin.sh file statement PERF_JVM_OPTIONS="-Xms256m -Xmx256m, is is 256 MB. To correct this
problem, log out of TSO, and then when you log back in to TSO try to increase the value of the
Size parameter on your login screen. If you cannot increase the value of the
Size
parameter on your login screen, check to see if any IEFUSI exits that prevents
you from increasing the value of this parameter.
If you are logging in by telnet to OMVS, the value that is used to determine the
address space size that your login receives is specified in the BPXPRMxx parmlib member. BPXPRMxx
controls the complete environment of z/OS UNIX. Therefore the value that is set for the
MAXASSIZE parameter determines the size of the address space. However, if you
are using RACF, the address size can also be set for an individual user in the respective RACF OMVS
segment. In this situation the value specified for the ASSIZEMAX parameter
indicates, in bytes, the address space size limit for that user. For example a setting of
ASSIZEMAX=0268435456 indicates the address space allocated to that user is
256 MB.