Making the DMGR “Mobile” · Making the DMGR “Mobile ... 1 dictionary.com. Why bother? Because...

WebSphere Application Server for z/OS V6.1(There are a few potential differences for V7 ... see page 21)

Making the DMGR “Mobile”Making the DMGR “Mobile”Making the DMGR “Mobile”Making the DMGR “Mobile”(One that can be started on a different MVS image if you need to)

This document can be found on the web at:www.ibm.com/support/techdocs

Search for document number WP101140 under the category of "White Papers"

Version Date: June 24, 2016See "Document Change History" on page 24 for a description of the changes in this version of the document

Written by the WebSphere Application Server for z/OS Support Team at the

IBM IBM IBM IBM Advanced Technical SkillsAdvanced Technical SkillsAdvanced Technical SkillsAdvanced Technical Skills

Gaithersburg,Gaithersburg,Gaithersburg,Gaithersburg, MD MD MD MD

The WebSphere for z/OS support team at the Washington Systems Center consistsof: John Hutchinson, Mike Kearney, Louis Wilen, Lee-Win Tai, Mike Loos and Don

Bagwell. Mike Cox, Distinguished Engineer, serves as technical consultant andadvisor.

For questions or comments regarding this document, send e-mail to Don Bagwell [email protected]

Table of Contents

22Example of simple script to change DMGR host and Daemon host values . . . . . . . . . . . . . . . . . . . . . . .

22Using batch JCL to invoke WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22Miscellaneous Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21WAS z/OS V8.5 and Making the DMGR Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21Changing the DMGR’s configured system name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21IPC Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21WAS z/OS V7 and Making the DMGR Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20Step 10 - Test the restarting of the DMGR on the other MVS image . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20Step 9 - Restart the servers in the nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19Step 8 - Use the syncNode.sh shell script to synchronize to the changes out to the nodes . . . . . .

19Step 7 - Restart the DMGR and its Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19Step 6 - Exit WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18Step 5 - Use WSADMIN to update the host name for the Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17Step 4 - Update DMGR node host name using WSADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17Step 3 - Stop all the servers in the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16Step 2 - Update TCP PROFILE in preparation for use of Sysplex Distributor . . . . . . . . . . . . . . . . . . . .

16Step 1 - Back up your configuration HFS for each node in the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15Overview of the process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15All the other requirements of a mobile DMGR still needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15Case #2 - Updating an Existing Configuration to Provide a Mobile DMGR . . . . . . . . . . . . . . . . . . . .

14Restarting the DMGR on the other MVS image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14Revisit the issue of the Daemon instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13Other enablers of starting the DMGR on another image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12TCP/IP PROFILE configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12Construction of the rest of the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11Construction of the DMGR node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10Port allocation -- important to know for VipaDistribute definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10Sysplex Distributor "generic IP" name in spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10DMGR configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9The sample cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9Case #1 - Configuring for DMGR Mobility From the Beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8Node Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8Deployment Manager's Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7Key Elements That Allow DMGR Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6Not covered -- move of just the DMGR to a different MVS image with no Daemon instance . . . . . . . . . . . . . .

5Not covered -- move of DMGR and its Daemon to a different MVS image . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5Two scenarios we're not covering in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5Only two MVS images? What about between three or four images? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5Two cases -- configuring at time of creation, and modifying after the fact. . . . . . . . . . . . . . . . . . . . . . . . .

5Scenario that we're covering in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5The necessity of testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4The need for the same version and maintenance level on both LPARs . . . . . . . . . . . . . . . . . . . . . . . . . . .

4What's involved? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4The core of the issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4Why bother? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3The basics of what we're talking about here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3Definition of "mobile" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3Restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3IMPORTANT POINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

WP101140 - Making the DMGR “Mobile”

Section: MainVersion Date: Friday, June 24, 2016

- 1 -© 2010, IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

24Document Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




Overview

IMPORTANT POINT

Having a “Mobile DMGR” for V7 is possible, but at the present time it may require additional steps.See “WAS z/OS V7 and Making the DMGR Mobile” on page 21 for more.

Restriction

Sysplex Distributor does not support UDP traffic, which is needed for Intelligent Managementcommunication. If you using Sysplex Distributor for a mobile Deployment Manager and want to usethe Intelligent Management plugin for web servers or ODR, then for Intelligent Managementcommunication to work properly the Sysplex Distributor must be owned by the TCPIP stack theDeployment Manager. The ownership of the Sysplex Distributor can be changed/moved using aVARY TCPIP,,SYSPLEX,DEACTIVATE command.

Definition of "mobile"

mo·bile - adjective - "capable of moving or being moved readily" 1

The basics of what we're talking about here

Imagine a two-LPAR WebSphere for z/OS configuration that looks something like this:

MVS Image

CR SR

AppServer

MVS Image

CR SR

DMGR

CR

Node Agnt

CR

Node Agnt

CR

Daemon

CR

Daemon

CR SR

AppServer

Now imagine you tried to start the DMGR over on the other MVS image:

MVS Image

CR SR

AppServer

MVS Image

CR

Node Agnt

CR

Node Agnt

CR

Daemon

CR

Daemon

CR SR

AppServer

CR SR

DMGR

Would it work? Yes ... it can work and work well. But it depends on how you configure it. And that'swhat this paper is about.




1 dictionary.com

Why bother?

Because it's a key element to a highly available design. While it's true the DMGR is not critical tothe steady-state operations of your cell, it is key to the normal management and care of your cell.The ability to start the DMGR on other MVS images enhances the HA posture of your cell.

The core of the issue

The key to this is making use of Sysplex Distributor and the VipaDistribute function of TCP/IP so theDMGR can be started on the other LPAR and still be accessible.

Without that, the Deployment Manager will be locked to the LPAR-specific IP host name where itwas first built. That means when it's moved to the other LPAR it'll fail to start.

What's involved?

Here's a quick summary of what's needed to support a mobile DMGR:

� The use of Sysplex Distributor and DVIPA. This is what allows traffic destined for the DMGR to berouted to whatever MVS image the DMGR is started on

� The use of VipaDistribute statements in the TCP Profile. This is what allows Sysplex Distributor

