Summary Overview |
5
|
Why this document was written |
5
|
What this document is intended to provide -- and not
provide |
5
|
How this document is designed |
5
|
The z/OS® focus of this document |
5
|
Where reference documentation is available |
5
|
Introduction to WSADMIN |
6
|
What WSADMIN is not |
6
|
If you have configured a Application Server for z/OS cell,
you have used WSADMIN |
7
|
The wsadmin.sh shell script |
7
|
Two ways to use WSADMIN -- interactive and batch |
7
|
Invoking the wsadmin.sh shell script from OMVS, Telnet, or
JCL |
8
|
A fourth way to invoke WSADMIN -- on another
platform |
9
|
Important: run wsadmin.sh under authority of Application
Server Administrator ID |
9
|
Connecting to server process port, or operating in "local
mode" |
9
|
When should one use "local mode" versus "remote
mode"? |
10
|
If connecting, which server process should we connect
to? |
11
|
If we operate in local mode (no connection), what
config HFS do we act against? |
12
|
Important: Do NOT use WSADMIN and Administrative Console
at the same time |
12
|
Using a scripting language |
13
|
Learning challenges |
13
|
Lesson 1: Starting Client and Exploring
Commands |
14
|
Access command line interface |
14
|
Invoke "Help" facility of WSADMIN |
14
|
Start WSADMIN client interface with -conntype of NONE |
15
|
List the applications installed in this cell |
16
|
Exiting the WSADMIN interactive client |
17
|
Concluding points on this lesson |
17
|
Lesson 2: Invoking WSADMIN in Batch Mode |
18
|
WSADMIN commands that follow the invocation of the shell
script |
18
|
WSADMIN commands held in a separate file |
19
|
Important point: WSADMIN by default expects files to be
in ASCII |
19
|
Create HFS file and enter commands |
19
|
Intentionally create error where EBCDIC used when
WSADMIN expects ASCII |
20
|
Use -javaoption switch to indicate source is in
EBCDIC |
20
|
WSADMIN commands inside JCL |
20
|
A look inside the BBODIAPP job |
21
|
Question: why no -javaoption in JCL to say commands are
in EBCDIC? |
22
|
Copy BBODIAPP job and modify it to do something simpler
at this point |
22
|
Pointing to an external file from a JCL batch job |
23
|
Concluding points on this lesson |
24
|
Lesson 3: Introduction to Jacl scripting |
25
|
Getting ready |
25
|
Simple setting of variable and putting variable back to
screen |
25
|
What happened in that last exercise? |
26
|
Setting multiple variables |
26
|
Parsing words out of a string |
27
|
Passing values in as parameters |
27
|
Using If-Else to validate the number of parameters passed
in |
28
|
Jacl lists -- an important way of providing options to
WSADMIN commands |
30
|
Using Jacl variables to break up long command
lines |
30
|
Jacl "list" function to the rescue |
31
|
Variable substitution into "list" function |
31
|
Nested options -- option lists inside and option
list |
32
|
Concluding points on this lesson |
34
|
Lesson 4: Installing an Application using $AdminApp
Object |
35
|
To connect to a server process or not ... that is the
question |
35
|
Which server process to connect to? |
35
|
If -conntype none used, does it matter which copy of
wsadmin.sh used? |
36
|
Important note concerning server security if enabled |
36
|
Simple install with minimum options |
36
|
Preliminary activities to ready your environment for
exercise |
36
|
Invoke "help" to understand the $AdminApp object
better |
37
|
Install MyIVT using a simple script file |
40
|
Uninstall MyIVT |
41
|
Determining what task options are applicable to
MyIVT.ear |
41
|
Finding out more about a particular task option |
41
|
Installing MyIVT.ear and mapping to a different Virtual
Host |
43
|
Uninstall application in preparation for next
exercise |
44
|
Using Jacl variables to construct the long command
line |
44
|
Jacl script that installs or uninstalls based on passed in
parameter |
45
|
Concluding points on this lesson |
47
|
Lesson 5: The $AdminConfig Object |
48
|
A little background on $AdminConfig |
48
|
What methods are on this object? |
48
|
How many different "configuration types"
exist? |
48
|
Does $AdminConfig require a connection to
a server process? |
49
|
Caution: z/OS is different type of environment from
distributed |
49
|
Synchronizing changes with nodes |
49
|
Node synchronization overview |
49
|
Initiating synchronization using WSADMIN |
50
|
Programmatically synchronizing with every node in the
cell |
51
|
Node Agent configuration settings that affect
synchronization intervals |
51
|
Exploring the VirtualHost type |
52
|
How can we know that VirtualHost is a type? |
52
|
What is the structure of the VirtualHost type? |
53
|
What is the value in what we just did? |
54
|
What is the minimum required to construct a VirtualHost
configuration type? |
55
|
Using WSADMIN to create a simple, no-alias Virtual
Host |
55
|
Determining the ID of the cell to provide as the
"parent" for the create method |
55
|
Jacl script to get the cell ID, then create no-alias
virtual host |
56
|
Listing the existing VirtualHost types (including your
new one) |
56
|
Using WSADMIN to determine the values assigned to an
existing virtual host |
57
|
Using the getid method to place the config ID of
default_host into a Jacl variable |
58
|
Using the show method to display all the attributes
held by the configuration object |
59
|
Using the showAttribute method to display a certain
kind of attribute |
59
|
Using the show and showAttribute methods to display
contents of host alias |
60
|
Creating a new virtual host complete with an HostName/Port
alias |
61
|
Understanding all the open and closing braces in create
VirtualHost command |
62
|
Jacl script with hard-coded attribute list |
62
|
Jacl script using variables to populate attribute
list |
63
|
Question: what if virtual host had multiple
hostname/port pairs? |
64
|
Using the modify method of $AdminConfig to add another
alias to the virtual host |
65
|
Changing the name of the virtual host |
65
|
Adding additional aliases to the virtual host |
66
|
Deleting the test virtual hosts created in this
lesson |
67
|
Jacl script to delete a virtual host |
67
|
Question: is it possible to delete multiple objects
with one command invocation |
68
|
Creating a new server by copying from an existing
server |
68
|
Simple example without node synchronization |
69
|
More automated example with node
synchronization |
69
|
Changing an application server's short name |
70
|
Changing an application server's Cluster Transition
Name |
72
|
Concluding points on this lesson |
73
|
Lesson 6: The $AdminControl Object |
74
|
Does requiring a connection to server process limit how I
might invoke $AdminControl? |
74
|
Which server process should we connect to? |
74
|
Starting a server in a Network Deployment
configuration |
75
|
Stopping a server in a Network Deployment
configuration |
76
|
Starting a Network Deployment server using batch JCL |
76
|
Starting a server in a Base Application Server node
configuration |
77
|
Stopping a server in a Base Application Server node
configuration |
77
|
Checking the status of a server process |
77
|
Starting an Application |
78
|
Stopping an Application |
78
|
Checking the status of an application |
79
|
Concluding points on this lesson |
79
|
Lesson 7: Digging Deeper into the $AdminApp
Object |
80
|
Installing a second copy of an application into a
cell |
80
|
Setting the JNDI name for an EJB |
80
|
Where are those values to be found in the EAR file
itself? |
82
|
Constructing $AdminApp install command
with change to JNDI name |
83
|
Mapping an EJB-ref to JNDI name |
83
|
Putting it all together -- install application, set JNDI
name, map reference to EJB |
84
|
Updating an existing application with a new copy |
86
|
Simple update |
86
|
Update of application and ignoring bindings in EAR
file |
87
|
Mapping an application to a data resource |
87
|
Format of MapResRefToEJB |
88
|
Example Jacl script that installs application and maps
resource reference |
89
|
Concluding points on this lesson |
89
|
Lesson 8: WSADMIN and Clusters |
90
|
What clusters are in your environment? |
90
|
What servers are members of that cluster? |
90
|
What nodes are those cluster members configured? |
90
|
Installing an application into a cluster |
91
|
Manually synchronizing with each known node of the
cluster |
91
|
Programmatically synchronizing every node |
91
|
Programmatically synchronizing to just the cluster
nodes |
91
|
Starting the members of a cluster |
92
|
Stopping the members of a cluster |
93
|
Checking the status of the cluster and cluster
members |
93
|
Appendix A: Exercises (available for
copy-and-paste) |
94
|
Lesson 2 Exercises |
94
|
Lesson 3 Exercises |
95
|
Lesson 4 Exercises |
95
|
Lesson 5 Exercises |
96
|
Lesson 6 Exercises |
100
|
Lesson 7 Exercises |
100
|
Lesson 8 Exercises |
102
|
More Information |
104
|
Tracing WSADMIN activites |
104
|
Turning tracing on or off |
104
|
Changing location of trace output |
104
|
Dynamically turning tracing on or off |
105
|
Tracing when WSADMIN client running on a distributed
platform |
105
|
When Global Security is enabled |
105
|
Authenticating the WSADMIN client to the SOAP
port |
105
|
Insuring client's ID has CA Certificate in its
keyring |
105
|
Using WSADMIN on distributed box when Global Security and
SSL enabled |
105
|
Document Change History |
106
|
Index |
107
|
Understanding what all the methods are, how to code the syntax for the
methods, and knowing what values to supply for the parameters is the
challenge in learning WSADMIN.
The WSADMIN scripting interface is common across all the platforms on
which WebSphere Application Server Version 5 runs. This is different than
in Version 4, where at one point in time the distributed platforms
migrated up to WSADMIN while the z/OS platform continued to use the older
interface.
WSADMIN being universal across the platforms is a good thing: it allows
the same script to be used in different environments. So, for example, a
script written for a test environment running on z/Linux may be reused
against a production z/OS server.
Same script used across different environments.
What WSADMIN is not
It is important to understand at this point what WSADMIN is not. It is
not a way to simply record and playback the mouse movements, mouse clicks
and keyboard entry of someone sitting at the Administrative Console of
Application Server. What the scripting interface provides is a way for
another program to accomplish administrative tasks by issuing commands
with keywords, options and parameters.
It does this by providing four Java "objects" -- AdminApp, AdminConfig,
AdminControl and Help. Each object has a number of "methods" that may be
invoked by your program (called a "script"):
The way in which WSADMIN is invoked is with the wsadmin.sh shell
script. In a Network Deployment configuration, you will have several
different copies of that shell script in the HFS:
Which you use is really a matter of personal preference. In this
document we most often instruct the use of the OMVS shell, but in truth a
Telnet terminal would work perfectly well. Using a JCL job to invoke
WSADMIN may also be used, and we illustrate that method in several places
in the document.
WSADMIN can be instructed to connect to a running server process, and
in fact we will do that quite a bit in this document. You pass in a -host
and -port parameter to accomplish this. That means that WSADMIN on
any server platform can connect to another server:
Invoking WSADMIN on a PC and connecting across the network to
Application Server on z/OS