Before you begin
Make sure that all
WebSphere Application Server for z/OS server, administrator and client
user IDs (any user IDs that run WebSphere Application Server for z/OS
scripts) are run with environment variables LANG and LC_ALL both set
to the same locale based on code page IBM-1047. Settings based on
any other code page may cause the scripts to fail. See "Changing the
Locale in the Shell" in
UNIX System Services User's Guide for
more information.
About this task
The WebSphere Application Server wsadmin tool provides the
ability to run scripts. The wsadmin tool supports a full range of
product administrative activities.
The following figure illustrates
the major components involved in a wsadmin scripting solution:
Figure 1: A WebSphere
Application Server scripting solution
The wsadmin tool supports
two scripting languages: Jacl and Jython. Five objects are available
when you use scripts:
- AdminControl: Use to run operational commands.
- AdminConfig: Use to run configurational commands to create
or modify WebSphere Application Server configurational elements.
- AdminApp: Use to administer applications.
- AdminTask: Use to run administrative commands.
- Help: Use to obtain general help.
The scripts use these objects to communicate with MBeans that
run in WebSphere Application Server processes. MBeans are Java objects
that represent Java Management Extensions (JMX) resources. JMX is
an optional package addition to Java 2 Platform Standard Edition (J2SE).
JMX is a technology that provides a simple and standard way to manage
Java objects.
Important: Some wsadmin
scripts, including the AdminApp install, AdminApp update, and some
AdminTask commands, require that the user ID under which the server
is running must have read permission to the files that are created
by the user that is running wsadmin scripting. For example, if the
application server is running under user1, but you are running wsadmin
scripting under user2, you might encounter exceptions involving a
temporary directory. When user2 runs wsadmin scripting to deploy an
application, a temporary directory for the enterprise application
archive (EAR) file is created. However, when the application server
attempts to read and unzip the EAR file as user1, the process fails.
It is not recommended that you set the umask value of the user that
is running wsadmin scripting to 022 or 023 to work around this issue.
This approach makes all of the files that are created by the user
readable by other users. To resolve this issue, consider the following
approaches based on your administrative policies:
- Run wsadmin scripting with the same user ID as the user that runs
the deployment manager or application server. A root user can switch
the user ID to complete these actions.
- Set the group ID of the user that is running the deployment manager
or application server to be the same group ID as the user that is
running wsadmin scripting. Also, set the umask value of the user that
is running the wsadmin scripting to be at least a umask 027 value
so that files that are created by the wsadmin scripting can be read
by members of the group.
- Run wsadmin scripting from a different machine. This approach
forces files to be transferred and bypasses the file copy permission
issue.
To perform a task using scripting, you must first perform
the following steps:
What to do next
Before you perform any task using scripting, make sure that
you are familiar with the following concepts:
Optionally, you can customize your scripting environment.
For more information, see Scripting environment properties.
After
you become familiar with the scripting concepts, choose a scripting
language, and start the scripting client, you are ready to perform
tasks using scripting.