to know what ports to distribute.

� A JCL start procedure library that's accessible from those systems on which the DMGR may bestarted.

� Any STEPLIB references in the DMGR's JCL start procedure resolve equally on any MVS image the

DMGR is to be started.

� Either a shared configuration HFS for the DMGR's node, or the ability to move that configuration HFSto the other MVS image. The DMGR must have access to its configuration HFS for it to start.

� A configured and started Daemon instance on that MVS image. One would be there if you federatedan appserver node on that image.

� The same service level of WebSphere Application Server for z/OS code on the MVS images whereyou intend to start the DMGR.

You can have different levels during the period you are rolling maintenance. The point hereis that if the DMGR has been updated to service level 6.1.0.13 (for example), you would notwant to try to start that DMGR on an MVS image where the level is still back at 6.1.0.11.

You can start a DMGR on an MVS image where the WAS for z/OS code is at a higher level... but understand that applyPTF processing will update the DMGR to that new level. That'sfine, but it means you couldn't move the DMGR back until you updated the other MVS imagecode to that level.

For the sake of simplicity it's easier to say this: "The DMGR is most mobile when theservice level of WebSphere for z/OS is the same across the different MVS images.

Note:

That's the essence of it. We'll show you details in this white paper.

The need for the same version and maintenance level on both LPARs

For this to work as supported, the version level and maintenance level of WAS z/OS needs to be thesame on both LPARs. Here’s why:

� This “mobile DMGR” concept assumes there’s a running Daemon on the target LPAR.

� If you’ve introduced new maintenance to a cell, you will have started with the DMGR node.That’s a pretty solid rule of thumb: the DMGR node must always be higher or equal to the levelof any node it supports.

� If the target LPAR node is at a lower level of maintenance then the Daemon on that LPAR willbe at that lower level of maintenance as well.

� When the DMGR is started on the target LPAR it will be operating with a Daemon that is at alower level of maintenance. That may work. It may not. In any event it would be an




unsupported environment. When moving the DMGR make sure the target LPAR is the samelevel of maintenance as the DMGR so the DMGR and Daemon align in terms of code level.

The necessity of testing

There's always a "gotcha" lurking somewhere2. What we're going to show you are the key elementsof making the DMGR mobile. You should of course test it before the time comes when you reallyneed it.

Scenario that we're covering in this document

What we're going to cover is the case where the DMGR is capable of being started on any MVSimage where -- here's the key -- there exists a Daemon instance for the cell:

MVS Image

CR SR

AppServer

MVS Image

CR

Node Agnt

CR

Node Agnt

CR

Daemon

CR

Daemon

CR SR

AppServer

CR SR

DMGR

A Daemon will exist on every MVS image where a node for that cell had been built. Having aDaemon there is important because the DMGR can't run without one. And you can't just drop aDMGR on an MVS image and have it auto-magically create a Daemon instance. So our scenario isthe movement of the DMGR between MVS images where that cell has a Daemon instanceconfigured and started.

Two cases -- configuring at time of creation, and modifying after the fact.

We'll show you two cases in this document -- one illustrates how to configure a brand new cell so itsDMGR is mobile. The other case shows how you can take an existing cell -- one that wasn'tconfigured to support a mobile DMGR -- and modify it so it can.

Only two MVS images? What about between three or four images?

Yes, that can be done. We'll illustrate two in this document. But the principles apply equally well fortwo or more MVS images. The one restriction for the purposes of this document is they must be inthe same Sysplex.

Two scenarios we're not covering in this document

There are two scenarios that are possible, but what's involved falls outside the scope of what we'retrying to accomplish with this document.

Not covered -- move of DMGR and its Daemon to a different MVS image

This is the case where you want to move a DMGR and its Daemon to a whole different MVSimage:




2 And a paper that covered every possible contingency would be long and somewhat confusing. Rather than go down thatpath, we're focusing on the key things.

MVS Image MVS Image

CR SR

DMGR

CR

Daemon

This can be done. But it involves changing the system name imbedded in the configuration ofthe Daemon, and possibly the IP Host name as well. For V6.1 that implies using the newWSADMIN AdminTask object.

See the white paper WP100792 on ibm.com/support/techdocs for more on this scenario.

Not covered -- move of just the DMGR to a different MVS image with no Daemon instance

This is the case where you want to move the DMGR to a new MVS image, but leave its Daemonwhere it was for other nodes to use on that MVS image. The target image has no Daemon tosupport the DMGR:

MVS Image

CR SR

AppServer

MVS Image

CR

Node Agnt

CR

Daemon

CR SR

DMGR

This requires that a new Daemon instance be created. That's a somewhat tricky thing to do. Itcan be done but it involves copying configuration files and hand-modifying them. (We providedan illustration of that for V5.1 in the WP100542 document on ibm.com/support/techdocs.)

It's not trivial. Don't do this unless you really know what you're doing.Note:

This strays too far from our objective of showing how to configure a DMGR to float between twoor more MVS images where there already exists a configured Daemon instance.




Key Elements That Allow DMGR Mobility

We'll first illustrate some key things about a cell configuration that make moving the DMGR possible.While we're doing that, we'll also illustrate a few other points that are "best practices" in configuring acell. The step-by-step instructions we'll offer later will put into practice these principles.

MVS Image

CR SR

AppServer

MVS Image

CR SR

DMGR

CR

Node Agnt

CR

Node Agnt

CR

Daemon

CR

Daemon

CR SR

AppServer

DMGR:

1. Uses host IP name associated with DVIPA address

2. Ports defined on VipaDistribute

3. Server short name has no "system identifier"

4. JCL start procedure has no "system identifier"

5. JCL start procedure in a Sysplex-wide proclib

6. Node has its own configuration file system and is either shared or can be quickly moved to other systems

DMGR's Daemon

1. Uses host IP name associated with DVIPA address

2. Ports defined on VipaDistribute

3. Daemon JOBNAME has no "system identifier"

Node Agents

1. All node agents use the same ports

2. Those ports are defined on VipaDistribute

An explanation of each will be offered next.

Deployment Manager

