WebSphere Application Server for z/OS (hereafter called WebSphere z/OS) contains a process model unique to the WebSphere Application Server family. This process model allows WebSphere Application Server (hereafter called Application Server) to leverage many z/OS unique services and provides Quality of Service (QoS) expected by customers on the z/OS platform. This overview describes the differences between the z/OS process model and the other WebSphere Application server platforms. It also describes how to administer the WebSphere z/OS process model. The article assumes you have some familiarity with the z/OS operating system.
Overview of z/OS and distributed WebSphere
The non-z/OS platforms (hereafter called distributed platforms) are built on a single process model. This means the entire server runs in one single Java Virtual Machine (JVM) process. However, WebSphere z/OS is built using a federation of JVMs, each executing in a different operating system process that collectively represents a single server instance.
Each JVM in the federation is not identical because one JVM is given preference and holds the external endpoints of the server. This JVM is called the controller (controller region). The other JVMs are either servants (servant regions) or adjunct (control region adjunct process). The adjunct is a special case of a servant process. Customer-installed applications execute only in the servant regions. The adjunct process houses the platform messaging component. Figure 1 shows a sample server and its associated JVMs.
Figure 1. WebSphere Application Server for z/OS V6.0.1
Meanings and uses of the various regions
In the model shown in Figure 1, all inbound and outbound communication occurs in the controller process, with the exception of JFAP and JCAI in version 6. Therefore, client requests arrive in the controller process, and are then dispatched, with help from the z/OS Workload Manager (zWLM) operating system component, to one of the potentially many servant processes. The number of servant processes is dynamically managed by zWLM. Servant processes are added or subtracted according to demand, as measured against installation-specified performance goals. These are expressed as a WLM policy.
Each servant process in this model is identical, hosting the necessary application server components to enable the J2EE application programming model. In this sense, the servant region is closely related to the entire distributed platforms application server. The servant processes rely on the control region for numerous services, such as communication, security, and transaction control.
Newly added in version 6.0.1 is the adjunct process, which hosts the internal messaging component and handles the JFAP and JCAI protocols. The NodeAgent, Proxy Server (v6.0.2), and JMSServer (v5.x) do not have servant or adjunct regions. They exist only in a control region. On z/OS, a standalone Location Service Daemon (Daemon) is provided. The Daemon provides the CORBA location service in support of Remote Method Invocation and Internet Inter-ORB Protocol (RMI/IIOP).
WebSphere allows you to perform four different operations on a server: Start, Stop, stopImmediate, and Terminate. Each of those operations is accessible via the Administrative Console and wsadmin scripting. Start and Stop also have shell script driven interfaces.
WebSphere z/OS supports a fifth way to perform all operations, MVS system commands. A z/OS operator can issue a command on the MVS console to start any server. The WebSphere-provided methods are actually all wrappers to these MVS system commands, making the MVS system commands the single way to start, stop, stopImmediate, or terminate a server.
Figure 2 shows a standard START command. In this case, it is the default START command of an application server.
Figure 2. Application Server START command
The JCL Procedures (PROC) that starts the server is created during customization via the customization dialog. One is created for each region (control, servant, adjunct) and one for the Daemon. The PROCs are generic in that they can start any server for a given node. The Deployment Manager generates its own set of PROCs, while the nodes use the base server's PROCs. You can use any 8 characters or less for the PROC. BBO6ACR is the default.
You can use the JOBNAME to identify the server. By default, WebSphere uses the server shortname unless it changed. The servant region will have the same job name as the control region, except an "S" will be appended. Similarly, an adjunct will have an "A" appended.
Control Region Jobname: BBOS001 Servant Region Jobname: BBOS001S Adjunct Region Jobname: BBOS001A |
The ENV is a unique string that identifies the server. The string is composed of the cell short name, node short name, and server short name. If the server short name is changed via the Administrative Console, the corresponding ENV parameter is also changed.
The following section shows sample START commands for the WebSphere servers.
Deployment Manager:
START BBO6DCR,JOBNAME=BBODMGR,ENV=PLEX1.PLEX1.BBODMGR |
The Deployment Manager always has a different PROC (BBO6DCR versus BBO6ACR) than any other server. The default job name for the Deployment Manager is BBODMGR. As there is only one Deployment Manager in a ND cell, there is no numeric attached to the JOBNAME.
Node Agent:
START BBO6ACR,JOBNAME=BBON001,ENV=PLEX1.SY1.BBON001 |
By default, each new node agent created is given the next free number in the sequence, for example, BBON002, BBON003 to BBONXXX.
Application Server:
START BBO6ACR,JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001 |
By default, each new Application Server created is given the next free number in the sequence, for example, BBOS002, BBOS003 to BBOSXXX.
Proxy Server v6.0.2:
START BBO6ACR,JOBNAME=BBOX001,ENV=PLEX1.SY1.BBOX001 |
By default, each new Proxy Server created is given the next free number in the sequence, for example, BBOX002, BBOX003 to BBOXXXX.
JMS Server v5.x:
START BBO6ACR,JOBNAME=BBOJ001,ENV=PLEX1.SY1.BBOJ001 |
By default, each new JMS Server created is given the next free number in the sequence, for example, BBOJ002, BBOJ003 to BOJXXX. Note that only the control region START command is needed to start a server. The control region will in turn start the Daemon, servants, and adjuncts if needed.
All the WebSphere servers (Deployment Manager, NodeAgent, Application Server, Proxy Server, and JMSServer) support the STOP command. To issue the command, the syntax is:
STOP BBOS001 P BBOS001 |
Where STOP or P is the command, and BBOS001 is the control region JOBNAME.
The stopImmediate function on a z/OS server is mapped to the CANCEL command. CANCEL will stop a started task immediately.
CANCEL BBOS001 C BBOS001 |
Where CANCEL or C is the cancel command, and BBOS001 is the job name for the control region.
The TERMINATE command is the last resort function to stop a running server. On a WebSphere distributed server, the terminate function terminates a server by calling an operation system sigkill.
On z/OS, use the terminate function after CANCEL has been issued multiple times without success. When you issue TERMINATE against a z/OS server, two commands will be issued. The first command to be called is the stopImmediate, the second is the TERMINATE command. This is the last chance at CANCEL before FORCE is issued. Note that a FORCE command being issued might require you to re-IPL the system.
The TERMINATE command is issued only from the NodeAgent, as opposed to both Stop and stopImmediate, which are driven by the target server itself. Therefore, you cannot terminate the Deployment Manager or the Base Application Server. You can only terminate managed servers, such as federated application servers, proxy servers, and JMS servers.
All of these commands (START, STOP, stopImmediate, TERMINATE) are defined in the server.xml file for a particular server. You can change them to suit your specific environment. For example, if you want the server to be canceled when a user clicks Stop on the Administrative Console, you could redefine the STOP command.
Similarly, a customer might want to append argument to their stopImmediate (CANCEL) command to append the ARMREST parameter. This allows WebSphere to call exactly the command suited to a customer environment when STOP, stopImmediate, or TERMINATE is called via scripting or the Administrative Console. These same commands are also called when performing an application rollout or RippleStart.
Using the commands on the Administrative Console
You can view and modify the defined START, stopImmediate, and TERMINATE commands on the Process Definition panel for each address space. Inside the control region, you will find:
startCommand START <PROC NAME> startCommandArgs JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001 stopCommand STOP BBOS001; CANCEL BBOS001 stopCommandArgs <empty> stopImmediate STOP BBOS001; CANCEL BBOS001 terminateCommand FORCE BBOS001 terminateCommandArgs <empty> |
You can change any of these commands. For example, if your particular setup requires a shorter START command, or you want to create similar commands that are easier to remember, changing and saving the new START command here allows WebSphere to issue it when you click Start server on the Administrative Console or via scripting. The STOP command and stopImmediate command are stored in the same XML stanza. They are delimitated by a semi-colon. Figure 3 shows the process definition panel for a controller region. Using this Administrative Console panel, you can redefine the START, STOP, stopImmediate, and TERMINATE commands.
Figure 3. Administrative Console Process Definitions panel
This article covered the WebSphere z/OS process model. The process model allows a great deal of flexibility and integration with the z/OS environment and maintains the server interface familiar to the z/OS system operator. It also covered various parts of the federated JVM model and the default naming schemes used. The ability to customize the process model allows you to closely integrate WebSphere z/OS with a customer's own environment and their own internal corporate policies.
- WebSphere Application Server for z/OS product page: Provides product information.
- WebSphere Application Server for z/OS v6.0.x Information Center: Provides product documentation.
- developerWorks WebSphere Application Server zone: Provides technical and how-to information for developers.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
