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.
This
figure illustrates the major components involved in a wsadmin 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.