1. The host IP name associated with the DVIPA is what allows anyone seeking the DMGR to use a"generic" host name -- one not tied to a specific MVS image. That would include people lookingto use the Admin Console as well as other servers in the cell seeking the services of the DMGR.

When the DMGR is configured with the DVIPA generic host name it doesn't matter where theDMGR is located. Sysplex Distributor will find it.

2. The ports used by the DMGR must be defined on VipaDistribute statements in the TCP/IP

PROFILE so that Sysplex Distributor knows to route the traffic when a request is received for

one of the DMGR's ports.

3. The DMGR's server short name should not have a system identifier. This is not a technicalrequirement, but rather a way to avoid confusion. Remember, we are designing the DMGR tobe mobile across multiple systems. We do not want the name to be tied to a specific system.

4. The DMGR's JCL start procedure should not have a system identifier either. This is not atechnical requirement. It is a way to reduce confusion.

5. If the DMGR's JCL start procedure was located in a proclib accessible to one MVS image butnot the other, then starting the DMGR elsewhere would not be possible. Having the JCL startprocedure in a shared proclib allows the DMGR's proc to be accessible from anywhere.

6. The DMGR's configuration file system (or "HFS" as many people refer to it) must be accessiblefrom whatever system you wish to start the DMGR. A separate configuration HFS makes this




easier -- the HFS can be moved to the other MVS image to improve performance. A sharedHFS would also work, but cross-Sysplex HFS access may slow the start of the DMGR.

Deployment Manager's Daemon

These things are not required to allow the DMGR to be mobile. We offer them because theyare considered "best practices" of a multi-image cell.

Note:

1. The host IP name associated with the DVIPA is what allows anyone seeking the Daemon to usea "generic" host name -- one not tied to a specific MVS image. You would not need this forstarting a DMGR on another MVS image. This is related to the "location name service" functionof the Daemon.

Coding the generic IP host name (and defining the Daemon ports on VipaDistribute, which

we describe next) means external clients will be given a way to access any available Daemon inthe cell. If you created the DMGR's Daemon with the IP host name for a specific MVS image,then that image-specific host name would be given to all external clients seeking name services.That works fine provided that image-specific host name Daemon is actually up. But if it's not,then the external client's request would fail.

2. Coding the Daemon ports on VipaDistribute is part of process to provide external clients accessto any available Daemon. The VipaDistribute statements allow Sysplex Distributor tounderstand how received traffic is to be distributed across the Sysplex.

3. The JOBNAME you define for the DMGR's Daemon will be used as the JOBNAME for allDaemons created when a node on another MVS image is federated into this cell. It could getconfusing to have a Daemon started on MVS B with a JOBNAME indicating MVS A. Better toavoid the confusion and provide a JOBNAME for the Daemon that is not system-specific.

Node Agents

These things are not required to allow the DMGR to be mobile. We offer them because theyare considered "best practices" of a multi-image cell.

Note:

1. When a cell consists of multiple nodes across MVS images, then there's no reason the nodeagents can't use the same ports. Configuring all node agents to use the same ports reduces thetotal ports consumed by a cell.

2. Node agents are often used as the server into which external clients bootstap into the cell.That's not a requirement -- they could bootstrap into any server. But when a cell has multiplenode agents, and those node agents are defined to use the same port numbers, then it providesthe ability to create a highly-available bootstrap point.

Defining the node agent ports on VipaDistribute means that external clients can be told to usethe Sysplex Distributor generic host name and the common node agent bootstrap port. SysplexDistributor will then forward the request to the best available node agent.




Case #1 - Configuring for DMGR Mobility From the Beginning

In this section we'll illustrate how to configure a configure a cell in which the DMGR is capable of beingstarted on either of the two MVS images the cell spans.

The sample cell

The FZCELL is an actual cell built and started on the WSCPLEX at the Washington SystemsCenter. The key configuration elements of this cell are provided in the notes below.

The "Planning Spreadsheet" found at ibm.com/support/techdocs under number PRS1331

was used to plan and build the cell.Note:

SYSC

CR SR

FZSR01C

SYSD

CR SR

FZDMGR

CR

FZAGNTC

CR

FZAGNTC

CR

FZDEMN

CR

FZDEMN

CR SR

FZSR02C

A

B B

C D

Notes:

A. The DMGR node has the following characteristics:

FZMGCR, FZMGSRJCL Start Procedures

OMVS.WAS610.FZCELL.FZDMNODE.CONFIG.HFSConfiguration HFS

28510, 28511, 28512, 28513, 28515, 28518, 28519TCP Ports

wsccb.washington.ibm.comConfigured host name

FZDMGRServer short name

B. The Daemon on SYSC was constructed at the time the DMGR was built. The Daemon on SYSD wasbuilt when the node on SYSD was federated into the DMGR cell.

28502, 28503TCP Ports

wsccb.washington.ibm.comConfigured host name

FZDEMNServer JOBNAME

C. The node on SYSC was built in the common way -- standalone server and then federate.

Separate from DMGR HFS (the actual name is not key to the main topic)Configuration HFS

28520, 28521, 28522, 28523, 28524, 28525Node Agent ports

wsc3.washington.ibm.comConfigured host name




D. The node on SYSD was built in the common way -- standalone server and then federate.

Separate from DMGR HFS (the actual name is not key to the main topic)Configuration HFS

28520, 28521, 28522, 28523, 28524, 28525

(the same as the Node Agent on SYSC)Node Agent ports

wsc4.washington.ibm.comConfigured host name

DMGR configuration tasks

The "Planning Spreadsheet" found at ibm.com/support/techdocs under number PRS1331 was

used to plan the cell.

Sysplex Distributor "generic IP" name in spreadsheet

We noted earlier that for the DMGR to be mobile it needed to use the IP host name associatedwith the DVIPA, and not the host name that was specific to the MVS image. In the spreadsheetthat was accomplished by coding wsccb.washington.ibm.com (the generic host IP name for

the WSCPLEX) for "Enter TCP/IP Host Name for Deployment Manager" in cell F111:

The standalone server, which was used to build the federated node on SYSC, did call for thesystem-specific IP name. You see wsc3.washington.ibm.com in cell F110.

Port allocation -- important to know for VipaDistribute definitions

We noted earlier that the DMGR's ports needed to be coded on VipaDistribute statements in theTCPIP PROFILE so traffic could be routed to wherever the DMGR was started. Thespreadsheet's allocation table assigned the following ports based on our starting port number of28500:

To give you a sense of how these ports were defined to TCP/IP and Sysplex Distributor, here'swhat was coded in the PROFILE:




:

;

VipaDynamic

VipaRange MOVE NONDISRUPT 255.255.255.224 9.82.25.1

VipaDefine MOVE IMMED 255.255.255.252 9.82.25.13


:

VipaDistribute 9.82.25.13 port 28502 28503 DESTIP ALL


VipaDistribute 9.82.25.13 port 28510 28511 28512 28513 DESTIP ALL


ENDVipaDynamic

;

:

SYS1.TCPPARMS(PROFELXA)

We'll cover this topic again under "TCP/IP PROFILE configuration tasks" on page 12.Note:

Construction of the DMGR node

We used the zPMT (z Profile Management Tool) to generate the jobs used to construct the DGMR.We took the variables straight from the spreadsheet, put them into a text file, and loaded that textfile in as a "response" file to the zPMT tool.

The Deployment Manager host name and IP port panel:

Generic host IP name

DMGR ports

And the Daemon host name and IP port panel:

Generic host IP name

Daemon ports

The ISPF panels correspond roughly to the zPMT panels. The concept is directly applicable --generic host IP name for DMGR and Daemon, and a noting of the ports used so they can becoded into the TCP/IP PROFILE for distribution.

Note:




Construction of the rest of the cell

This was done in the normal fashion:

� Construct the Standalone Server

� Federate the Standalone Server

Application Server nodes do not use the "generic host IP name" -- that's only for the DMGR and theDaemons. Application servers and node agents are not mobile ... they can not be started onanother MVS image.

Well ... they can, but it requires the embedded system name definition and IP host namedefinition to be changed. WP100792 on ibm.com/support/techdocs provides information

on how that is done. We also do something very similar to it in "Case #2 - Updating an ExistingConfiguration to Provide a Mobile DMGR" starting on page 15.

Note:

TCP/IP PROFILE configuration tasks

Because the DMGR and the Daemons used the generic IP host name, it was important to provideinformation to TCP/IP to know how to route traffic received on that virtual address. This was done inthe SYS1.TCPPARMS(PROFELXA) member, where the VipaDefine and VipaDistribute

definitions were coded:

:

;

VipaDynamic

VipaRange MOVE NONDISRUPT 255.255.255.224 9.82.25.1



:



VipaDistribute 9.82.25.13 port 28510 28511 28512 28513 DESTIP ALL


ENDVipaDynamic

;

:

SYS1.TCPPARMS(PROFELXA)

A

B

C

D

Notes:

A. This "virtual IP address" of 9.82.25.13. The host name wsccb.washington.ibm.com is

associated with this address in the DNS.

B. The two Daemon ports. In a Network Deployment configuration all the Daemons have the sameports. DESTIP ALL tells Sysplex Distributor to consider all the TCP/IP stacks in the Sysplex aseligible for distribution. Our cell spanned SYSC and SYSD only. We could have limited distribution tojust those two systems, but coding DESTIP ALL was simpler.

C. Two of the six Node Agent ports. These two are the ORB and ORB SSL ports. That's the protocolused by external clients looking to bootstrap into the cell. The other ports are for other protocols thatare used for internal communications. They do not need to be distributed.

Recall that we said that the application server nodes were not configured with the generic IPhost name. They use the system-specific host name for their respective systems. Thecoding of the VipaDistribute for the Node Agents was not necessary to enable the

DMGR to be restarted elsewhere ... it was done as a "best practice" so external clients hada common and highly available place to bootstrap into the cell.

Note:

D. Six of the seven DMGR ports. The only port not listed is the High Availability Manager port.




With those definitions coded, any traffic received on the virtual IP address of 9.82.25.13 -- which thegeneric host name of wsccb.washington.ibm.com resolved to -- would be then be handled by

Sysplex Distributor.

Sysplex Distributor routes based on the port. That's the purpose of the VipaDistribute statements.They tell Sysplex Distributor what ports to watch for when traffic is received.

To illustrate this, let's look at two scenarios:

� Imagine someone sends a URL to:

http://wsccb.washington.ibm.com:28518/ibm/console

That's the URL used to access the Admin Console of the DMGR. The host name used therewould resolve to 9.82.25.13, which is the Virtual IP. The port 28518 was coded on the

VipaDistribute statement.

Sysplex Distributor then looks across its TCP stacks to see where the port 28518 is listening.We only have one DMGR, so Sysplex Distributor will only see one instance of somethinglistening on that port. It'll route the traffic there.

This is what allowed us to start the DMGR on either SYSC or SYSD and have trafficfor the DMGR properly routed. This was the main point of the exercise.

Let's say someone else configured something -- an HTTP Server, or whatever -- that alsoused port 28518 on one of the systems in the Sysplex. What would happen? SysplexDistributor would see two bound instances of listeners on that port in the Sysplex andconsider load balancing across the two. That would be a problem. Re-using ports within acell is okay -- our Node Agents and Daemons did just that. But in some cases -- the DMGRis an example -- the port should be unique and not used by anyone else.

Note:

� Now imagine someone outside the cell issues a URL attempting to bootstrap into the cell usingthe host and port:

wsccb.washington.ibm.com:28521

That's the Node Agent ORB port. Our cell has two Node Agents. Sysplex Distributor would seethat port bound on both SYSC and SYSD. It would then use its intelligent routing algorithm todetermine which of the two would best be able to handle the request and then route the requestto that system.

That's what provides the high availability for external clients. Provided at least one Node Agentis up, they can bootstrap into the cell. And the wsccb.washington.ibm.com generic

address, which resolves to 9.82.25.13, is virtual. It is capable of being immediately rehosted

to another physical adapter in the event of an outage on the original adapter.

The same concept applies to Daemons and external clients seeking location name services.

Other enablers of starting the DMGR on another image

The other components of our system which allowed the restart of the DMGR on the other MVSimage:

� The DMGR's JCL start procedures went into SYS1.PROCLIB, which is a shared proclib across

the Sysplex. The proclib is accessible from either SYSC or SYSD, the two systems on whichthe cell spans.

� The cell uses STEPLIB to access the product module libraries. The data sets -- SBBOLOAD,

SBBOLD2 and SBBOLPA -- were shared libraries, accessible from any system in the Sysplex.

The use of STEPLIB is not a requirement of a mobile DMGR. That's just what we used.

Using LPA/LNKLST is okay as well. The key is that the modules the DMGR needs must beaccessible on the other system.

Note:




� The WebSphere product HFS -- SBBOHFS -- was mounted at a shared location. Therefore, itwas accessible from either SYSC or SYSD.

� The DMGR's configuration HFS was also at a shared location, accessible from either SYSC orSYSD. However, we found that the time it took for the DMGR to initialize was significantlyimproved by having the HFS owned by the system on which the DMGR was being started.

� The level of WebSphere Application Server was the same on both SYSC and SYSD. That'sbecause we had a common, centralized location for the WAS SMP/E code. The key here is thatbecause it was the same level on both systems, there was no concern about applyPTFprocessing taking place, or the server not starting due to the configuration maintenance levelbeing higher than the underlying product maintenance.

Revisit the issue of the Daemon instance

Recall that the DMGR was initially constructed on SYSC. The objective of this illustration was toshow how it could be started on SYSD as well.

The Daemon instance on SYSC was built when the DMGR was built. That Daemon instance onSYSC is specific to SYSC -- it has configuration information in its was.env file that locks that

instance to that MVS image.

The DMGR has within its configuration XML information about how to start a Daemon if it doesn'tsee one as the DMGR is being initialized. Because the DMGR was initially constructed on SYSC,the information in the DMGR's configuration calls for the SYSC Daemon instance to be started.

That means the DMGR, when it's started on SYSD, needs to have a Daemon already up andrunning there. If it doesn't see one, it'll try to start a Daemon, and it'll try to use its configuredDaemon start command ... but that'll be for the SYSC Daemon instance. The SYSC Daemoninstance can't start on SYSD.

Thankfully, the design of WebSphere's DMGR requires only that a Daemon instance for the cell bepresent, not that a specific Daemon instance be present.

So we come back to one of our key requirements -- that there be a Daemon instance for the cell onthe MVS image where you're trying to start the DMGR, and that that Daemon instance be up andrunning when the restart of the DMGR is attempted.

If you start the DMGR on it's original system (SYSC in our example), it'll be able to start it's Daemonwithout difficulty. It's only when you try to start the DMGR on another MVS image that a runningDaemon instance being present is a requirement.

A reader3 wrote to the author of this document with this: “If one sets WebSphere variableWAS_DAEMON_daemonInstanceName to the same value on the DMGR and all

Application Servers nodes, then there is no issue at all starting the DMGR when theDaemon is not started.”

Note:

Restarting the DMGR on the other MVS image

With all those things in place, the DMGR was able to be started on either SYSC or SYSD. The startcommand was the same on either system:

S FZMGCR,JOBNAME=FZDMGR,ENV=FZCELL.FZDMNODE.FZDMGR

As mentioned, we have found that the initialization time for the DMGR is significantly improved if theconfiguration HFS for the DMGR is owned by the MVS image where the DMGR is starting4.




4 Starting with z/OS 1.13 and shared file systems, this is no longer true. See WP102230 at ibm.com/support/techdocsfor performance study that shows the shared file improvements with 1.13.

3 IBMer Martin Rieger from Austria.

Case #2 - Updating an Existing Configuration to Provide a Mobile DMGR

If you have a cell that's already built, and you tied the DMGR to the image-specific IP host name, youcan modify it to make the DMGR mobile. With WebSphere for z/OS V6.1 the process is much simplerthan it was before. It involves the use of WSADMIN and a single command to change the DMGRnode's host name.

You might be tempted to try to modify in the Admin Console the DMGR server's host under "Ports."That won't make the DMGR mobile. The objective is to change the DMGR node's host name, andthat can only be done using WSADMIN and the AdminTask command.

Note:

All the other requirements of a mobile DMGR still needed

The focus of this scenario is the changing of the DMGR node's host name to the host nameassociated with the virtual IP address. Doing so is one piece of the puzzle, but the other things wementioned under "Case #1 - Configuring for DMGR Mobility From the Beginning" also apply:

� DMGR ports configured in TCP PROFILE on VipaDistribute statements

� A virtual IP address defined with VipaDefine and the DNS updated to associate a the generic IPhost name with that virtual IP address

� The DMGR's JCL start procedures accessible from those MVS images where the DMGR will bestarted

� The DMGR's configuration HFS either shared across those MVS images or can be moved to theother MVS image. The basic point is that the DMGR needs access to its configuration HFS tostart.

� The level of WebSphere for z/OS the DMGR will use is the same on any MVS image where theDMGR is to be started.

� A Daemon instance for the cell be configured and started. In other words, you can't start theDMGR on an MVS image where no other component of the cell is built. We discussed thatunder "Two scenarios we're not covering in this document" starting on page 5.

All these things are what was discussed under "Key Elements That Allow DMGR Mobility" startingon page 7.

Overview of the process

Imagine an existing cell that looks like this:

SYSC

CR SR

FZSR01C

SYSD

CR SR

FZDMGR

CR

FZAGNTC

CR

FZAGNTC

CR

FZDEMN

CR

FZDEMN

CR SR

FZSR02C

Daemon host IP tied to SYSC IP host name

DMGR node host name tied to SYSC IP host name

Daemon created after federation also references SYSC IP host name




And the objective is to modify the DMGR and the Daemons so they have the generic IP host nameassociated with the Sysplex Distributor virtual IP address. This is so the DMGR will be "mobile" likewe've discussed before, and external clients could access the location name service using thegeneric IP host name as well.

What we'll illustrate here is using WSADMIN in interactive mode -- that is, entering thecommands at the WSADMIN command prompt, one command at a time. We do this so youcan clearly see the steps.

Please understand that the whole thing can be packaged up in one WSADMIN script andinvoked with batch JCL ... see "Using batch JCL to invoke WSADMIN" on page 22 for that.

Note:

The steps to accomplish this are:

1. Back up your configuration HFS

2. Update TCP PROFILE in preparation for use of Sysplex Distributor for DMGR, Daemons and NodeAgents

3. Stop all the servers in the cell

It is possible to minimize the downtime by stopping servers at a later time. Eventually they'llall need to be stopped and restarted to pick up the changes we're making. It's just easier tostop them all now and restart them in an orderly fashion.

Note:

4. Use WSADMIN to update the host name for the DMGR node

5. Use WSADMIN to update the host name for the Daemons

6. Use WSADMIN to save the changes

7. Restart the DMGR and its Daemon

8. Use the syncNode.sh shell script to synchronize to the changes out to the nodes

9. Restart the servers in the nodes

10. Test the restarting of the DMGR on the other MVS image

This is exactly what we'll illustrate here, using the FZCELL as an example

Step 1 - Back up your configuration HFS for each node in the cell

The changes you'll make using WSADMIN are minor, but backing up the node configuration HFSprior to doing this is good insurance.

� Back up the configuration HFS using the tool or process of your choice

Step 2 - Update TCP PROFILE in preparation for use of Sysplex Distributor

This is exactly the same as we illustrated under "TCP/IP PROFILE configuration tasks" on page 12.You can make this update before you make the changes to the WebSphere configuration.

� Inventory the DMGR ports, Daemon ports and Node Agent ports as illustrated under "TCP/IPPROFILE configuration tasks" on page 12.

� Make sure a VipaDefine statement is present and a virtual IP address is coded.

� Make sure that virtual IP address has a DNS host name entry to that resolves to it. In ourFZCELL illustration that host name was wsccb.washington.ibm.com.

� Code the VipaDistribute statements for the ports. Use the picture under "TCP/IP PROFILE

configuration tasks" on page 12 as a guide.

� Enable the updates.




Step 3 - Stop all the servers in the cell

We do this because we're about to change a fundamental aspect of its configuration. While it wouldbe possible to leave the application servers up for now, for the sake of simplicity we'll illustratestopping the whole cell and then later restarting the servers in a specific order.

� Stop the Daemon that supports the DMGR. This will stop the DMGR and all servers for that cellon that MVS image.

� Stop the Daemons that support federated nodes on other MVS images. That will stop the otherservers in the cell.

Step 4 - Update DMGR node host name using WSADMIN

WSADMIN is the programming interface for configuration and management of WebSphere. TheAdmin Console is the GUI interface, WSADMIN is the programming API.

Prior to WebSphere V6.1 the act of modifying a node's configured IP host name involvedhand-editing XML files and running shell scripts to update the configuration. It was not simple. WithV6.1 WebSphere introduced a new WSADMIN command object called AdminTask. With that theact of updating the node's host name was made much more simple. That's what we'll use here.

You don't need to be an expert in WSADMIN to follow the instructions offered here. But if you'dlike to learn more about WSADMIN, we recommend two Techdocs:

� http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100963

� http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101014

Note:

� Telnet to the system on which the DMGR is currently defined

� You can use OMVS if you wish.� You may use batch JCL rather than an interactive prompt if you wish. See "Using batch

JCL to invoke WSADMIN" on page 22.

Notes:

� "Switch users" (su) to the WebSphere Admin ID for the cell

WSADMIN will need write access to a few directories and files. Operating under theWebSphere Admin ID guarantees this access. An alternative would be to connect an ID tothe WebSphere Configuration group and run WSADMIN under that ID.

Note:

� Change directories to:

/aaaaa/DeploymentManager/profiles/default/bin

where aaaaa is the mount point for the Deployment Manager's configuration HFS.

� Issue the following command:

./wsadmin.sh -conntype NONE -lang jython

� Wait for the following:

WASX7357I: By request, this scripting client is not connected to any serverprocess. Certain configuration and application operations will be availablein local mode.

WASX7031I: For help, enter: "print Help.help()"

wsadmin>

� At that command prompt enter the following:

AdminTask.changeHostName('[-nodeName aaaaa -hostName bbbbb]')

Where:� aaaaa is the node long name

� bbbbb is the new host name you want for the node




For example, the command for the FZCELL we used back in Case #1 the command would be:

A

AdminTask.changeHostName('[-nodeName fzdmnode

-hostName wsccb.washington.ibm.com]')

B

The line is split here simply because it wouldn't fit on one line in this document. Whenentering into WSADMIN it's important to have it be on one line.

Important:

Notes:

A. The long name of the DMGR node

B. The generic IP host name associated with the virtual IP address. Because this is not tied to aspecific MVS image the DMGR can be started on different images and things can still find it. It'sbecause of Sysplex Distributor that they can.

� If the syntax of your command was correct, you'll get back very little ... just a set of quote marksand the command prompt:

''

wsadmin>

� Now it's time to save the configuration changes. Enter this command:

AdminConfig.save()

You'll get the same set of quote marks and the command prompt. Continue to the next step.

Step 5 - Use WSADMIN to update the host name for the Daemons

This is not strictly required to support the movement of the DMGR to another MVS image. Butit's a good practice to have the ports for a ND cell Daemon use the Sysplex Distributor genericIP host name and have its ports distributed. See "Deployment Manager's Daemon" on page 8for an explanation as to why.

Note:

� At the WSADMIN prompt (which you should still have open), issue the following command:


Important:

AdminTask.modifyNodeGroupProperty('DefaultNodeGroup',

'[-name was.WAS_DAEMON_protocol_iiop_daemon_listenIPAddress -value aaaaa]')

Where:� aaaaa is the new host name you want for the Daemons

For example, the command for the FZCELL we used back in Case #1 the command would be:

A

AdminTask.modifyNodeGroupProperty('DefaultNodeGroup',

'[-name was.WAS_DAEMON_protocol_iiop_daemon_listenIPAddress

-value wsccb.washington.ibm.com]')


Important:

� If the syntax is correct you'll get back an echo of the property that was updated. For example,we saw this:




'was.WAS_DAEMON_protocol_iiop_daemon_listenIPAddress(cells/fzcell/node

groups/DefaultNodeGroup|nodegroup.xml#Property_3)'

wsadmin>

� Save the configuration changes. Enter this command:

AdminConfig.save()

You'll get the same set of quote marks and the command prompt.

Step 6 - Exit WSADMIN

� At the WSADMIN prompt (which you should still have open), issue the following command:

quit

� You'll be returned to the UNIX command prompt. Maintain your telnet session because you'llneed it to do the node synchronization steps which come next.

Step 7 - Restart the DMGR and its Daemon

Restarting the DMGR and it's Daemon does two things:

1. It validates the changes made and the ability to access the DMGR through Sysplex Distributor

2. It allows us to use the syncNode.sh shell script to synchronize the changes out to the nodes. TheDMGR has to be running for that to work.

Do the following:

� Start the DMGR on the original MVS image as you normally would.

� Access the DMGR's Admin Console using the generic IP host name. This will validate the TCPPROFILE definitions and the use of the generic host name. For the FZCELL the URL was:

A

http://wsccb.washington.ibm.com:28518/ibm/console

B

Notes:

A. The generic IP host name associated with the virtual IP address. This is the host name we usedon the WSADMIN command that updated the DMGR's host value and the Daemons' host value.

B. The HTTP port of the DMGR. This port value, along with the other ports we described under"TCP/IP PROFILE configuration tasks" on page 12, was now being handled by SysplexDistributor. TCP/IP looked to see which system had a process that was bound to that port andthen routed the request to that system. For this initial test the system was the original MVSimage.

Step 8 - Use the syncNode.sh shell script to synchronize to the changes out to the nodes

The changes were made to the DMGR's "master configuration," but they were not yet synchronizedout to the nodes. Synchronization can be accomplished using a supplied shell script.

Do this for each of the application server nodes in your cell.

� In the telnet window, change directories to the application server node's /bin directory. For

example:

/wasv61config/fzcell/fznodec/AppServer/profiles/default/bin

� Make sure you're still operating under the ID of your WebSphere Admin ID. Issue the followingcommand:

whoami

You should see it respond with your WebSphere Admin ID. If not, then su to that ID.

� Invoke the syncNode.sh script using the following command:




./syncNode.sh aaaaa bbbbb -conntype SOAP -username ccccc -password ddddd

Where:� aaaaa is the new host name for the DMGR ... this would be the generic IP host name

� bbbbb is the SOAP port of the DMGR

� ccccc is the WebSphere Admin ID

� ddddd is the WebSphere Admin ID password

For example, the command we used for the FZCELL was:

A

./syncNode.sh wsccb.washington.ibm.com 28510 -conntype SOAP

-username FZADMIN -password ******

B

C D

Notes:

A. The generic IP host name associated with the virtual IP address.

B. The SOAP port of the DMGR. This port value, along with the other ports we described under"TCP/IP PROFILE configuration tasks" on page 12, was now being handled by SysplexDistributor.

C. The WebSphere Admin ID

D. The WebSphere Admin ID's password

� Look for the indication of success. For the FZCELL the response was this:

ADMU0116I: Tool information is being logged in file /wasv61config/fzcell/fznoded/AppServer /profiles/default/logs/syncNode.logADMU0401I: Begin syncNode operation for node fznoded with Deployment Manager wsccb.washington.ibm.com: 28510ADMU0016I: Synchronizing configuration between node and cell.

ADMU0402I: The configuration for node fznoded has been synchronized with Deployment Manager wsccb.washington.ibm.com: 28510

� Repeat the previous steps for each application server node in your cell.

Step 9 - Restart the servers in the nodes

With all the nodes synchronized they now have the information they need to understand that theDMGR is listening on the generic IP host name. The Daemons are also listening on that generic IPhost name.

� Restart the servers and Node Agents as you normally would

Step 10 - Test the restarting of the DMGR on the other MVS image

You should now be able to stop the DMGR on the original MVS image and restart it on one of theother MVS images where a node already exists for the cell.

Key things to keep in mind:

� The ownership of the configuration HFS should be changed to the new MVS image to improvethe time it takes for the DMGR to start

� The Daemon instance on the other MVS image must be already started when the DMGR isstarted. The DMGR's configuration still points to the original system Daemon instance. TheDMGR will happily use a Daemon instance it finds on the other MVS image, but it can't start it.

Your DMGR is now mobile.




WAS z/OS V7 and Making the DMGR Mobile

WAS z/OS V7 introduced new functionality that at the present time modifies slightly the process to makethe DMGR “mobile” and avoid any potential problems.

The fix for this is documented as part of APAR PM26178. That is currentlytargeted for inclusion in Service Level (Fix Pack) 7.0.0.17 of WebSphereApplication Server V7.0.

The process described for V6.1 in the earlier part of this document still applies. The problem does notmanifest itself in WAS z/OS V6.1 or earlier.

If you have V7 and have implemented the originally documented “Mobile DMGR” process, it maywell be that it works for you without any problems. If so, then the changes described below are notstrictly required.

Note:

To avoid any potential for the problem prior to 7.0.0.17 is to:

� Make sure the IPC ports for the node agents on the different LPARs are different numeric values.

- or -� Use the WSADMIN AdminTask command object to change the configured system name for the DMGR

node to that of the target LPAR.

You could do both, but that is unnecessary. One or the other provides an effective workaround.

IPC Ports

Our normal recommended “best practice” is to have the Node Agent ports for an ND cell be thesame numeric values on the different LPARs.

There’s no technical reason why that be so. We recommend that for simplicity, and so the NodeAgent ORB ports may be used as a convenient highly available bootstrap port.

The Planning Spreadsheet for V7 assumes same numeric values for Node Agents across LPARs.

Using the Administrative Console to modify the IPC ports so they are unique numeric values will beenough to circumvent the potential problem.

Changing the DMGR’s configured system name

The alternative workaround is to change the DMGR’s configured system name when it is moved tothe secondary LPAR. Techdoc WP100792 illustrates how the AdminTask object can be used to dothis.

WAS z/OS V8.5 and Making the DMGR Mobile

An interesting element of this came up when running with WAS z/OS 8.5, though in reality this situationapplies to any level of WAS z/OS. It is this: the use of BIND to bind the Deployment Manager to a

DVIPA host, for example:

IPORTE0

40002 TCP WADMGR BIND 9.82.17.103 ;DM ORB

Then you also need to create a custom property for the Deployment Manager to allow the DMGR to bemobile. In the Admin Console, go to Deployment manager > ORB service > Custom properties andcreate a custom property with the following:

com.ibm.CORBA.BootstrapHost = [ DVIPA host name or DVIPA IP address ]

Summary: either remove the BIND or code the custom property.




Miscellaneous Information

Using batch JCL to invoke WSADMIN

WSADMIN can be invoked from JCL. Many use this method when the WSADMIN commands arepart of a larger, more complicated script. The JCL simply invokes the wsadmin.sh shell script andthen points to Jython script to be run. Here's an example of JCL that does that:

****** ***************************** Top of Data *************************=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+--000001 //CHNGHOST JOB (ACCTNO,ROOM),REGION=0M, 000002 // USER=FZADMIN,PASSWORD=****** 000003 //STEP2 EXEC PGM=IKJEFT01 000004 //SYSTSPRT DD SYSOUT=* 000005 //SYSTSIN DD * 000006 BPXBATCH SH + 000007 /wasv61config/fzcell/fzdmnode/DeploymentManager/profiles/default+000008 /bin/wsadmin.sh + 000009 -lang jython + 000010 -conntype NONE + 000011 -f /u/user1/chnghost.jy + 000012 1> /tmp/wsadmin.out + 000013 2> /tmp/wsadmin.err 000014 /* ****** **************************** Bottom of Data ***********************

There are some important things to understand about this:

� Line 2 -- When -conntype NONE this is necessary so the process has the necessary permissions to theconfiguration HFS. When -conntype SOAP or RMI, this names the ID that owns the keyring that holdsthat certificate that allows the SSL stuff to work.

� Line 7 -- Notice the + sign at the end of that ... it's directly after the "t" in "default." What that does is

provide a concatenation with no space between this line and the next. That's important because whatthis is doing is building the path to the wsadmin.sh script to be invoked.

� Lines 8, 9 and 10 -- Here the + sign has a space before it. That space allows the concatenation to take

place with separation between the command options.

� Line 10 -- this example shows -conntype NONE, which is what we used earlier in this document.

That means that WSADMIN modifies the XML directly, without making a connection to the DMGR. Ifyou change that to -conntype SOAP or -conntype RMI, you may need to supply -user and

-password. It'll depend on whether security is enabled for the cell, whether the userid and password is

coded in the soap.client.props file, and whether RMI is used.

The topic of WSADMIN and security can get complicated. Go to ibm.com/support/techdocs and

take a look at the WP101014 white paper for more information on this.

� Line 11 -- The -f switch points to the location of a script file (in ASCII by default) which contains the

commands. We illustrate that script file next.

� Lines 12 and 13 -- Routing the output to a set of files in /tmp.

Example of simple script to change DMGR host and Daemon host values

With batch JCL coded to invoke WSADMIN and fetch a script file, all that's left is to supply the scriptfile. It's nothing more than a text file with the WSADMIN commands in it. Earlier we used threeWSADMIN commands. Those three commands, placed in a file called chnghost.jy might look

like this:




# ------------------------------------------------------------- ## Variables definition ## ------------------------------------------------------------- #node = 'fzdmnode'host = 'wsccb.washington.ibm.com'# ------------------------------------------------------------- ## Invoke commands -- no mods needed below this line ## ------------------------------------------------------------- #AdminTask.changeHostName('[-nodeName '\ + node + ' -hostName ' + host + ']')AdminTask.modifyNodeGroupProperty('DefaultNodeGroup',\ '[-name was.WAS_DAEMON_protocol_iiop_daemon_listenIPAddress -value '\ + host + ']')AdminConfig.save()

� The backslashes are what break a line and continue it on the next. You could code the longcommands on line in the file. WSADMIN would be fine with that.

� This script changes the values in the DMGR node and save the changes, but it does not dothe synchronization. A script can be written to do that, but for this example we're keeping itsimple. You would still need to use syncNode.sh as shown earlier to force synchronization

to the nodes.

Notes:

So the steps would be:

� Code up the JCL as shown before.

� Code up a text file and include the commands shown here

� Modify the variables node and host to map to what you need

� Upload the file in binary to the z/OS system

� Make sure the JCL -f switch points to the location and name of the file

� Make sure the permissions on the file allowed at least READ access

� Invoke the JCL

� Check the output files in /tmp to see things ran okay




Document Change History

Check the date in the footer of the document for the version of the document.

Added a note about the restriction using this “Mobile DMGR” approach with theintelligent management function of the web server plugin or On Demand Router. Forthis design to work with those functions, the Sysplex Distributor function must reside onthe same LPAR as the DMGR.

June 24, 2016

Added a section for WAS z/OS V8.5 that discusses what to do when the DMGR isbound to the DVIPA using a TCP BIND statement. A custom property is then requiredto allow the DMGR to be mobile.

November 13, 2015

Added a note about how the version and maintenance levels of the LPARs over whichthe DMGR may move are the same. They key is avoiding the situation where theDMGR is started on an LPAR where the already-existing Daemon server is operating ata lower level. That may work, or it may not, depending on the levels. In any event, itwould be unsupported. The DMGR and the Daemon that supports it must always be atthe same level.

September 12, 2013

Inserted the APAR number and targeted fix level for the V7 issue cited in the previousdocument history entry.

March 22, 2011

Inserted information on workarounds for V7 to prevent the potential manifestation of aproblem discovered by a customer. See “WAS z/OS V7 and Making the DMGR Mobile”on page 21.

October 16, 2010

Fixed the header title so it provided the title of this documentMarch 24, 2008

Republish with the assigned Techdoc number added to the document.November 21, 2007

Original document.November 20, 2007

End of WP101140




Making the DMGR “Mobile” · Making the DMGR “Mobile ... 1 dictionary.com. Why bother? Because...

Documents

Transcript of Making the DMGR “Mobile” · Making the DMGR “Mobile ... 1 dictionary.com. Why bother? Because...