washington systems center sample websphere for …...overview and introduction the purpose of this...

WebSphere for z/OS Version 5.0.2

Washington Systems CenterSample WebSphere for z/OS

ND Configuration

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

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

Document Release #502-2Version Date: March 9, 2004

See "Document Change History" onpage 127 for information on what's new

in this version of the document

IBM Washington Systems Center

Don BagwellIBM Washington Systems Center

[email protected]

Virtually all credit for this document goes to Mike Cox andJohn Hutchinson of the Washington Systems Center.

They're the ones who make all this stuff work. I carefullylisten to what they say ... and then I write about it.

Table of Contents

50Base Application Server validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Base Application Server node started on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49Customized jobs run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48Updates as specified in BBOSSINS member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48Manual updates made . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48View instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Customized jobs generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Customization variables saved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41The 'Define Variables' option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Target data sets allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Security Domain variables loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Base Application Server node main option panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Option to configure a Base Application Server node selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38ISPF dialogs started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37ISPF Panels for the Base Application Server node on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Base Application Server node created on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Customized jobs run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36View instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Save Security Domain variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Generate customized jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Define variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Allocate target data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Option to configure Security Domain selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32ISPF dialogs started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31IDs and Groups created in Security Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Security Domain Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Summary of naming conventions used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Cluster naming and WLM application environment names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Cell and Node short and long names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Server short and long names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Server JCL start procedure names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Starting point: JOBNAME values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24The naming convention used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Application servers are considered to be a member of a cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20A single error log stream used for all components in this cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Allow no more than one node per system in the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Make use of dynamic WLM application environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Utilize Sysplex Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Fence off a small range of TCP ports and use instead of default port assignments . . . . . . . . . . . . . . . . . . . .13Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Other considerations taken into account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9How the RACF profiles are created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Minimize RACF userids and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Minimize JCL start procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Three key design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3High-level configuration objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Starting Environment: WSCPLEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Other documents on Techdocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1How to best use this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Overview and Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

WP100367 - Washington Systems Center Sample WebSphere for z/OS ND Configuration

81Base Application Server validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Base Application Server started on SYSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Manual updates made and customized jobs run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Customized jobs generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79Customization variables saved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75The 'Define Variables' option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74Target data sets allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74Variables Loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74ISPF Panels for the Base Application Server node on SYSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Note about where to run ISPF panels for Base Application Server on SYSB . . . . . . . . . . . . . . . . . . . . . .73Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Base Application Server node created on SYSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Configuration at this point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72Status of progress towards target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71Starting server from administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Starting server manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Server in the newly-federated node started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Node Agent started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70How a virtual host alias is added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Why did the application work in the Base Application Server node? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Symptom if virtual host alias not present . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69HTTP ports of federated server added to virtual host list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68BBOWADDN job run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68Access to /tmp directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Base Application Server and Daemon shut down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Deployment Manager running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Preparing to run the customized BBOWADDN job on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67BBOANINS instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Option 5 - Federate Base Application Server node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63ISPF Panels for federating the Base Application Server node on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . .62Overview of federation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Base Application Server node's HFS content not moved ... just changed . . . . . . . . . . . . . . . . . . . . . . . . . . .61What federation does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Federated Base Application Server node on SYSA into the DM cell . . . . . . . . . . . . . . . . . . . . . . . .60Configuration at this point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60Status of progress towards target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Deployment Manager started and validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Customized jobs run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Customized jobs generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Configuration variables saved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54The 'Define Variables' option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Target data sets allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Security Domain variables loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53SAVECFG from Base Application Server node configuration loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Deployment Manager option selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52ISPF dialogs invoked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52ISPF panels for Deployment Manager configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Deployment Manager created on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Configuration at this point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Status of progress towards target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


130Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129Other Documents on the Techdocs website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127Document Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125Using the IOR received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124Requesting an IOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124More on the role of Daemons and Node Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124What about vertical clusters? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123Dynamic Application Environments (DAE) to the rescue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123Horizontal clusters and node names in the ENV= string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122Horizontal clusters and JCL start procedure names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122Clusters and WLM application environment names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122Why WLM Dynamic Application Environments helps in configuring horizontal clusters . . . . . . . . . . . . .121When Code HFS is lower level than Config HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Maintenance places instruction files in Code HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121What applyPTF.sh does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Maintenance to Config HFS necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120SMP/E maintenance applied to Code HFS, not Config HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120Relationship between Config HFS and Code HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120The applyPTF.sh process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120Appendix E - Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116Appendix D - BBOANINS for Federation of Node into DM on SYSA . . . . . . . . . . . . . . . . . . . . . . . .109Appendix C - BBOCCINS for Deployment Manager on SYSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Appendix B - Customized RACF profile used for this configuration . . . . . . . . . . . . . . . . . . . . . . .96Appendix A - BBOSSINS for Base Application Server node on SYSA . . . . . . . . . . . . . . . . . . . . . . .95The Final Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94Change new cluster member's short name from default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93TCP ports of new clustered server remapped . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93New clustered server created on AZNODEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92Existing server azsr01a selected as starting server in cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91New cluster created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91Cluster created across SYSA and SYSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Configuration at this point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90Status of progress towards target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Starting server from administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Starting server manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Server in the newly federated node started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Node Agent started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88HTTP ports of federated server added to virtual host list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88BBOWADDN job run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Access to /tmp directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Base Application Server and Daemon shut down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Deployment Manager running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Preparing to run the customized BBOWADDN job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87BBOANINS instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85ISPF Panels for federating the Base Application Server node on SYSB . . . . . . . . . . . . . . . . . . . . . . . . . .84Same TCP ports used by both Node Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Updates to HFS made by shell script process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Federating a node on an MVS image other than where the Deployment Manager lives . . . . . . . . . . . . .83Federated Base Application Server node on SYSB into the DM cell . . . . . . . . . . . . . . . . . . . . . . . .82Configuration at this point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82Status of progress towards target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Overview and IntroductionThe purpose of this document is to present an actual sample implementation of WebSphere forz/OS Version 5 -- one that's been implemented at the Washington Systems Center -- and from thatprovide an explanation of various planning considerations.

The final configuration looks something like this:

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01

Node: AZNODEA Node: AZNODEB

Cell: AZCELL

Sysplex Distributor

AB B

C C

D

CR = "Controller Region"SR = "Servant Region"

Configuration map of "AZCELL" configuration on WSCPLEX

D - Application ServersB - Daemon ServersC - Node Agent ServersA - Deployment Manager ServerLegend:

There are two aspects of WebSphere for z/OS Version 5 that we will not cover in this paper:The Integral JMS Provider functionSecurity-related issues (except for the basic RACF profile creation stuff)

Note:

That's the finish line. But what went into getting there? That's what this paper is all about.

We understand that every customer's implementation will be different. This sample implementationis meant as just that -- a sample -- and not as a recommendation to adhere to every aspect of thesample provided.

But there are some "best practice" things that we'll point out along the way.Note:

How to best use this document

We recommend the following:

Scan through the table of contents to get a feel for the things documented in this paper, andthe flow of the paper.

Depending on your experience:If you are already familiar with the process of using the ISPF dialogs, read"Configuration Planning" on page 3 to see the planning that went into this configuration.If you are relatively new to the ISPF configuration process, then start with "BaseApplication Server node created on SYSA" on page 37 and see how the configuration


Version Date: Tuesday, March 09, 2004- 1 -© 2003, IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

process works. Then return to "Configuration Planning" on page 3 to see the planningbehind the configuration values.

Make use of the index at the back of the document to focus in on specific topics.

Other documents on Techdocs

This document may be found on the web at:

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

The Techdocs website is the official home of Washington Systems Center documentation. Weencourage you to browse that site for other valuable information. See "Other Documents onthe Techdocs website" on page 129 for a listing of some of those documents.

Starting Environment: WSCPLEX

The Sysplex environment at the Washington Systems Center consists of four MVS images: SYSA, SYSB, SYSC and SYSD:

SYSA SYSB

SYSC SYSD

CF

z/OS 1.41.5 GB Real

9672-ZZ7

z/OS 1.41.5 GB Real

z/OS 1.41.5 GB Real

z/OS 1.41.5 GB Real

LPAR LPAR

LPAR LPAR

Key Attributes:Single JES2 MASSingle RACF data setShared HFS implementedDistributing VIPA stack

Other Interesting Information:DB2 data sharing group which spans all four systems (plus other DB2 data subsystems)CICS and IMS subsystems which have access to shared and unshared dataWebSphere MQ is active on all systems, though there is currently no shared queue implementation

The WSCPlex environment at the IBM Washington Systems Center

The WSCPLEX environment was designed to provide a great deal of Parallel Sysplex basefunction, and is used to test and demonstrate products that exploit Parallel Sysplex.


Version Date: Tuesday, March 09, 2004- 2 -© 2003, IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

Configuration PlanningAll configurations start with some target in mind. And then various assumptions and otherdecisions are factored in. Let's explore what was done with the configuration documented in thispaper.

High-level configuration objectives

The objective of this exercise was to design and install a WebSphere for z/OS Version 5"Network Deployment" configuration across SYSA and SYSB. We had four main goals:1. No default configuration values were to be used

This was to avoid interfering with any other WebSphere environment that may have made use ofdefault values. It also helps avoid the problem of someone later building a configuration with defaultvalues and interfering with us.

2. Design a naming convention that is meaningful and flexibleThe importance of a good naming convention can't be stressed enough. Our goal to support easyhorizontal and vertical scaling was really a statement about the naming convention we designed. Apoor naming convention might hinder the expansion of the configuration. The naming convention wedesigned -- see "The naming convention used" on page 24 -- supports easy expansion.

3. The configuration design must easily support scaling to SYSC and SYSDConsider this "horizontal scaling" of the WebSphere cell. The thing we wanted to avoid was having tochange things like the naming convention just because the cell was expanded.

4. The configuration design must easily support the creation of additional servers on any of thesystemsConsider this "vertical scaling" of the WebSphere configuration within a given MVS system. Again,the objective was to design the configuration so that adding more servers wouldn't require excessiveadditional work.

So the picture we had in mind was this:

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Server

CR SR

Daemon

CR

Node Agent

CR

Daemon

CR

SYSB

Additional Servers

Additional Servers

SYSC SYSD

Cell Boundary

Goal 3

Goal 4

CF

Expanded Cell Boundary

Goal 1

Use no default values

Goal 2

Meaningful naming

convention

Conceptual picture of configuration design


Section: Configuration PlanningVersion Date: Tuesday, March 09, 2004- 3 -© 2003, IBM Americas Advanced Technical Support

Washington Systems Center, Gaithersburg, MD

This picture, while okay to convey the basic structure of the WebSphere configuration we wereshooting for, doesn't take into account some of the other assumptions and design decisionsthat were necessary. Those come next.

Three key design decisions

In addition to the basic things outlined in the previous picture, we set our sights on three otherdesign objectives:

1. Minimize the number of JCL start procedures

One of the features of WebSphere for z/OS Version 5 is the ability to use a "generic" set of JCLprocedures to start multiple servers. The alternative is to use separate JCL procedures for eachserver. For this configuration we chose the former: as few JCL procedures as we could get awaywith.

2. Minimize the number of RACF userids and groups

With WebSphere for z/OS Version 5, you can go either way on this: minimize the userids/groups orestablish separate identities for each server. For this configuration we chose the former: a minimumnumber of RACF userids and groups, which implies servers are sharing identities.

3. Utilize Sysplex Distributor For clients outside this WebSphere cell, it doesn't matter which Daemon is accessed, or which NodeAgent is used to bootstrap into the environment. Therefore, we wanted to use Sysplex Distributor tobalance that inbound traffic across Daemons with the same port values, and Node Agents sharingports.

Minimize JCL start procedures

As mentioned earlier, the design of WebSphere for z/OS Version 5 permits the same JCLprocedure to be used for multiple servers. More precisely, the same procedure can be usedto start multiple controllers. Another JCL procedure -- different from the controllerprocedure -- can be used to start multiple servants:

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Server

CR SR

JCL

JCL

JCL

JCL

JCLSee note below regarding Deployment Manager's JCL

Daemon:PGM=BBODAEMN

Controller:PGM=BBOCTL

Servant:PGM=BBOSR

One JCL start procedure may be used to start multiple regions

Though at the time of the writing of this document it was possible to use the controller JCLfor both the Deployment Manager controller and the Node Agent/Server controllers, the wordfrom development was to avoid doing this. There is a chance the JCL for the Deployment

Note:




Manager will change in the future, thus eliminating the ability to share the JCL. For now it'sstill possible, but discouraged.

To accomplish this, WebSphere constructs the JCL so the unique infomation is passed inas a start parameter:

//AZACR PROC ENV=,PARMS=' ',Z=AZACRZ// SET ROOT='/wasv5config/azcell' : ://BBOCTL EXEC PGM=BBOCTL,REGION=0M,// PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DF//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z //

S AZACR,JOBNAME=<jobname>,ENV=<aaa>.<bbb>.<ccc>

ENV= value is concatenation of the cell, node and server short name you wish to start. That points to symbolic link in HFS that gives access to the server's configuration file, was.env

The objective is to locate the was.env file. &ENV is symbolic link in HFS that provides shortcut

Structure of JCL permits ENV= to be passed in as START parameter

But using the same JCL for multiple servers only works if all the servers are under the sameHFS mount point. The JCL contains a SET ROOT= line that names the configuration HFSmount point. The value of &ROOT is combined with the passed-in value of &ENV to createthe pointer to the was.env file. If two serves are under different HFS mount points, theywould then require separate JCL as the SET ROOT= is hard-coded in the JCL.




//AZACR PROC ENV=,PARMS=' ',Z=AZACRZ// SET ROOT='/AAA/WebSphere V5' : ://BBOCTL EXEC PGM=BBOCTL,REGION=0M,// PARM='TRAP(ON,NOSPIE),ENVAR...//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Daemon

CR

Node Agent

CR

SYSB

If pieces of your cell's configuration are under different mount points, then it implies using separate JCL because of hard-coded SET ROOT=

/AAA/WebSphereV5HFS

/BBB/WebSphereV5HFS

//AZACR PROC ENV=,PARMS=' ',Z=AZACRZ// SET ROOT='/BBB/WebSphere V5' : ://BBOCTL EXEC PGM=BBOCTL,REGION=0M,// PARM='TRAP(ON,NOSPIE),ENVAR...//BBOENV DD PATH='&ROOT/&ENV/was.env'// INCLUDE MEMBER=&Z

Different HFS mounts points implies different JCL

There are three ways we could have addressed this:

1. Change the JCL so ROOT is a variable passed in on the START commandThis isn't the way WebSphere for z/OS Version 5 works by default, and it would require a fairamount of manual work, particularly for the servant regions that are started by WLM. We lookedat this, but discarded it as an option because of the potential difficulty. (The JCL start proceduresmay be updated by future service PTFs, which would make maintaining customized proceduresmore difficult.)

2. Use a "common" mount point for separate HFS file systems that resolve to asystem-specific mount pointFor example, the mount point would be /var/azcell where that would resolve to/SYSA/var/azcell or /SYSB/var/azcell. This was rejected because it would prevent usfrom doing a cross-system restart. The failed/restarted server might not have its configurationfiles available on the target system.

3. Use a mount point that's shared across all MVS imagesThis is the cleanest and easiest solution. The mount point we used was/wasv5config/azcell, and that HFS is shared across all four systems in WSCPLEX:




//AZACR PROC ENV=,PARMS=' ',Z=AZACRZ // SET ROOT='/wasv5config/azcell' //BBOCTL EXEC PGM=BBOCTL,REGION=0M, // PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DF//BBOENV DD PATH='&ROOT/&ENV/was.env' // INCLUDE MEMBER=&Z //

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Daemon

CR

Node Agent

CR

SYSB

HFS/wasv5config/azcell

A common proc works because HFS mount point is the same for both. We shared the HFS across systems.

HFS/

Shared HFS makes it much easier to minimize the number of JCL procedures used

Having gone through all that, we have seen cases where customers want to useseparate JCL for each controller and servant, even though they have a common mountpoint and could minimize the number of procedures. There's nothing that says you arerequired to use common JCL, just that it's there if you wish to use it. Separate JCLmight make it simpler from an operational point of view. If you code a separate JCLproc for each controller, hard-code the appropriate ENV= string right into the proc andmake the proc name equal to the JOBNAME= value, you can simplify the STARTcommand to just /S <proc>

That will, however, result in more RACF STARTED profiles in play. A trade-off.

Our objective was to minimize, so we went with as few JCL procs as we could.

Note:

Minimize RACF userids and groups

Before you plan on reducing the number of RACF userids and groups,check with your security administrator. We illustrated a reduced set ofprofiles here to show how it is done. But this is not necessarily arecommendation that you do it.

Again, check with your security administrator.

Important Point!

WebSphere for z/OS Version 5 by default will call for the creation of quite a few RACF (orSAF interface) userids and groups. Want a picture to help you visualize it? Here's what thesimplest building block of WebSphere -- the "Base Application Server" node will call for:




Server

Node

Cell

Controller address space

Servant address spaces

UU U

G

U U

G

Daemon address space

G Configuration Group Servant Group

Unauthenticated Userid

Unauthenticated User Group

Daemon Userid

Controller Userid

Servant Userid

Administrator Userid

Base Application Server node's RACF userid and group definitions

The ones highlighted in gray are the ones typically assumed to be unique for each newnode or server.

The non-highlighted ones in the picture above would typically be the same across all nodesand servers of a cell, but that's not strictly required (with the exception of the ConfigurationGroup, which must be the same across the whole cell). The non-highlighted ones are createdby the "Security Domain" configuration process. See "Security Domain Configuration" onpage 31.

???

Is it required that you create new userids for each new controller, servant and daemon youcreate? No. It is possible to collapse the number of userids and groups to a minimum set.And that's exactly what we decided to do with the AZCELL configuration. Here was the planfor the AZCELL configuration:

AZACRU

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

AZASRUController ID

Servant ID

Same values used for additional systems and

additional servers

AZCFG AZSRVG

Config Group Servant Group

AZCELL plan: one Controller ID and one Servant ID for the entire configuration




To keep that chart from getting too cluttered, some of the other identities aren't shown. Herethey are:

Administrative ID and Group: AZADMIN / AZADMINUnauthorized User ID and Group: AZGUEST / AZGSTGP

The UID/GID values also aren't shown. Again, this was done to reduce the clutter of thechart.

Note:

You may wonder: "Where did you get those names?" That goes to the question of thenaming convention decided upon. That's a whole separate topic, covered under "Thenaming convention used" on page 24.

How the RACF profiles are created

The RACF profiles can be broken down into two broad categories:

1. Those that are common to the cell, and therefore should be consistent across everynode of the cell, and

2. Those that are specific to a given application server

Security Domain

Starting with W502000, the profiles in the first category were separated out into aseparate configuration option in the ISPF customization panels. This option is called"Configure Security Domain." This option produces two important things:

ISPF Customization

Dialogs

Variables saved into "SDCFG" data set

Cell-wide RACF

profilesCustomized batch RACF

script

1

2

Two important pieces of output from the "Configure Security Domain" option

The cell-wide RACF profiles that are created are the following:

WebSphere Configuration Group InformationWebSphere Administrator InformationUnauthenticated User Definitions for Base ServersWebSphere Asynchronous Administration TaskServant group for base servers

As well as some SSL and EJBROLE information that we won't cover in this document.

But it's the variables file (the "SDCFG" file) from the process that's interesting. It is thatfile carried forward and used as input to the other ISPF options -- BaseAppconfiguration, Deployment Manager configuration and Federation configuration -- thatprovides the consistency of those key variables. Later we'll see how the SecurityDomain is configured and how the SDCFG file is made use of in the other configurations.

Server-specific profiles

When the Base Application Server node is configured, the "Server Customization"panels will ask for the IDs to be used for the controller, servant and Daemon. Whatever




values you provide there will be folded into the customized job used to create theserver-specific profiles.

What about the group information? It'll know what group to connect the IDs to because akey step in configuring a BaseApp server (or Deployment Manager, for that matter) isloading in the saved variables from the Security Domain configuration -- the SDCFG file.

???

The ISPF customization dialogs generate a REXX-based RACF script that can be usedto create the RACF profiles. The job hlq.CNTL(BBOCBRAJ) has a switch inside thatallows you to control when and how the actual RACF commands are issued:

://SYSTSIN DD * BBOWBRAC 'issuecmds(n) '/* :

BBOCBRAJ

If "Y"

If "N"

BBOWBRAC

DATA

BBOWBRAK

DATA

Run the REXX-based RACF

commands in BBOWBRAC

Generate in-line RACF commands

in BBOWBRAK member

BBOCBRAJ job creates RACF profiles directly, or generates easier-to-read inline commands

The default is "N," which means the RACF commands are generated and placed in theBBOWBRAK member of the DATA data set. The hlq.CNTL(BBOCBRAK) job may then beused to issue the commands:

//BBOCBRAK JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M,// USER=SYSADM1,PASSWORD=xxxxxx //* /*JOBPARM SYSAFF=SYSA //BBOCBRAK EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSEXEC DD DISP=SHR,DSN=WAS500.AZBASEA.DATA //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * %BBOWBRAK /* //

BBOWBRAK

DATA

RACF

Note: The Deployment Manager's jobs have slightly different names: BBODBRAJ and BBODBRAK

BBOCBRAK batch-invokes in-line RACF commands in BBOWBRAK member

Why this two-step process? Many people do not like the REXX-based script found inBBOWBRAC. All the RACF commands are in there, but it takes some effort to sort throughthe REXX statements and find them all. The in-line commands generated into BBOWBRAKare much more straight-forward and easy to read. Therefore, they're much easier tounderstand and modify if needed.

???

Use generated BBOWBRAK or create your own

The generated RACF commands are very specific: if, for example, your applicationserver MVS job name is AZSR01A, the RACF STARTED profile for the controller will beAZSR01A.*.




But what if your plan calls for 99 different servers -- AZSR01A through AZSR99A -- andyou don't want 99 different STARTED profiles? Well, you're always free to take theRACF commands generated into BBOWBRAK and modify them to be more generic.That's exactly what we did for this AZCELL configuration.

If you're unfamiliar with RACF commands, or if you're somewhat unsure of what all theprofiles in BBOWBRAK do, then we recommend you stick with the generated profiles.Security profile errors can be difficult to debug.

Note:

The customized RACF commands can be run with the BBOCBRAK job. Simply point towhatever data set and member in which the commands reside:

//BBOCBRAK JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M,// USER=SYSADM1,PASSWORD=xxxxxx //* /*JOBPARM SYSAFF=SYSA //BBOCBRAK EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSEXEC DD DISP=SHR,DSN=WAS500.AZBASEA.DATA //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * %BBOWBRAK /* //

<your data set>

BBOCBRAK can be used to run customized RACF commands

The RACF commands used for this configuration is provided under "Appendix B -Customized RACF profile used for this configuration" on page 107. Notes about whatwas changed and why are included inline with the sample RACF script.

Use RACF AUTOUID and AUTOGID functions

One of the things incorporated into the RACF commands used for the AZCELLconfiguration was the use of the AUTOUID and AUTOGID functions. Those functionsautomatically assign UID or GID numbers. These became available in z/OS 1.2. It's afairly simple function to use:

ADDGROUP AZCFG OMVS(AUTOGID)With "auto" function:

ADDGROUP AZCFG OMVS(2500)Without "auto" function:

See "Appendix B - Customized RACF profile used for this configuration" on page 107 tosee the AUTOUID and AUTOGID function in use in those commands.

Even if you use the ISPF-generated BBOWBRAK job you can still use the AUTOUID andAUTOGID function. Simply edit the hlq.DATA(BBOWBRAK) member and insertAUTOUID and AUTOGID wherever hard-coded values exist in the commands.

Notes:

A note about UID/GID values found in other customized jobs

You should be aware that the UID/GID values you provide on the ISPF panels findtheir way into other customized jobs as well, not just the jobs that create the RACFidentities. For example, the job BBOWCHFS is what's used to create the HFS filesystem for the configuration, the mount point onto which it will be mounted, and thenmount the file system. BBOWCHFS points to the BBOWCPYD member in the DATA dataset, which is what creates the mount point and mounts the file system. Thatmember looks like this:




BROWSE WAS500.AZBASEA.DATA(BBOWCPYD) Command ===>********************************* Top of Data ************************BBOWBMPT '/wasv5config/azcell OMVS.WAS.AZCELL.CONFIG.HFS 2403 2500'

File owner UID from ISPF panel

Group owner GID from ISPF panelMount Point

HFS file system data set (allocated in BBOWCHFS JCL)

Contents of the BBOWCPYD member: creates mount point and mounts HFS

If the BBOCBRAK job (the job that creates the RACF profiles) was run with theAUTOUID and AUTOGID functions in place, then the actual UID and GID valuesassigned to your intended file owner and group will be different from what was in theISPF panel.

When the BBOWCHFS job is run, the UID and GID in the BBOWCPYD member will beused to create the mount point and mount the file system. Those UID and GIDvalues will not correspond to an actual RACF userid or group, but the mount pointwill be created anyway. If you were to list the newly-created directory using the ls-al command, it would show the file owner and group as the UID and GID, ratherthan the resolved Userid and Group:

drwxrwxr-x 2 2403 2500 8192 Oct 23 10:21 azcell

drwxrwxr-x 7 AZADMIN AZCFG 8192 Sep 10 10:26 azcell

But if UID/GID wasn't defined earlier by BBOCBRAK job, then directory will show only UID/GID values found in BBOWCPYD member

If there's a userid and group assigned to the UID/GID used in BBOWCPYD, then when you list

the directory you'll see that userid and group

UID and GID values shown as owners of directory rather than Userid and Group

Is this a problem? It turns out that it is not a problem. Here's why: the BBOMCFG2job -- the last one run -- will sweep through and reset all the file and directoryownerships to the proper values. That job "finalizes" the HFS. So any issues ofdirectories not being owned by a defined userid at this point are corrected whenBBOMCFG2 is run.

Other considerations taken into account

In addition to the things just discussed, other things were understood, taken into account anddecided upon:




Daemons

Daemons are perhaps the least understood component of the configuration. A Daemon is asingle controller server. A Network Deployment configuration that spans MVS images in aSysplex will have one Daemon per system over which the cell spans:

SYSA

Daemon Deploy. Manager

Node Agent

Appl. Server

SYSB

Daemon

Node Agent

Appl. Server

SYSn

Daemon

Node Agent

Appl. Server

Network Deployment Cell

Node Node Node

Rule of thumb: one Daemon per system (node) per cell

What does a Daemon do? Its role in life is to provide "location name services" to the node;that is, be able to resolve indirect object requests from external clients into direct references.That's all fairly obscure stuff if you're not already familiar with the concepts. Suffice it to say, aDaemon is required. Kill the Daemon and all servers related to that Daemon come down aswell.

???

It is important to understand that in the creation of a Network Deployment configuration, anode goes through two life cycles: first, as a Base Application Server node; and then, whenfederated, a Network Deployment configuration node. In both phases of its life, the noderelies upon the services of a Daemon, but the Daemon it relies upon is different beforefederation as compared to after. (See "What federation does" on page 61 for a high-levelexplanation of what "federation" is all about.)

All nodes must have access to the services of a Daemon. A Base Application Servernode has its own Daemon. After federation the newly federated node will rely upon adifferent Daemon. What Daemon a federated node will use after federation isdependent on whether that node is on the same MVS image as the DeploymentManager or not.

Key Points:

BaseApp node federated into Deployment Manager cell on same MVS image

When a Base Application Server node is federated into a Deployment Manager cell onthe same MVS image, the BaseApp's Daemon is set aside. The federated node startsusing the Deployment Manager's Daemon:




SYSA

DaemonDeploy. Manager

DaemonAppl.

Server

Deployment Manager

Cell

Base Application Server node

Before Federation

SYSA


Node Agent

Appl. Server

After Federation

Daemon

Base Application Server node's Daemon (and cell) structure "set aside" and no longer used after federation.

Before and after federation: the Daemon that supports servers on same MVS image

As the picture illustrates, when a Base Application Server node is federated into aDeployment Manager cell on the same MVS image, the already existing DeploymentManager Daemon simply picks up more work. But the original Base Application Servernode's Daemon is no longer used.

A Base Application Server node's Daemon should be considered temporary. It isonly used until the node is federated. Thereafter, the BaseApp's Daemon is nolonger used. That means the following things are temporary when a BaseApp isintended for eventual federation into a Deployment Manager cell:

Original BaseApp Daemon's short name and JOBNAME valueOriginal BaseApp Daemon's TCP ports

We'll go into further detail on this later.

Key Points:

BaseApp node federated into Deployment Manager cell from different MVS image

Things are slightly different when the Base Application Server node being federated ison a different MVS image from the Deployment Manager. The original BaseAppDaemon is still set aside, but a new Daemon is created:




Deployment Manager

Cell


SYSA


Before Federation

SYSB

DaemonAppl.

Server

Daemon

Base Application Server node's Daemon (and cell) structure "set aside" and no longer used after federation.

SYSA


After Federation

SYSB

NEW Daemon

Node Agent

Appl. ServerNew Daemon is copy of

Deployment Manager's Daemon, including short

name, JOBNAME and ports

Before and after federation: NEW Daemon supports servers on different MVS image

There are two points to be made here:

Base Application Server node Daemons are temporary if that BaseApp is federated.It doesn't matter if the BaseApp is on the same MVS image or different from theDeployment Manager.

The Daemon of any Base Application Server node intended for federationshould be considered temporary.

Key Point:

When a Base Application Server node on a different MVS image from theDeployment Manager is federated, the new Daemon that is created is identical to theDeployment Manager's Daemon: same TCP port values, same short name value,same JOBNAME value.

The Deployment Manager's Daemon should be considered a cell-wideresource. The short name and JOBNAME values should not contain asystem-specific identifier since the same values may be used on multiple MVSimages. And the TCP ports for all Daemons in a Network Deploymentconfiguration will be the same.

Key Point:

Wrap up discussion on Daemons

This topic was provided at this point because we're about to launch into a discussion ofTCP port allocations and naming conventions. Daemons introduce a unique twist intothose topics, so it was important to get across the key points made in this section.

Fence off a small range of TCP ports and use instead of default port assignments

WebSphere for z/OS Version 5, as shipped, makes use of a considerable number of ports.Further, the default values are spread out over a wide range. This makes the managementof the ports for a "test" and "production" (as well as "QA" and "dev" and others) verychallenging. Care for a picture?




Cell

CR SR

Dep. Mgr

CR SR

App Server

CR

Node Agent

CR

Daemon

8880

7973

9811

0

9080

9443

SOAP JMX

DRS Client

ORB port

ORB SSL port

HTTP port

HTTP SSL

For each application server:

8879

7277

7989

9809

0

9090

9043

SOAP JMX

Cell Discovery

DRS Client

ORB port

ORB SSL port

HTTP port

HTTP SSL

For each Deployment Manager

5755

5756Daemon ports

For each Daemon

2809

7888

7272

5000

2809

0

8878

SOAP JMX

DRS Client

Node Discovery

Node Multicast

ORB Listener

ORB SSL

SOAP Connector

For each Node Agent:

Default ports ... not what this example configuration will use

Ports and their default assignments for a simple Network Deployment configuration

Therefore, we decided that for each cell environment a range of ports would be set aside,and the ports would be given to the WebSphere components from that range during theISPF customization effort. The port range chosen for the AZCELL configuration was 9500to 9600. No default port values would be used.

How the fenced-off ports were allocated to the various servers

The following picture illustrates how the ports between 9500 and 9600 were allocatedbetween the servers:

Daemons Dep. Manager Node Agents azsr01 azsr02JMX Soap 9510 9520 9540 9550DRS 9511 9521 9541 9551Bootstrap 9512 9522 9542 9552ORB IIOP 9500 9512 9522 9542 9552ORB SSL 9501 9513 9523 9543 9553Discovery 9514 9524Multi-cast 9525HTTP 9518 9548 9558HTTP SSL 9519 9549 9559

Server Clusters

95-forty range

95-fifty range

Interim ORB: 9506

Interim ORB SSL: 9507For BaseApp Server Daemons:

Fenced-off ports allocated across the servers in predetermined manner

This diagram bears some explanation:

Daemon ports

As described under "Daemons" on page 13, Base Application Server node Daemonsare considered temporary. The ports assigned to a Base Application Server node's




Daemon are used only until that node is federated. That's why we set aside twoports -- 9506 and 9507 -- to serve as "interim ports" for the Base Application Servernode Daemon.

The "permanent" Daemon ports are the ones assigned to the Deployment Manager.Those same ports are copied to Daemons created when a Base Application Servernode on another MVS image is federated into the Deployment Manager cell.

Did we need two sets of "interim" ports, one set for the Base Application Servernode on SYSA and one set for the BaseApp on SYSB? No. We could have donethat, but we decided instead to simply reuse the same two ports (9506 and 9507)for the two Base Application Server Daemons we knew to be temporary.

Deployment Manager ports

There can be only one Deployment Manager in any WebSphere cell. For the AZ cellthe ports assigned are shown on the chart. They fall in the 9510-9519 range.

Node Agent ports

There will be a Node Agent per MVS image on which the AZ cell spans. Our designcalls for all Node Agents to have the exact same ports (so we can use SysplexDistributor to balance the traffic between the two). Those ports 9520-9529 range,as shown on the previous chart.

The Node Agent is created when the BBOWADDN customized job is run. See"Federated Base Application Server node on SYSA into the DM cell" on page 61 forthe steps involved with customizing the BBOWADDN job and federating the node.

Note:

Server clusters

A server cluster is a grouping of two or more servers into a logical one. You createa cluster through the administrative console. Servers within a cluster are called"cluster members." Servers ("members") within a cluster start out being clones ofone another.

See "Application servers are considered to be a member of a cluster" on page 20 formore on the concept of clusters. See "Cluster created across SYSA and SYSB" onpage 91 for how to actually create the cluster through the administrative console.

Note:

When it comes to the TCP ports for the members in a cluster, the administrativeconsole allows you during the creation of the cluster to specify if you want the HTTPports to be unique or the same. The other ports -- bootstrap, DRS, ORB, ORB SSLand SOAP -- will be made unique by WebSphere. For the AZCELL configuration wewanted members of a cluster to be as nearly identical to one another as possible,including the TCP ports.

Therefore, in our planning we allocated a range of ports for a cluster, and intendedto make certain all members of that cluster were given the same set of ports.Because WebSphere was automatically generating unique DRS, ORB, ORB SSLand SOAP ports for the second cluster member, it meant we had to go back in andre-map the ports back to the ports set aside for this server cluster (see "TCP ports ofnew clustered server remapped" on page 93).

We ruled out creating what's known as a "vertical cluster" -- two members on thesame MVS image. Therefore, we didn't have to worry about port sharing by twomembers of the same cluster on the same MVS image.

Note:




The initial plan called for two server clusters: azsr01 and azsr02. The portranges for each were:

9560 - 9569 (If it were configured; this paper does not show it yet built)azsr03

9550 - 9559azsr02

9540 - 9549azsr01

If you were constructing a cell you knew was going to have many clusters, you'dfence off more than the 100 ports we fenced off for this configuration.

Note:

Utilize Sysplex Distributor

Sysplex Distributor is the function of z/OS TCP/IP that provides a way to intelligentlydistribute TCP traffic within a Sysplex environment. Clients out on the network direct theirrequests to the DVIPA address. ("Dynamic Virtual IP Address" -- a virtual address hostedat any given moment by one of the TCP stacks in the Sysplex, and capable of being takenover by another TCP stack in the event the first TCP stack fails.) The TCP stack that'shosting the DVIPA then intelligently balances the requests across all the processes in theSysplex that are listening on the ports defined as eligible for this kind of routing. Not allports are distributed by Sysplex Distributor; only those defined to TCP/IP.

Parameters in the TCP PROFILE data set instruct TCP which ports to distribute:

:VipaDistribute 9.82.25.13 port 9500 9501 9522 9523 DESTIP ALLVipaDistribute 9.82.25.13 port 9548 9549 DESTIP ALL :

The DVIPA address Any request received on the VIPA and destined for

these ports will be distributed across the

systems in the Sysplex

wsccb.washington.ibm.com DNS

Definitions in TCP PROFILE determine which ports will be distributed

The ports shown on the first line of this example relate to the ORB IIOP and ORB SSL portswe used for the Daemons and the Node Agents. We wanted clients on the network tocome to the DVIPA address rather than a system-specific host name. Our AZCELLconfiguration plan calls for all Daemons to use ports 9500 and 9501, and all Node Agentsto use ports 9522 and 9523 for the bootstrap ports.

The ports shown on the second line of this example relate to the HTTP and HTTP SSLports for server cluster AZSR01. We made a decision to have all members in a cluster havethe same TCP ports, including HTTP ports (see "How the fenced-off ports were allocated tothe various servers" on page 16).

The picture of what Sysplex Distributor is used for looks like this:




SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


95009501

95009501

95229523

95229523

95489549

95489549

Sysplex Distributor

IIOP

IIOP

HTTP

IIOP

IIOP

HTTP

Use of Sysplex Distributor and the ports involved

Server AZSR02B is not yet clustered. Therefore, it's ports (9558, 9559) are not yet partof the Sysplex Distributor configuration.

If HTTP session objects are used by an application, then it becomes necessary tomaintain session affinity (the routing of subsequent requests back to the controllerbehind which the session object exists). Sysplex Distributor does not have sessionaffinity functionality. There are ways to get around this -- "persist" the objects to DB2 somultiple servers can access the object, or make use of WebSphere's "DomainReplication Service" (DRS) to copy objects from the memory of one server to another.Those topics are beyond the scope of this document at this time. We assumed nosession objects, so our use of Sysplex Distributor to balance HTTP between serverclusters was okay.

Notes:

Make use of dynamic WLM application environments

Dynamic WLM application environments is a function of WLM that became available withAPAR OW54622. With that new function, programs may dynamically create applicationenvironments on the fly. WebSphere for z/OS Version 5 is a program that is designed tomake use of the dynamic WLM application environment if it sees the function available.

Generally speaking, this is a function of WebSphere you can't turn off: WebSphere will usethe dynamic capability of WLM if it's there; otherwise it'll rely on static WLM applicationenvironments. Static application environments still in existence when APAR OW54622 isapplied will simply stop being used in favor of dynamically created ones of the same name.

Interestingly enough, there's no conflict between a static WLM application environmentnamed "XYZ" and a dynamically created one of the same name "XYZ."

The use of Dynamic Application Environments makes configuring horizontal clustersconsiderably easier. If you plan on configuring horizontal clusters, make sure OW54622is present. See "Why WLM Dynamic Application Environments helps in configuringhorizontal clusters" on page 122 if you're interested in an explanation of that.

Notes:




Allow no more than one node per system in the cell

What we're getting at here is this:

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Node Agent

CR

Cell extends to SYSBRuled Out:

Two nodes in the same cell on the same MVS image

Two nodes within the same cell on the same MVS image won't be allowed

The primary reason for imposing this limitation is because of the intent to use SysplexDistributor for the bootstrap port of the Node Agents. We wanted to have all the nodeagents in the cell listening on the same bootstrap port (9522 in this configuration). Twonode agents on the same MVS image listening on the same port might imply TCP portsharing, which we didn't want to do. So it was decided to limit the configuration to one nodeper MVS image.

It's possible to have multiple TCP stacks on the same MVS image, and to tie a port to aspecific TCP stack. The AZCELL configuration doesn't do this.

This configuration has multiple nodes, but they're on separate MVS images. Therefore,each has its own TCP stacks with separate IP addresses.

There's very little reason to configure multiple nodes in the same cell on the same MVSimage. Some think that offers greater isolation, but in reality there's very littleadministrative isolation between nodes in a cell.

Note:

Once a node is created on an MVS image and becomes part of the AZCELL configurationcell, no other nodes will be federated on that MVS image. If more servers are desired onthe MVS image, servers will be added to the existing node rather than federating in morenodes.

A single error log stream used for all components in this cell

Since WSCPLEX is a parallel sysplex, it will have a common error logstream rather than adifferent logstream for each node. It just makes things easier.

Application servers are considered to be a member of a cluster

To fully explain what this means, we have to back up a step and explain a few things aboutclusters in WebSphere for z/OS Version 5.

Definition of a cluster

In WebSphere for z/OS Version 5, a "cluster" is a grouping of multiple servers into alogical "one server." WebSphere views that cluster as a logical entity. (For example




applications are installed into a cluster, and WebSphere handles installing theapplication into all servers that are part of that cluster.) In picture form, it looks like this:

SYSA

Node Agent

Server_A

CR SR

Server_B

CR SR

Daemon

CR

Node Agent

CR

SYSB

CR

DM

CR SR

Daemon

CR

These two application servers are clones of one another.

Cluster

Clustered servers are considered by WebSphere to be a logical entity

You may have any number of servers in a cluster. We represent two here for simplicity.

Though it is possible to create a cluster where all the cluster servers reside on a singlenode (that's known as a "vertical cluster"), for the AZCELL configuration we decided tolimit clusters to "horizontal clusters" -- like what's illustrated in the previous diagram.

Note:

How clusters are created -- the first server in cluster defined

Clusters are created through the administrative console of WebSphere. Under the"Servers" branch of the navigation tree of the admin console you'll find a link called"Clusters." What you'll see is something like this:

<existing clusters>

"New" button starts process of defining a cluster

Previously defined clusters will be

listed here

Panel under "Servers" "Clusters" in administrative console

After clicking the "New" button you'll be taken to the first panel used to create a cluster.It's there that you get to choose the first server that will become part of your new cluster.You may choose an existing server or create a new server for this purpose:




Name of your cluster here

Create a new server as the first server in cluster(next panel is where you

create this server)Select an

existing server as the first

server in the cluster

First server in the cluster may either be a brand new server, or an existing server

If you choose to go the route of defining a new server as the first server in the cluster,you'll be given the opportunity to model that new server after an existing server, ormodeling it after a standard template supplied with WebSphere.

Note:

Creating the other servers in the cluster

Once the first server in the cluster is decided upon, the other servers in the cluster arethen created. They will all be clones -- copies -- of that first server.

Well, there are some differences ... the names of the servers will be different, the HTTPports may be different, and the other TCP ports will initially be different. But all theserver settings -- environment variables, JVM settings, etc. -- will be the same.

Note:

It is in "Step 2" in the previous picture where the additional servers are created. It's asimple process

That leads to the next point ...

Can't cluster two existing servers -- servers in cluster must be clones

It is tempting to think that creating a cluster involves selecting two already-createdservers and grouping them into a cluster. But that is not the way it is done. As pointedout in the previous two headings, the process of creating a cluster involves:

Selecting your first server (existing server or new server)

Cloning that server to form the other servers in the cluster

Cluster short names

When you create your cluster, you will not initially be given the chance to provide the"cluster short name." The long name, yes; the short name no. WebSphere will assignthe cluster short name, and the value WebSphere will assign will be based on whatserver was your initial server of the cluster:




Existing server -- the cluster short name will be made equal to the "ClusterTransition Name" of the server you selected as the initial server. Recall that the"Cluster Transition Name" of the original Base Application Server was the WLMapplication environment name for that server. You can start to see why thedesigners of WebSphere used the term "Cluster Transition Name" to refer to thatfield in the ISPF panels: that value becomes the cluster short name when you pickthat server to be the starting server for a cluster.

New server -- the cluster short name will be assigned default value of BBOC00n,where "n" is a number incremented as needed to maintain uniqueness. This is avalue you'll likely want to change to match your naming conventions. For theAZCELL configuration, that value was changed to AZSR01.

To change the value, display the clusters in your cell, click on the link that representsyour cluster, change the value for the short name and then save to the masterconfiguration.

???

The WLM application environment for cluster members

WebSphere for z/OS Version 5 does an interesting thing with all the servers in a cluster:it assigns them all the same WLM application environment name. WebSphere assumesthe WLM application environment name that will be used is equal to the cluster's shortname.

The short name for a cluster is also that cluster's WLM application environmentname for all the servers in the cluster.

Key Point:

In the previous section we saw where the cluster short name came from: either the"Cluster Transition Name" of an existing server used to start the cluster, or BBOC001 ifyou created a brand new server to create the cluster.

The reason for our bringing this to your attention is to help illustrate the fairly closerelationship between the server short name, the "Cluster Transition Name" and theWLM application environment name used for the members of a cluster.

Where are we leading with this? Plan from the start and assume that all servers will beconsidered part of a cluster.

Bring it all together: servers considered to be a member of a cluster

So we're back to the original point: for the AZCELL configuration, all application serverswill be considered to be part of a cluster.

That does not mean all application servers are members of a cluster. It means that inthe design of the configuration -- and in particular the naming convention -- the possibilityof a server joining a cluster is taken into account from the start.

Note:

In making this assumption, we tied together three names: the server short name, theserver's WLM application enviornment name and the cluster short name:




AZSR01A

Cluster short name

Node indicator

("A"=SYSA)

Server short name

WLM application

environment=

Relationship between the cluster short name and the server shorts names in the cluster

To illustrate this, consider the following picture. This picture illustrates our two-systemconfiguration with one cluster, and the creation of a new server:

SYSA

Node Agent

AZSR01A

CR SR

AZSR01B

CR SR

Daemon

CR

Node Agent

CR

SYSB

CR

DM

CR SR

Daemon

CR

Cluster Name: AZSR01WLM ApplEnv: AZSR01

AZSR02B

CR SRThough this server is

not yet part of a cluster, everything is in place to

include it in a cluster and maintain our

naming conventionServer Name: AZSR02BWLM ApplEnv: AZSR02Future Cluster: AZSR02

Creation of a new server and considering it part of a cluster, even though initially it is not

See "Cluster created across SYSA and SYSB" on page 91 for an illustration of how acluster was built for this configuration.

There's been a good deal of reference to a "naming convention." What namingconvention did we settle upon? Let's explore that next.

The naming convention used

A strong, flexible naming convention is critical to the success of your WebSphere for z/OSVerstion 5 experience. There are simply too many things that require naming to approach theeffort without some planning up front. Plus, there's a good deal of inter-relatedness to thenames.

For a quick table summary of the naming convention, see "Summary of naming conventionsused" on page 29.

Note:




Starting point: JOBNAME values

The place to start your planning is the started task JOBNAME values. For the AZCELLconfiguration, we chose a naming template that looks like this:

Cell Identifier Component Identifier System

IdentifierServant

Flag

a a b b b b c d

2-character alpha-numeric that indicates the WebSphere cell this started task applies.

Example: AZ

4-character alpha-numeric that identifies the type of component:

Application Server: SRnnWhere nn is 01-99, AA-ZZ identifier

Node Agent: AGNTDeployment Manager: DMGRDaemon: DEMN

Example: SR01

1-character alpha-numeric that indicates the system on which the component is running. For WSCPLEX, letters A, B, C or D would apply.

Example: A

Fixed character S to indicate a servant region.

Example: S

AZSR01AS"Server 01 servant in Cell AZ, running on SYSA"

Naming convention for started task JOBNAME values

It's important to understand that there's no magic to the number of bytes allocated to "cell"versus the number of bytes allocated to "component" and so on. You can use more for oneand less for another. The key points here are:

Have a common first set of characters so all associated jobs can be displayed on the DApanel (next topic)

Leave one character at the end (eighth byte) so WLM can append the S for the servantregion jobname.

Note:

More on the Daemon JOBNAME values

As we saw back in "Daemons" on page 13, Base Application Server node Daemons aretemporary. They are of concern only up until the time the node is federated. After thatpoint, the original Base Application Server node Daemon is set aside and no longerused. The Deployment Manager's Daemon -- or a copy of it -- are used.

When it comes to planning JOBNAME values for Daemons, keep the following in mind:

The Deployment Manager Daemon's JOBNAME will be used for all Daemons in theNetwork Deployment configuration. Therefore, you do not want to apply a systemidentifier to it. Make that JOBNAME value generic.

Base Application Server node Daemon JOBNAME values are temporary. Go aheadan apply a system identifier to them. When that node is federated, the Daemongoes away and the Deployment Manager's Daemon (or copy of it) is used.

For the AZCELL configuration, we named the Deployment Manager Daemon somethinggeneric: AZDEMN (no system identifier). The Base Application Server node Daemons




were given a system identifier: AZDEMN1 and AZDEMN2 (a departure from the "A" and"B" system identifiers, but minor and harmless due to temporary nature of the BaseApplication Server node Daemons).

Operational benefit of structured naming convention

Right away there's a benefit you should see in having a naming convention where thefirst set of characters is common across the cell: a display of the active jobs using theSDSF DA panel will yield a tidy list of all things related to your cell:

COMMAND INPUT ===> PREFIX=AZ* DEST=(ALL) OWNER=* SYSNAME=SYSANP JOBNAME StepName ProcStep JobID AZAGNTA AZAGNTA BBOCTL STC05351 AZDEMN AZDEMN BBODAEMN STC05347 AZDMGR AZDMGR BBOCTL STC05360 AZDMGRS AZDMGRS BBOSR STC05362 AZSR01A AZSR01A BBOCTL STC05457 AZSR01AS AZSR01AS BBOSR STC05458

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Application Server

controller and servant

Deployment Manager

controller and servant

Node Agent

Daemon

Structured naming convention allows you to quickly see all tasks related to your cell

Server JCL start procedure names

Back under the heading "Minimize JCL start procedures" on page 4 it was shown how just afew JCL procedures would be used for all the servers in the configuration. The absoluteminimum number of JCL procedures needed would be three:

1. Daemon start procedure

Name: AZDMN

This requires a separate JCL proc from the other servers because the program modulestarted is different: BBODMN. Only the Daemon uses that program, whereas forexample every controller uses BBOCTL.

2. Controller start procedure

Name: AZACR

All controllers in the configuration (with the exception of the Daemon controller, which isunique) make use of the program BBOCTL. Using one JCL procedure for all thecontrollers works because the entire configuration is under one HFS mount point. TheENV= string is used at server startup to indicate which of the many servers is to bestarted.

3. Servant start procedure

Name: AZASR




Similar to the controllers, all servants in the configuration make use of the programmodule BBOSR. WLM starts the servants and the JCL proc and ENV= string are codedin the WLM application environment.

It is generally recommended that a separate set of JCL procs -- the set generated by theISPF customization dialogs for the Deployment Manager -- be used for the DeploymentManager. The JCL is slightly different (difference in the PARMS= field) and has the chance ofgetting more different as time goes by. That said, at the time of the writing of this documentit still worked to use the same JCL for the Deployment Manager and the other servers in theconfiguration. So that's what was done.

Note:

Server short and long names

"Short names" are a WebSphere for z/OS thing. They don't exist on the other platforms.They were invented to accomodate some of the length limitations of MVS. "Long names"are what is displayed on the WebSphere administrative console. Short names are limited to8 characters; long names may be much longer than that.

It makes good sense to have the server short names closely related to the JOBNAME valuesfor those started regions. The naming convention adopted for the JOBNAME values wasillustrated under "Starting point: JOBNAME values" on page 25. Therefore...

The server short names will be identical to the JOBNAME values for the controller.Servant JOBNAME will be the server short appended with an S.

Key Point:

To keep things simple, the AZCELL configuration uses the same value for the long name asthe short name. The difference is the long name is folded into lowercase, where the shortname, because it's so MVS-oriented, is in uppercase. For example:

azsr01aServer long name . . . . . . .

AZSR01AServer short name . . . . . .

To illustrate the names for the servers on SYSA, consider this table:

Notes:Long names for the Daemons, Deployment Manager and Node Agents don't apply. WebSphereuses default values when displaying those entities on the administrative console.The Deployment Manager's Daemon has no system indicator, as described under "More on theDaemon JOBNAME values" on page 25. The Base Application Server node Daemon name is atemporary thing -- good only until federation and then unused thereafter. For the AZCELLconfiguration we put a number at the end of this temporary name. We probably should haveused the system indicator A, B, etc. The Deployment Manager short name could have a system indicator, but in this case it does not.There is only one Deployment Manager per cell. For AZCELL it is known to be on SYSA.

AZSR02Aazsr02aAZSR02ASecond Application Server

AZSR01Aazsr01aAZSR01AFirst Application Server

AZAGNTAn/aAZAGNTANode Agent

AZDMGRn/aAZDMGRDeployment Manager

AZDEMN1n/aAZDEMN1Base Application Server node Daemon

AZDEMNn/aAZDEMNDeployment Manager Daemon

ControllerJOBNAMELong NameShort NameServer




Cell and Node short and long names

There is only one cell in this configuration and the name for that cell is AZCELL. The firsttwo characters AZ is the cell indicator throughout this naming convention. The string CELLis simply a fixed string. The cell long name is identical to the short name, only in lowercase:

azcellCell long name . . . . . . . . .

AZCELLCell short name . . . . . . . . .

The initial configuration plan called for two nodes (on SYSA and SYSB) with the ability toexpand to SYSC and SYSD if needed. The node naming structure decided upon wasAZNODEx, where "x" is the system indicator. Therefore:

azdmnodeDeployment Manager Node long name . . . .

AZDMDeployment Manager Node short name . . .

aznodebSYSB Node long name . . . . . . . . . . . . . . . . .

AZNODEBSYSB Node short name . . . . . . . . . . . . . . . .

aznodeaSYSA Node long name . . . . . . . . . . . . . . . . .

AZNODEASYSA Node short name . . . . . . . . . . . . . . . .

Cluster naming and WLM application environment names

Back in the section titled "Application servers are considered to be a member of a cluster"on page 20 we discussed in detail the relationship between server short names, WLMapplication environment names and the cluster name. In picture form, the relationship lookslike this:

AZSR01A

Cluster short name

Node indicator

("A"=SYSA)

Server short name

WLM application

environment=

Relationship between the cluster short name and the server shorts names in the cluster

Since one of the design assumptions of this configuration was that all servers wereconsidered to be part of a cluster, cluster names are derived from the short name of theserver used to create the cluster. The WLM application environment name for a cluster willalways be equal to the cluster short name (WebSphere does that). So the solutionillustrated in the previous diagram provide seamless naming between an unclustered serverand that same server after it is joined into a cluster.




Summary of naming conventions used

Cell and node names

aznodebAZNODEBNode on SYSBaznodeaAZNODEANode on SYSAazcellAZCELLCell

Long NameShort Name

Daemon Servers

n/aAZDEMNDeployment Manager

Daemon and allpost-federation Daemons

n/aAZDEMN2BaseApp Daemon on SYSBn/aAZDEMN1BaseApp Daemon on SYSAn/aAZDMNJCL start procedure

Long NameShort Name

The final configuration will have two Daemons -- one on SYSA and one on SYSB. BothDaemons will be indentical in name. Prior to federation, the Daemons for each BaseApplication Server node have a name different from the Deployment Manager'sDaemon. Those names were AZDEMN1 and AZDEMN2 for SYSA and SYSB respectively.See "More on the Daemon JOBNAME values" on page 25 for an explanation of Daemonnames.

Note:

Deployment Manager Server

n/aAZDMGRWLM ApplEnvn/aAZACRJCL start proceduren/aAZDMGRSServant MVS jobnamen/aAZDMGRController MVS jobnamen/aAZDMGRServer name

Long NameShort Name

Node Agent Server

Note: the Node Agent's long name is a fixed value of "nodeagent."n/aAZACRJCL start proceduren/aAZAGNTBMVS jobname on SYSB

nodeagentAZAGNTBServer name on SYSBn/aAZAGNTAMVS jobname on SYSA

nodeagentAZAGNTAServer name on SYSALong NameShort Name




Application Servers on SYSA

n/aAZSR01WLM ApplEnvn/aAZACRJCL start proceduren/aAZSR01ASServant MVS jobnamen/aAZSR01AController MVS jobname

azsr01aAZSR01AServer nameLong NameShort Name

Additional servers would:Make use of the same JCL start procedureIncrement the 01 portion of the above example to 02

Note:

Application Servers on SYSB

n/aAZSR01WLM ApplEnvn/aAZACRJCL start proceduren/aAZSR01BSServant MVS jobnamen/aAZSR01BController MVS jobname

azsr01bAZSR01BServer nameLong NameShort Name

The last character of the name ("B" in the above example) is the system indicator.Recall that servers are always considered to be part of a cluster. (See "Applicationservers are considered to be a member of a cluster" on page 20.) If server AZSR01A iscreated on SYSA, it is assumed that eventually that server will be cloned over to SYSB toform a cluster. That cloned server on B would be AZSR01B. Both would share the sameWLM application environment name because they're both members of the same cluster.

Note:




Security Domain ConfigurationThe "Security Domain" option is new with W502000. Its role is two-fold: it provides a way toseparate out the common RACF profiles that apply across all nodes in the cell; and it provides away to differentiate one cell from another so the administrator role can be restricted, cell by cell.

It is the former capability -- providing consistency of common RACF variables across the differentnodes -- that will be illustrated in this paper. The ability to create actual "security domains" to restrict the administrator role to a single cell is beyond the scope of this document.

Note:

Configure and create Base Application Server

node on SYSB

Federate BaseApp node on SYSB into

Deployment Manager cell

Configure and create Base

Application Server node on SYSA

Configure and create Deployment Manager

cell on SYSA

Federate Base Application Server node

into Deployment Manager cell on SYSA

Configure and create Security

Domain

Creating the Security Domain

IDs and Groups created in Security Domain

Server

Node

Cell

Controller address space

Servant address spaces

UU U

G

U U

G

Daemon address space

G Configuration Group Servant Group

Unauthenticated Userid

Unauthenticated User Group

Daemon Userid

Controller Userid

Servant Userid

Administrator Userid

Resources highlighted in gray are the ones created by Security Domain

This is just the ID/Groups that are created. SSL resources are also created, but that's not shownhere.

Note:


Section: Security Domain ConfigurationVersion Date: Tuesday, March 09, 2004- 31 -© 2003, IBM Americas Advanced Technical Support


ISPF dialogs started

The ISPF dialogs were invoked by issuing the following command from the ISPF commandshell:

ISPF Command ShellISPF Command ===> Enter TSO or Workstation commands below: ===> ex 'WAS502.WAS.SBBOCLIB(BBOWSTRT)'

High-level qualifier for installation data sets

Invoking the ISPF customization dialogs for WebSphere for z/OS Version 5

If this is your very first time invoking the ISPF customization dialogs, you'll have to navigate pastthe license agreement panel.

Note:

Option to configure Security Domain selected

----------------- WebSphere for z/OS Customization ------------------Option ===> 1 Use this dialog to customize WebSphere for z/OS for the first time or to add Deployment Manager functionality to an existing base application server. Specify an option and press ENTER. 1 Configure security domain. If you want to configure a security domain, use this option. 2 Configure base Application Server node. If you want to configure a stand-alone base application server, use this option. You must option 1 before starting this option. 3 Configure integral JMS provider. If you want to configure for an Integral JMS Provider, use this option. You must complete option 2 before starting this option. 4 Configure Deployment Manager node. If you want to configure for a Deployment Manager, use this option. You must complete option 2 before starting this option. 5 Federate Base Application Server node. If you want to federate the base application server node, use this option. You must complete option 4 before starting this option. 6 Configure Web Services Gateway. If you want to configure for Web Services Gateway, use this option. You must complete option 2 before starting this option. 7 Configure v5.0.2 License Agreement Refresher. If you want to configure from previous service fix levels W501nnn to W502nnn, use this option.

Enter "1" to start the configuration of the Base Application Server node

ISPF main option panel

The panel flow under this options looks like this:




1. Configure Security Domain

2. Configure Base Application Server node

3. Configure integral JMS provider

4. Configure Deployment Manager node

5. Federate Base Application server node

6. Configure Web Services Gateway

1. Allocate target data sets

2. Define variables

3. Save Security Domain Variables

4. Generate customization jobs

5. View instructions

L. Load customization variables

Panel1 of 1

Panel1 of 1

Browse Member

Panel1 of 1

Start

Invoke ISPF

dialogs

Panel1 of 2

Panel2 of 2

Schematic flow of panels used to define the Security Domain

Allocate target data sets

Sub-option 1 was selected to allocate the target data sets. The target data sets are wherethe customized jobs and script go. The panel looked like this:

High Level Qualifier: WAS502.AZSECDM .CNTL .DATA The dialog will display data set allocation panels. You can make changes to the default allocations, however you should not change the DCB characteristics of the data sets. .CNTL - a PDS with fixed block 80-byte records to contain WebSphere customization jobs. .DATA - a PDS with variable length data to contain other data produced by the customization dialog.

High-level qualifier for the CNTL and DATA datasets that'll hold the

customized jobs for the Base Application Server node on SYSA

Naming the high-level qualifier for the data sets that hold the customized jobs

The default allocation paramters were taken.

Define variables

The next step was to select sub-option 2 to define the variables for the Security Domain.The first panel looked like this:




Security Domain Configuration (1 of 2) Specify the following to customize the security domain to be selected when configuring one or more WebSphere for z/OS servers or cells. Press Enter to continue. Use Security Domain Identifier in RACF Definitions: N Security Domain Identifier....................: Sysplex Name: WSCPLEX Generate default RACF realm name: Y Default RACF realm name ....: WSCPLEX WebSphere Configuration Group Information Group....: AZCFG GID..: 2500 WebSphere Administrator Information User ID..: AZADMIN UID..: 2403 Password.: AZADMIN Unauthenticated User Definitions for Base Servers User ID..: AZGUEST UID..: 2402 Group....: AZGSTGP GID..: 2502 WebSphere Asynchronous Administration Task User ID..: WSADMSH UID..: 2504

The AZCELL did not make use of a

"Security Domain"

Default UID/GID values shown

here. "AUTOUID" and

"AUTOGID" used to generate

actual values.

Panel 1 of 2 of the Security Domain configuration

See "How the RACF profiles are created" on page 9 for an explanation of how we used acustom set of RACF commands, where those came from, and how the AUTOUID andAUTOGID function was used.

The second panel looked like this:

Security Domain Configuration (2 of 2) Specify the following to customize the security domain to be selected when configuring one or more WebSphere for z/OS servers or cells. Press Enter to continue. WebSphere Common Groups and User IDs Servant group for base servers..: AZSRVRG Servant GID for base servers....: 2501 SSL Customization WebSphere Certificate Authority Keylabel: WebSphereCA Generate Certificate Authority (CA) certificate: Y Expiration date for CA Authority: 2010/12/31 Default RACF Keyring Name.........: AZCellKeyring Enable SSL on Location Service Daemon: N Additional z/OS Security Customization Options: Use SAF EJBROLE profiles to enforce J2EE roles: Y Enable Passtickets for z/SAS authentication: Y Passticket KEYMASK value................: 1234123412341234 Enable SAF authentication using LTPA or ICSF login tokens : Y Use APPL Profile to restrict access to WebSphere: Y

Panel 2 of 2 of the Security Domain configuration




Generate customized jobs

We were now ready to generate the customized jobs. The two "target data sets" weallocated earlier were used to hold the customized jobs and scripts. The panel we receivedgave us the opportunity to customize the JOB card used with each set of customized JCL:

Jobs and data files will get generated into data sets: 'WAS502.AZSECDM.CNTL' 'WAS502.AZSECDM.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=SYSADM1,PASSWORD=xxxxxxxx //* /*JOBPARM SYSAFF=SYSA

The JOB card that will be

placed at the top of each

customized job.

SYSADM1 is a userid with UID=0 authority, which is required for

many of the jobs to run properly

Our "target" data sets

Specifying the JOB card that will be used for each of the customized jobs

Coding the USER= and PASSWORD= of a UID=0 ID on the JOB card hereinsures each customized job's JOB card will have this information. Many ofthe jobs require a UID=0 authority to run.

Important Point!

When we pressed "Enter" the jobs were written out to the target data sets. It is possible togenerate customized jobs into data sets that already have members resident. The processwill simply delete and recreate any members it sees as already there.

Note:

Save Security Domain variables

This option saved all our customization variables into a sequential data set. Saving thevariables protected our investment in time. These variables are also a very important inputto the process of configuring the Deployment Manager on SYSA.

Select option "S" and you'll see this panel:

Data set name: 'WAS502.AZSECDM.SDCFG'

The Security Domain is a cell-wide definition. The middle qualifier did not contain a system specifier

such as the BaseApp SAVECFG files did.

Panel used to save customization variables to data set

The variables do not require a very large data set. The default allocation parameters seemto work well:




DATA SET NAME: 'WAS500.AZBASEA.SAVECFG' Volume serial ===> Space units ===> TRACKS Primary quantity ===> 2 Secondary quantity ===> 2 Directory blocks ===> 0 Record format ===> VB Record length ===> 255 Block size ===> 0 Releasing space ===> NO Expiration date ===>

Default values for allocation parameters work well

Allocation parameters for the SDCFG file used for the Security Domain

The Security Domain variables are a key input to the Base ApplicationServer node configuration, the Deployment Manager configuration and theFederation configuration. Do not bypass the saving of these variables.

Important Point!

View instructions

The member BBOSDINS was written out to the CNTL data set and contained the instructionson how to execute the jobs to create the Security Domain. Selecting option 5 allowed us toview those instructions.

Customized jobs run

The customized jobs are listed in the BBOSDINS member and were run in sequential order.

Uses the script created by BBOSBRAJ to create the RACF objects.BBOSBRAK

Creates a script full of RACF commands that will be invoked by the next job. Thisjob just creates the script. The next job actually drives RACF and creates theprofiles.

BBOSBRAJ

What it doesJob

This created the cell-wide RACF profiles.

Were these jobs customized to make them more "generic?" No. These values are cell-wideprofiles. Since one set of these is used for the whole cell -- regardless of how manyapplication servers we may create later -- we did not choose to customize these and makethem more generic.

???




Base Application Server node created on SYSAThe configuration is done through the ISPF customization dialogs, which capture key variables anduse those value to populate custom jobs. Those jobs, when run, create the configured WebSphereenvironment. The flow for creation of the AZCELL environment is:


node on SYSB






cell on SYSA




Domain

Creating the Base Application Server node on SYSA

This section will focus on the box that is highlighted in gray. The screen captures show the valuesentered into each panel of the ISPF customization dialog. Some of the panels have commentaryincluded to explain important points.

If you are already familiar with the ISPF panels, you may wish to merely skim through this section.Note:

ISPF Panels for the Base Application Server node on SYSA

To process for creating a Base Application Server node involves a running through a flow ofpanels like this:

1. System Locations

2. System Environment

3. Server Customization

4. Security Customization

Panel1 of 3

Panel2 of 3

Panel3 of 3

Panel1 of 4

Panel2 of 4

Panel3 of 4

Panel4 of 4

Panel1 of 2

Panel2 of 2

Panel1 of 1

1. Configure Security Domain

2. Configure Base Application Server node

3. Configure integral JMS provider

4. Configure Deployment Manager node

5. Federate Base Application server node

6. Configure Web Services Gateway

1. Load Security Domain Variables

2. Allocate target data sets

3. Define variables

4. Generate customization jobs

5. View instructions

S. Save customization variables

L. Load customization variables

Panel1 of 1

Panel1 of 1

Browse Member

Panel1 of 1

(See below)

Start

Invoke ISPF

dialogs

Schematic flow of ISPF panels to create Base Application Server node


Section: Base Application Server on SYSAVersion Date: Tuesday, March 09, 2004- 37 -© 2003, IBM Americas Advanced Technical Support


What results from this is a set of customized instructions and customized jobs that, when run,results in the creation of your base application server node:

Customized instructions and jobs

ISPF Panels


Run the customized jobs to create your Base Application Server node

We'll now walk through each of the panels and show you the exact values that were enteredinto each field.

ISPF dialogs started

If you exited the dialogs after configuring the Security Domain, re-enter them again:

ISPF Command ShellISPF Command ===> Enter TSO or Workstation commands below: ===> ex 'WAS502.WAS.SBBOCLIB(BBOWSTRT)'

High-level qualifier for installation data sets

Invoking the ISPF customization dialogs for WebSphere for z/OS Version 5




Option to configure a Base Application Server node selected

The first panel is a simple product information panel. Pressing enter took us to the followingwhere we started the process of configuring the Base Application Server node:



Main option panel of the ISPF customization dialogs

Base Application Server node main option panel

The main option panel of the Base Application Server node looked like this:

1 Load security domain variables. Load your Security Domain variables. 2 Allocate target data sets. The data sets will contain the WebSphere customization jobs and data generated by the dialog. 3 Define variables. Define your installation-specific information for WebSphere customization. 4 Generate customization jobs. Validate your customization variables and generate jobs and instructions. 5 View instructions. View the generated customization instructions. Options for WebSphere for z/OS Customization Variables S Save customization variables. Save your WebSphere customization variables in a data set for later use. L Load customization variables. Load your WebSphere customization variables from a data set.

Main option panel of the "Configure Base Application Server node" function




It's from here that you go into the various sub-options to configure the Base ApplicationServer node.

Security Domain variables loaded

They key first step is to load the SDCFG variables data set into the Base Application Servernode configuration. This is what brings the "WebSphere Configuration Group" and othercell-wide variables into the BaseApp's configuration. The variables were saved back under"Save Security Domain variables" on page 35.

Load Security Domain Variables Specify the name of a data set containing the security domain variables. IBM-supplied defaults are in 'WAS502.WAS.SBBOEXEC(BBOWSECV)' Press Enter to continue. Data set name: 'WAS502.AZSECDM.SDCFG' If this data set is not cataloged, specify the volume. Volume:

Variables data set saved earlier.

Security Domain variables loaded into BaseApp configuration

If you fail to load the Security Domain variables into the BaseAppconfiguration, the ID's you specify here will be connected to a defaultConfiguration Group. That might result in unpredictable operations. Donot overlook this step.

Important Point!

Whenever the Security Domain variables (SDCFG) are loaded into a BaseApp configurationalong with a SAVECFG set of variables, load the SDCFG last. By doing so, it insures yourmost recent key cell-wide security variables overwrite whatever legacy variables may bepresent in what may be a pre-W502000 SAVECFG file.

Note:

Target data sets allocated

The first step was to allocate the two data sets that'll hold the customized jobs and scriptsfor the Base Application Server node on SYSA. The panel looks like this:

High Level Qualifier: WAS502.AZBASEA .CNTL .DATA The dialog will display data set allocation panels. You can make changes to the default allocations, however you should not change the DCB characteristics of the data sets. .CNTL - a PDS with fixed block 80-byte records to contain WebSphere customization jobs. .DATA - a PDS with variable length data to contain other data produced by the customization dialog.

High-level qualifier for the CNTL and DATA datasets that'll hold the

customized jobs for the Base Application Server node on SYSA

Naming the high-level qualifier for the data sets that hold the customized jobs

The allocation parameters used were the defaults:




DATA SET NAME: 'WAS502.AZBASEA.CNTL' Volume serial ===> Space units ===> TRACKS Primary quantity ===> 15 Secondary quantity ===> 15 Directory blocks ===> 30 Record format ===> FB Record length ===> 80 Block size ===> 0 Releasing space ===> NO Expiration date ===>

DATA SET NAME: 'WAS502.AZBASEA.DATA' Volume serial ===> Space units ===> TRACKS Primary quantity ===> 5 Secondary quantity ===> 5 Directory blocks ===> 30 Record format ===> VB Record length ===> 255 Block size ===> 0 Releasing space ===> NO Expiration date ===>

Default allocation parameters are fine for these data sets

Allocation parameters for the CNTL and DATA data sets -- default values used

The 'Define Variables' option

With the target data sets allocated, we were now ready to go through and define thevariables for the configuration. First step: "System Locations."

System Locations - 1 of 2

Panel 1 of 2 under "System Locations" looks like this:

System name.: SYSA Sysplex name : WSCPLEX Full Names of Data Sets PROCLIB.: SYS1.PROCLIB PARMLIB.: SYS1.PARMLIB SYSEXEC.: SYSS.WSC.SYSEXEC In LNKLST or LPA (Y or N)? SCEERUN..: CEE.SCEERUN Y SBBOLOAD.: WAS502.WAS.SBBOLOAD N SBBOLD2..: WAS502.WAS.SBBOLD2 N SBBOMIG..: WAS502.WAS.SBBOMIG N SBBOLPA..: WAS502.WAS.SBBOLPA N SGSKLOAD.: SYS1.CRYPTO.SGSKLOAD N SBBOEXEC.....: WAS502.WAS.SBBOEXEC SBBOMSG......: WAS502.WAS.SBBOMSG

Modules not in LNKLST simply because the WSCPLEX environment has several different levels of WebSphere

installed at one time. Answering "N" here results in JCL having STEPLIB statements to load libraries.

Note specification of SYSA here

Values entered for "System Locations - 1 of 2" panel

We recommend you run the ISPF dialogs on the MVS image on which the server willoperate. That's the easiest way to make sure "System name" value is correct.

Note:





Locations of HFS Resident Components WebSphere SMP/E home directory.: /usr/lpp/zWebSphere/V5R0M2 WebSphere JMS Client Java Feature SMP/E home directory.: /usr/lpp/mqm/V5R3M1 java home directory.: /usr/lpp/java2/J1.3

See note regarding "SMP/E home directory"


Pointing directly at the actual mount point of the product HFS can limit a cell's abilityto accept maintenance updates in a non-disruptive fashion. The reasons for thisare outlined in the white paper WP100396, found at:

www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100396

To avoid introducing any confusion at this point, this document will illustrate thedefault practice of pointing at the mount point of the SBBOHFS data set.

Since this is the last panel of this series, completing this took us back to the mainoption panel for the "Base Application Server node" function. The next step was toconfigure the "System Environment."

Notes:

System Environment Customization - 1 of 3

WebSphere HFS Information Mount point....: /wasv5config/azcell Name...........: OMVS.WAS.AZCELL.CONFIG.HFS Volume, or '*' for SMS.: * Primary allocation in cylinders...: 250 Secondary allocation in cylinders.: 100

Recall that this is a shared HFS. The entire

configuration -- on SYSA and SYSB -- will be contained in here.

Values entered for "System Environment Customization - 1 of 3" panel

Using a shared HFS if not a requirement. It is something we chose to do for thisconfiguration. See "Minimize JCL start procedures" on starting on page 4 for anexplanation why we chose to use a shared HFS across SYSA and SYSB.

Note:





WebSphere Error Logstream Information Name.................: AZCELL.ERROR.LOG Data class ..........: STANDARD Storage class........: HLQ for data sets....: LOGGER Is logstream CF resident (Y|N) : Y If yes, specify structure name.: AZCELL_ERRORLOG If no, specify: logstream size.: 3000 staging size...: 3000 RRS Logstream Information Group name...........: WSCPLEX Data class...........: STANDARD Storage class........: HLQ for data sets....: LOGGER Is logstream CF resident (Y|N).: Y Create RRS PROC (Y|N).......: N



CTRACE Writer Definitions Procedure name.: AZCTRW User ID........: STCRACF Group..........: SYS1 Trace Data Set Information Name...................: SYS1.SYSA.AZCELL.CTRACE Volume, or "*" for SMS.: * Primary space in cylinders...: 10 Secondary space in cylinders.: 0 Trace Parmlib member suffix....: AZ


Again, since this is the last panel of this series, completing this took us back to the mainoption panel for the "Base Application Server node" function. The next step was toconfigure the "Server Customization."

Note:




Server Customization - 1 of 4

Application Server definitions WAS home directory.....: /wasv5config/azcell / AppServerNodeA Cell name (short)......: AZCELLA Cell name (long).......: azcella Node name (short)......: AZNODEA Node name (long).......: aznodea Server name (short)....: AZSR01A Server name (long).....: azsr01a Cluster transition name: AZSR01

Admin asynch operations procedure name: AZBPXSH

Directory under mount point modified from its

default value of /AppServer. See notes

below for explanation why.

Node and server long and short names as described earlier. "Cluster Transition Name" is

the WLM application environment name.

Value AZCELLA (appended with A) is a temporary name. It ceases to be used when this node is federated into the Deployment Manager cell, which will be called AZCELL.

Node name here must be unique from node name used for

Deployment Manager later.

Values entered for "Server Customization - 1 of 4" panel

The cell name for a Base Application Server node should beconsidered temporary. When the Base Application Server node isfederated into a Deployment Manager cell, the BaseApp Server node'scell name is no longer used. The Deployment Manager's cell name iswhat continues to be used.

Important Point!

Why was the directory changed from the default /AppServer to /AppServerNodeA?The target configuration consists of a node on SYSA and a node on SYSB. Recall thatone of the design decisions was to include everything in one HFS, and share that HFSbetween SYSA and SYSB.

The primary benefit of putting everything under one HFS is this: it allows a common set ofJCL to be used for all the servers.

???

The /AppServer directory and everything under it represents the node. If you wish tohave two or more nodes under the same HFS mount point, then you need to make thisdirectory unique for each. So for this node the directory was made unique byappending NodeA to /AppServer. And for the node on SYSB it was made/AppServerNodeB.





Application Server definitions Controller information Jobname........: AZSR01A Procedure name.: AZACR User ID........: AZACRU UID............: 2431 Servant information Jobname........: AZSR01AS Procedure name.: AZASR User ID........: AZASRU UID............: 2432

Jobname value as described

earlier.

Common proc for all

controllers other than Daemon

Common Userid for all controllers

Default UID. AUTOUID

function to be used later.

Servant information similar to controller's


See "How the RACF profiles are created" on page 9 for an explanation of how we useda custom set of RACF commands, where those came from, and how the AUTOUID andAUTOGID function was used.


Application Server definitions Node host name...........: wsc1.washington.ibm.com SOAP JMX Connector port...................: 9540 DRS Client Address port...................: 9541 ORB Listener host name...: * ORB port..................................: 9542 ORB SSL port..............................: 9543 HTTP transport host name.: * HTTP port.................................: 9548 HTTP SSL port.............................: 9549

IP address of SYSA

See below for pointer to TCP port allocation method


For an explanation of how the TCP ports were allocated, see "How the fenced-off portswere allocated to the various servers" on page 16.





Location Service Daemon definitions Daemon Home Directory: /wasv5config/azcell/Daemon Daemon Job Name: AZDEMN1 Procedure Name.: AZDMN User ID........: AZACRU UID............: 2411 IP Name........: wsc1.washington.ibm.com Port...........: 9506 SSL Port.......: 9507 Register Daemon with WLM DNS: N

Default value

See Note 1 below

See Note 2 below

See Note 3 below


Notes:

The IP name is that of the SYSA MVS system in WSCPLEX. The ports for the Daemon aretemporary: see the next section.

3

Most of the controllers in WebSphere for z/OS Version 5 use the same program, BBOCTL. Butthe Daemon uses BBODAEMN. So a separate JCL procedure is needed for the Daemon server.The RACF userid is the same one as used by all the other controllers, however. This is inkeeping with the design objective of minimizing the number of userids employed. The UIDvalue here is the default, but was not used. The AUTOUID function was used instead. See"How the RACF profiles are created" on page 9 for an explanation of how this was done.

2

The system indicator here is slightly different from that used elsewhere. Here the number 1was used where the letter A was used elsewhere. It makes little difference: this Daemon willexist only until the node is federated. See "Temporary nature of Base Application Server nodeDaemons" on page 46.

1

Temporary nature of Base Application Server node Daemons

This Daemon was considered temporary: after this node was federated into theDeployment Manager cell (see "Federated Base Application Server node on SYSAinto the DM cell" starting on page 61), this Daemon ceased to be used. Once thisnode was federated, it started to use the services of the Deployment Manager'sDaemon.

The Daemon may still continue to run unless you manually stop it before or afterfederation. The BBOWADDN job that performs the federation will attempt to stop theapplication server if its running, but will not try to stop the Daemon. Therefore, it'srecommended you stop the Base Application Server node's Daemon prior tofederating the node.

Note:

The Daemon job name value and the ports assigned on this panel are only used solong as the Base Application Server node remains un-federated. Once it'sfederated, these values cease to be used in the configuration.

The ports are what's important to focus on: these two port values are the "interimports" illustrated on the chart back in "How the fenced-off ports were allocated to thevarious servers" on page 16. These two ports were used as the "interim ports" forthe Base Application Server node on SYSA, and then again for the Base ApplicationServer node on SYSB. Knowing that they were temporary port allocations, we coulddo that.




View Security Domain configuration panels

This option provides you the opportunity to browse -- but not edit -- the Security Domainvariables created back under "Security Domain Configuration" on page 31.

It was now time to save our variables and then generate the customized jobs. Weneeded to return to the Base Application Server node configuration main option panel(one back from "Define Variables").

Note:

Customization variables saved

This option saved all our customization variables into a sequential data set. Saving thevariables protected our investment in time. These variables are also a very important inputto the process of configuring the Deployment Manager on SYSA.

Select option "S" and you'll see this panel:

Data set name: 'WAS502.AZBASEA.SAVECFG'

Middle qualifier identifies this SAVECFG file as belonging to the Base Application Server node on SYSA

Panel used to save customization variables to data set

The variables do not require a very large data set. The default allocation parameters seemto work well:

DATA SET NAME: 'WAS502.AZBASEA.SAVECFG' Volume serial ===> Space units ===> TRACKS Primary quantity ===> 2 Secondary quantity ===> 2 Directory blocks ===> 0 Record format ===> VB Record length ===> 255 Block size ===> 0 Releasing space ===> NO Expiration date ===>

Default values for allocation parameters work well

Allocation parameters for the SAVECFG file used for the Base Application Server node on SYSA

Customized jobs generated

We were now ready to generate the customized jobs. The two "target data sets" weallocated earlier were used to hold the customized jobs and scripts. The panel we receivedgave us the opportunity to customize the JOB card used with each set of customized JCL:




Jobs and data files will get generated into data sets: 'WAS502.AZBASEA.CNTL' 'WAS502.AZBASEA.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=SYSADM1,PASSWORD=xxxxxxxx //* /*JOBPARM SYSAFF=SYSA



customized job.



Our "target" data sets

Specifying the JOB card that will be used for each of the customized jobs


Important Point!

When we pressed "Enter" the jobs were written out to the target data sets. It is possible togenerate customized jobs into data sets that already have members resident. The processwill simply delete and recreate any members it sees as already there.

Note:

View instructions

After we generated the customized jobs, a member called BBOSSINS is created thatcontains text instructions on the steps you take to create your Base Application Servernode. The instructions are divided into two main sections:

Updates you manually make to your environment

Customized jobs you run

The entire BBOSSINS member is provided under "Appendix A - BBOSSINS for BaseApplication Server node on SYSA" on page 96.

You should print your copy of this member for handy reference.

Manual updates made

These are required before running any of the customized jobs.

Updates as specified in BBOSSINS member

We reviewed the top section of the BBOSSINS member and performed the updates asspecified. This white paper will not attempt to explain the various updates, most of whichare fairly common and well-understood MVS system programmer activities.

For a printout of those instructions, see "Appendix A - BBOSSINS for Base ApplicationServer node on SYSA" on page 96.

Note:




A note about WLM Application Environments

The instructions in BBOSSINS called for us to create a WLM Application Environment forour application server, unless you have APAR OW54622 applied. OW54622 provides the"Dynamic Application Environment" (DAE) support. With dynamic WLM applicationenvironment support there's no need to hand-code the definitions.

However, if you don't yet have OW54622 in place, you'll need to hand-code anapplication environment definition. Instructions are provided under the first step of themanual update section of BBOSSINS.

However, without WLM Dynamic Application Environments this AZCELL configurationwouldn't be possible. Horizontal clusters require DAE.

Note:

Customized jobs run

The customized jobs are listed in the BBOSSINS member and were run in sequential order.

The jobs must be run in sequential order. Do not start the next job until you have verified theprevious job has run successfully. Not all jobs are required. Read the instructions in theBBOSSINS member carefully (see "Appendix A - BBOSSINS for Base Application Server nodeon SYSA" on page 96). See the following checklist for a quick summary of each job's function.

Note:

Creates the was.env from the information stored in many different places throughoutthe Base Application Server node HFS.

BBOWC2N

Copies a bunch of shell scripts, XML files and trace data into the WebSphere HFSdirectory structure.

BBOWCPY2

Copies tailored members to PROCLIB, PARMLIB and SYSEXEC. Take a look at thejob itself to see what members are copied.

BBOWCPY1

Configures a directory for UDDI registry. This configuration doesn't use UDDI, butrunning this causes no harm and prevents one of the later jobs from getting a RC 4.

BBOMCFGU

Creates the directory structure inside the HFS just created.BBOMCFG

Allocates the HFS file system data set and mounts it at the mount point you specified.BBOWCHFS

Uses the script created by BBOCBRAJ to create the RACF objects needed to run yourserver.

Note: we did not run this job. We used our own modified RACF script. See "How theRACF profiles are created" on page 9.

Note 2: if you're not very familiar with the RACF relationships, it's probably better tosimply go ahead and run the BBOCBRAK job.

BBOCBRAK

Creates a script full of RACF commands that will be invoked by the next job. This jobjust creates the script. The next job actually drives RACF and creates the IDs, groups,etc.

BBOCBRAJ

Allocates the CTRACE data set used by BBOWTR.BBOWCTR

Defines the RRS log streams.BBORRSLS

Defines the error log stream. This configuration uses a common error log stream for allthe servers. We ran this job for the first Base Application Server node and re-used thesame error log stream for other servers.

BBOERRLG

Sets up message translation. We did not run this job.BBOMSGC

What it doesJob




Finalizes the HFS. This is a very important step; do not overlook it.BBOMCFG2

Batch-installs the administrative application into your server. Note: this job takes a longtime to execute. Be patient.

BBOWIAPP

What it doesJob

Base Application Server node started on SYSA

The command to start the Base Application Server node on SYSA was also provided in theBBOSSINS instruction member. The command was:

S AZACR,JOBNAME=AZSR01A,ENV=AZCELLA.AZNODEA.AZSR01A

Common controller procedure

JOBNAME is equal to server

short name

Cell short

Node short

Server short

This starts controllerController automatically starts Daemon and waits for it to initializeController completes its initializationWLM starts servant

Sequence of events:

Start command for the Base Application Server node

Starting the server at this point in time servers two purposes: one, it validates things; and two, itresults in the the running of the applyPTF step in the JCL. That's a prerequisite to federatingthe node later.

What's the applyPTF step all about? See "The applyPTF.sh process" on page 120 for anexplanation.

Note:

Base Application Server validated

We feel that driving the administrative application (installed into the Base Application Serverwith the BBOWIAPP job) is a pretty good initial test.http://wsc1.washington.ibm.com:9548/admin/

The TCP port 9548 is the "HTTP Port" defined on "Server Customization, Panel 3 of 4" in theISPF dialogs. That's the port on which the Base Application Server is listening for non-SSL HTTP.The context root for the administrative application is /admin/.

???

If you get the logon panel and can get to the primary panel of the administrative application, youcan be fairly certain the server is up and running properly.




Status of progress towards target configuration

Target Configuration

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL

The target configuration

Configuration at this point

Only the Base Application Server node on SYSA was completed so far:

SYSA

AZSR01A

CR SR

AZDEMN1

CR

SYSB

Cell: AZCELLA

Temporary names

Progress towards target configuration

When this Base Application Server node was federated into the Deployment Manager cell,the cell name of the Deployment Manager remained but the Base Application Server node'scell was no longer used. The same thing with the Daemon: the Deployment Manager'sDaemon server became the one that was used, and the Base Application Server node'sDaemon was "set aside" and no longer used. Hence, the "temporary" nature of those twothings.

Note:




Deployment Manager created on SYSAThe process is remarkably similar to that of creating the original Base Application Server node.The flow of the panels for the Deployment Manager (acronym: "DM") is very close -- though notexactly the same -- as the Base Application Server node. In sequence of tasks to create the targetconfiguration, this is where this section will focus:


node on SYSB






cell on SYSA




Domain

Creating the Deployment Manager

ISPF panels for Deployment Manager configuration

ISPF dialogs invoked

If the ISPF customization dialog is not started, invoke it in the same way as was done forthe Base Application Server node.

Deployment Manager option selected



Main option panel of the ISPF customization dialogs


Section: Deployment Manager on SYSAVersion Date: Tuesday, March 09, 2004- 52 -© 2003, IBM Americas Advanced Technical Support


SAVECFG from Base Application Server node configuration loaded

This is done to provide to help provide some consistency between the original BaseApplication Server node and the Deployment Manager node being built. It's not striclyrequired, but we've found it to help.

But loading the Security Domain variables is required, as you'll see next.Note:

----------------- WebSphere for z/OS Customization -----------Option ===> Load Customization Variables Specify the name of a data set containing the customization variables. IBM-supplied defaults are in 'WAS500.WAS.SBBOEXEC(BBOWVARS)' Press Enter to continue. Data set name: 'WAS502.AZBASEA.SAVECFG' SAVECFG file from Base

Application Server node

Configure Deployment Manager node Use this dialog to define WebSphere for z/OS variables and generate customization jobs for your installation. Specify an option and press ENTER. HLQ for WebSphere product data sets: WAS502.WAS 1 Load security domain variables. Load your Security Domain variables.

5 View instructions. View the generated customization instructions. Options for WebSphere for z/OS Customization Variables S Save customization variables. Save your WebSphere customization variables in a data set for later use. L Load customization variables. Load your WebSphere customization variables from a data set.

Lines removed from the screen capture to save space in the document

Loading SAVECFG from Base Application Server node into Deployment Manager configuration

Security Domain variables loaded

Option 1 was selected to bring up the panel that allowed us to load the Security Domainvariables into the Deployment Manager configuration:

Load Security Domain Variables Specify the name of a data set containing the security domain variables. IBM-supplied defaults are in 'WAS502.WAS.SBBOEXEC(BBOWSECV)' Press Enter to continue. Data set name: 'WAS502.AZSECDM.SDCFG' If this data set is not cataloged, specify the volume. Volume:

Saved variables data set from Security Domain

configuration

Loading Security Domain variables




This is a critical step: loading the SDCFG file from Security Domain into theDeployment Manager configuration provides the critical connection to thecommon Configuratoin Group used by this Deployment Manager and theother Base Application Servers.

Important Point!


Just as was done for the Base Application Server node, a set of target data sets wasrequired to hold the customized jobs used to create the Deployment Manager.

It is possible to name the same target data sets as used for the Base Application Servernode, but it's not recommended. The job names are very close to one another, and it'sdifficult to keep separate the two sets of jobs -- the Base Application Server node and theDeployment Manager node. It's far better to create a new set of target data sets and keepthe two sets of jobs separate from one another.

Note:

High Level Qualifier: WAS502.AZDMGR .CNTL .DATA The dialog will display data set allocation panels. You can make changes to the default allocations, however you should not change the DCB characteristics of the data sets. .CNTL - a PDS with fixed block 80-byte records to contain WebSphere customization jobs. .DATA - a PDS with variable length data to contain other data produced by the customization dialog.

A different set of target data sets from Base

Application Server node

Allocating target data sets for Deployment Manager's customized jobs


Because the SAVECFG variables from the Base Application Server node were loaded intothis Deployment Manager configuration, the Base Application Server node values appearedon the ISPF panels. We had to be careful to make sure we change the proper variables tocustomize the Deployment Manager, but left other variables in place to insure consistency.


Was the same as used for the Base Application Server node. No changes wereneeded:

System name.: SYSA Sysplex name : WSCPLEX Full Names of Data Sets PROCLIB.: SYS1.PROCLIB PARMLIB.: SYS1.PARMLIB SYSEXEC.: SYSS.WSC.SYSEXEC In LNKLST or LPA (Y or N)? SCEERUN..: CEE.SCEERUN Y SBBOLOAD.: WAS502.WAS.SBBOLOAD N SBBOLD2..: WAS502.WAS.SBBOLD2 N SBBOMIG..: WAS502.WAS.SBBOMIG N SBBOLPA..: WAS502.WAS.SBBOLPA N SGSKLOAD.: SYS1.CRYPTO.SGSKLOAD N SBBOEXEC.....: WAS502.WAS.SBBOEXEC SBBOMSG......: WAS502.WAS.SBBOMSG





We recommend you run the ISPF dialogs on the MVS image on which the server willoperate. That's the easiest way to make sure "System name" value is correct.

Note:


Was exactly the same as the Base Application Server node. No changes needed.

As stated earlier, pointing to the actual mount point of the "SMP/E home directory" hasthe potential to limit a cell's ability to accept new maintenance non-disruptively. For thesake of simplicity we're showing the default behavior of pointing directly at the/usr/lpp/zWebSphere/V5R0M2 directory. Please review the white paper WP100396,found at www.ibm.com/support/techdocs for more details on this issue.

Note:


Unlike for the Base Application Server node configuration, which had four panels underthis option, the Deployment Manager has only one panel:


A single HFS is shared across this entire

configuration. Therefore, the mount point and HFS file system name used for

the Base Application Server node is named

again here.


If in your configuration you wish to have your Deployment Manager in a separate HFS,simply name a different mount point and HFS file system name here.

Note:


Because we loaded the Base Application Server node's SAVECFG file into theDeployment Manager's configuration, the values for things like cell, node and servername provided earlier appeared here. We overrode the initial values with the values forthe Deployment Manager, as discussed in "The naming convention used" on page 24.

Deployment Manager definitions WAS home directory.....: /wasv5config/azcell / DeploymentManager Cell name (short)......: AZCELL Cell name (long).......: azcell Node name (short)......: AZDM Node name (long).......: azdmnode Server name (short)....: AZDMGR Server name (long).....: dmgr Cluster transition name: AZDMGR

The default directory of /DeploymentManager is supplied by ISPF dialogs.

That default is used.

The Base Application Server node's values will be initially loaded here.

Override those values with your Deployment

Manager's values. See notes below.

1

2

Deployment Manager's Server Customization - 1 of 4




Notes:

The node name used by our Deployment Manager had to be different from the node nameused for our Base Application Server node. When we federated our Base Application Servernode into our Deployment Manager cell, the two nodes -- Deployment Manager node andBase Application Server node -- had to have different names.

2

The value for "Cell" used for the Base Application Server node was a temporary value. TheBase Application Server node's cell goes away when the node is federated into theDeployment Manager's cell. So cell name we supplied for your Deployment Manager is thecell name that was used in our ultimate configuration.

1


Deployment Manager definitions Controller information Jobname........: AZDMGR Procedure name.: AZACR User ID........: AZACRU UID............: 2421 Servant information Jobname........: AZDMGRS Procedure name.: AZASR User ID........: AZASRU UID............: 2422

Recall objective of using common set of JCL and minimize RACF identities. We'll use the same procs and IDs for the Deployment Manager as used for

the Base Application Server node.

New values for Deployment

Manager

Server Customization panel 2 of 4 for Deployment Manager

The RACF profiles created during the construction of the Base Application Server node(see "How the RACF profiles are created" on page 9) will work for the DeploymentManager as well. The STARTED profiles were generic enough to cover any MVSjobname starting with AZ*. And the same user ID values were used throughout (see"Minimize RACF userids and groups" on page 7).

Note:


Deployment manager definitions Node host name...........: wsc1.washington.ibm.com SOAP JMX Connector port...................: 9510 CELL DISCOVERY ADDRESS port...............: 9514 DRS CLIENT ADDRESS port...................: 9511 ORB Listener host name...: * ORB port..................................: 9512 ORB SSL port..............................: 9513 HTTP transport host name.: * HTTP port.................................: 9518 HTTP SSL port.............................: 9519

See Note 1 below

Different port values for the Deployment

Manager. See Note 2 below.

Server Customization panel 3 of 4 for the Deployment Manager




Notes:

The TCP ports for the Deployment Manager are different from the ports used by the BaseApplication Server node. Recall that for this configuration we have fenced off a small range ofTCP ports, and we allocated those ports manually. See "How the fenced-off ports wereallocated to the various servers" on page 16 to understand how the ports were allocated.

2

In this configuration the first Base Application Server node is on SYSA, and the DeploymentManager is also on SYSA. While it's possible to have multiple IP stacks on a given MVSimage and have the Deployment Manager and Base Application Server tied to separate hostnames, for this configuration they're associated with the same node host name.

1


Some interesting things here:

Location Service Daemon definitions Daemon Home Directory: /wasv5config/azcell/Daemon Daemon Job Name: AZDEMN Procedure Name.: AZDMN User ID........: AZACRU UID............: 2411 IP Name........: wsccb.washington.ibm.com Port...........: 9500 SSL Port.......: 9501 Register Daemon with WLM DNS: N

See Note 1

Same values used here as with the Base Application Server node.

See Note 2

Notes:

Back in "Utilize Sysplex Distributor" on page 18, it was shown how Sysplex Distributor is beingused to flow requests to the Daemons in the configuration. To accomplish this, a "DistributeVirtual IP address" (DVIPA) is used -- a cluster address -- which Sysplex Distributor then takesand flows to multiple common services. In this configuration, the two Daemons planned forthe final configuration (Daemon in SYSA and Daemon and SYSB) will both listen on the sameport values. This Daemon was configured to be associated withwsccb.washington.ibm.com, which is the DVIPA.

2

The Daemon job name provided for the Base Application Server node was AZDEMN1. Thatname was temporary: when the Base Application Server node was federated into theDeployment Manager cell, the original Base Application Server Daemon was no longer used.So the job name for this Daemon was the one that lived on in the final configuration. This isalso the name that will be used for all post-federation Daemons on other MVS images.Therefore, this name has no system indicator; it is generic. When the Deployment Manager'scontroller was started, its Daemon was started automatically using this job name value.

1



Configuration variables saved

The variables generated for the Deployment Manager node were saved to a differentSAVECFG dataset:




Data set name: 'WAS502.AZDMGR.SAVECFG' A different SAVECFG file from that used for the Base Application Server node

Note!

Note!A different SAVECFG file is used for the Deployment Manager configuration

It is possible to save the variables from the Base Application Server node in the sameSAVECFG file with the Deployment Manager node. The SAVECFG files are not very large andhaving separate files keeps things more organized and easier to understand.

Note:


The process was very similar to that done for the Base Application Server node:

Jobs and data files will get generated into data sets: 'WAS502.AZDMGR.CNTL' 'WAS502.AZDMGR.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=SYSADM1,PASSWORD=xxxxxxxx //* /*JOBPARM SYSAFF=SYSA



customized job.



Your "target" data sets for the Deployment Manager

Generating the customized jobs for the Deployment Manager


Important Point!

Customized jobs run

The jobs must be run in sequential order. Do not start the next job until you have verified theprevious job has run successfully. Not all jobs are required. Read the instructions in theBBOCCINS member carefully (see "Appendix C - BBOCCINS for Deployment Manager on SYSA"on page 109). See the following checklist for a quick summary of each job's function.

Note:

Creates a script full of RACF commands that will be invoked by the next job. This jobjust creates the script. The next job actually drives RACF and creates the IDs, groups,etc.

BBODBRAJ

What it doesJob




Finalizes the HFS. This is a very important step; do not overlook it.BBODCFG2

Copies digital certificates from RACF to the keystore in the HFS. The configuration inthis white paper is not using security features (to keep things simple), so this step wasnot run.

BBOCR2FD

Batch-installs the administrative application into your server. Note: this job takes a longtime to execute. Be patient.

BBODIAPP

Creates the was.env from the information stored in many different places throughoutthe Base Application Server node HFS.

BBODC2N

Copies a bunch of shell scripts, XML files and trace data into the WebSphere HFSdirectory structure.

BBODCPY2

Copies tailored members to PROCLIB, PARMLIB and SYSEXEC. Take a look at thejob itself to see what members are copied.

Note: Since we're using a common set of JCL produces, we did not need to run this job.

BBODCPY1

Configures a directory for UDDI registry. This configuration doesn't use UDDI, butrunning this causes no harm and prevents one of the later jobs from getting a RC 4.

BBOMCFGU

Creates the /DeploymentManager directory structure inside the HFS.BBODCFG

Allocates the HFS file system data set and mounts it at the mount point you specified.

Note: Since the AZCELL configuration is sharing a common HFS, we did not need to runthis for the Deployment Manager. The HFS was created and allocated when the BaseApplication Server was created:

BBOWCHFS

Uses the script created by BBODBRAJ to create the RACF objects needed to run yourserver.

Note: For this configuration we used a custom set of RACF commands that was runonce and applied to the whole configuration. See "How the RACF profiles are created"on page 9. However, if you're not using a special RACF-generation script, then run thisjob to generate the IDs for the Deployment Manager.

BBODBRAK

What it doesJob

Deployment Manager started and validated

S AZACR,JOBNAME=AZDMGR,ENV=AZCELL.AZDM.AZDMGR



short name

Cell short

Node short

Server short


Sequence of events:

Start command for the Deployment Manager node

Again, driving the administrative application is a good test:http://wsc1.washington.ibm.com:9518/admin/

Make certain you don't point your browser at the HTTP port of your Base Application Server.The TCP port 9518 is the HTTP port of the Deployment Manager.

Note:






SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL



We had two competely separate cells. Federating the Base Application Server node intothe Deployment Manager cell was the next step.

SYSA

AZDMGR

CR SR

AZDEMN

CR

SYSB

Cell: AZCELL

AZSR01A

CR SR

AZDEMN1

CRCell: AZCELLA

Two completely separate cells at this

point in time

Nothing yet in SYSB





Federated Base Application Server node on SYSA into the DM cellThis is where this section of the document will focus:


node on SYSB






cell on SYSA




Domain

Federating the SYSA Base Application Server node into the Deployment Manager's cell

What federation does

Federation is the act of taking the node structure of a Base Application Server node andmerging it into the cell structure of a Deployment Manager cell:

Deployment Manager

CR SR

Daemon

CR

Cell "ABC"

Base

CR SR

Daemon

CR

Cell "XYZ"

Deployment Manager

CR SR

Daemon

CR

Cell "ABC"

Base

CR SR

Daemon

CR

Cell "XYZ"Base Application Server's cell structure is "set aside" -- no longer used, but not discarded -- when node is federated into Deployment Manager cell. Cell name is used only before federation, but not after.

Deployment Manager's cell name is the one that "lives on" after federation

Federation involves extracting node from original Base Application Server and merging it into DM cell

This act of federation may be done within a given MVS image, or across MVS images within thesame Sysplex. The key thing is this: the original Base Application Server node's cell structurebecomes unused once federation completes. It's not discarded: it's maintained in the HFS justin case you want to un-federate the node later. The active cell structure is the DeploymentManager's cell. Further, the Deamon server used by the original Base Application Server nodebecomes unused as well.


Section: Federation of BaseApp on SYSAVersion Date: Tuesday, March 09, 2004- 61 -© 2003, IBM Americas Advanced Technical Support


Base Application Server node's HFS content not moved ... just changed

When federation occurs, the contents of the Base Application Server node's HFS ismodified to reflect the new cell in which it resides. This means the symbolic links usedduring server startup are modified, and it means some of the XML files are updated toreflect the new cell name.

The original Base Application Server node's HFS and its mount point remain, and allthe contents of the HFS remain. The contents are not moved over to the DeploymentManager's HFS*. The Base Application Server node's HFS is merely modified insuch a way that WebSphere now recognizes the node as residing in the DM's cell andnot in the old Base Application Server node cell.

(*Well, a copy of the information is placed in the Deployment Manager's HFSstructure. But the key point remains: the Base Application Server node's HFS is notmoved.)

Key Point:

Overview of federation process

The act of federating a node into a Deployment Cell involves using an option in the ISPFdialogs to customize a job that performs the federation. Pictorially, the process looks like this:

ISPF Dialogs

SDCFG

Saved configuration variables (SAVECFG file and SDCFG file--

see notes)

CNTLDATA

JCL BBOWADDN

Specify Values

2

3

4

51

SAVECFG

Flow of the process used to federate a node

1. Load the SAVECFG file from the Deployment Manager into the ISPF dialogs.

Prior to W502000 the rule was to load the BaseApp's SAVECFG. That changed withW502000. Loading this SAVECFG file from the Deployment Manager provides all theimportant information about how to connect to the DMGR to initiate the federation.

Note:

2. Load the SDCFG file from the Security Domain configuration

This is new with W502000. This is what provides the WebSphere Administrator IDinformation.

Note:

3. You specify information about the node being federated, and what you want the createdNode Agent to be called and what ports to use.

4. Output is fed to target data sets. (DATA data set will be empty; CNTL will have threemembers: BBOANINS -- instruction member; BBOTCPIA -- port reservation text for TCPprofile; and BBOWADDN -- customized JCL that runs BPXBATCH which runs addNode.shshell script).

5. The JCL BBOWADDN is submitted, which federates the node.




ISPF Panels for federating the Base Application Server node on SYSA

We suggest you run the ISPF dialogs on the MVS system where the Base Application Servernode being federated resides.

Note:

Option 5 - Federate Base Application Server node

The sub-options under this main option look like this:

Federate Base Application Server Node Use this dialog to define WebSphere for z/OS variables and generate customization jobs for your installation. Specify an option and press ENTER. HLQ for WebSphere product data sets: WAS502.WAS 1 Load security domain variables. Load your Security Domain variables. 2 Allocate target data sets. The data sets will contain the WebSphere customization jobs and data generated by the dialog. 3 Define variables. Define your installation-specific information for WebSphere customization. 4 Generate customization jobs. Validate your customization variables and generate jobs and instructions. 5 View instructions. View the generated customization instructions. Options for WebSphere for z/OS Customization Variables S Save customization variables. Save your WebSphere customization variables in a data set for later use. L Load customization variables. Load your WebSphere customization variables from a data set.

Option to customize the federation batch job

Load customization variables

There are two customization variable data sets to load: the Deployment Manager'sSAVECFG file, and the Security Domain SDCFG file.

Deployment Manager's SAVECFG file loaded

Option L was selected to load the SAVECFG from the Deployment Manager. Thisprovides the federation customization process what it needs to connect to theDeployment Manager to initiate the federation.

Data set name: 'WAS502.AZDMGR.SAVECFG'Deployment Manager's SAVECFG

Loading SAVECFG from Deployment Manager into the federation customization dialog

Prior to W502000: load the Base Application Server node's SAVECFG andmanually insure proper Deployment Manager information.

W502000 or after: load the Deployment Manager's SAVECFG and manuallyinsure the proper "WAS Home Directory" of the node being federated.

Note:




Security Domain SDCFG file loaded

Option 1 was then selected to load the Security Domain variables into the federationcustomzation dialogs:

Data set name: 'WAS502.AZSECDM.SDCFG'Deployment Manager's SAVECFG

Loading SDCFG from Security Domain configuration

This provides information about the WebSphere Administrator ID.Note:


These data sets are used to hold the customized jobs. They are identical in format tothe ones used to hold the customized jobs for the Base Application Server node and theDeployment Manager. As a general practice, we recommend the use of separate targetdata sets for all steps in the configuration:

High Level Qualifier: WAS502.AZFEDA .CNTL .DATA

HLQ Indicates this is federation job for

node on SYSA

Allocating a separate set of target data sets for customized federation jobs

Define variables

A single panel is used to define the variables needed to federate the Base ApplicationServer node on SYSA into the Deployment Manager cell, also on SYSA:




Define variables for Federate Base Application Server node (1 of 1) Specify the following to customize your WebSphere for z/OS server. Press Enter to continue. WAS home directory.....: /wasv5config/azcell / AppServerNodeA Deployment Manager access: Node host name........: wsc1.washington.ibm.com JMX Soap port.........: 9510 Deployment Manager Security is Enabled: N Userid.............: AZADMIN Include Apps..........: Y Base server ORB port..: 9542 Node Agent definitions: Server name (short)...: AZAGNTA Server name (long)....: nodeagent SOAP JMX Connector port........: 9520 DRS Client Address port........: 9521 Node Discovery port............: 9524 Node Multicast Discovery port..: 9525 ORB Listener host name...: * ORB port.......................: 9522 ORB SSL port...................: 9523

1

2

3

4

6

7

5

Defining the customization variables for the federation of the node

A quick way to tell if you're really at W502000 is to see if the "WAS home directory" fieldis open to modification. Prior to W502000 it was not.

Note:

Just in case the Base Application Server is up when the federation process is started, theBase server's ORB port is provided so the server can be brought down. See "How thefenced-off ports were allocated to the various servers" on page 16 for a discussion of TCPports.

5

A "Y" here means any applications installed in the Base Application Server will be kept in theserver as it is federated into the DM's cell. Specifying "N" has the opposite effect: theapplications are removed prior to the node being federated.

4

The BBOWADDN customized job must run under the identity of the "WebSphere Administrator."The value found on this panel comes from the Security Domain's SDCFG file loaded earlier.Supplying the userid and password here does not result in the JOB card of the customized jobbeing updated with this information. This merely adds the information to the BBOANINSinstruction member. You must add that manually. See "Generate customized jobs" on page66.

3

The values for the "Deployment Manager Access" fields will come from the SAVECFG of theDeployment Manager, which starting with W502000 is what is loaded for federation.

2

The "WAS home directory" is what tells the federation process which Base Application Servernode is being federated. The addNode.sh shell script will be run from the /bin directory ofwhatever value is found in this field. Pay close attention to whether the initial value found inthis field is correct for the node being federated. Change if necessary. (The value found inthis field initially comes from the SAVECFG of the DMGR, and that will have the correct valueonly if the SAVECFG of the BaseApp was loaded into the DMGR's customization.)

1




All the ports that will be used by the newly-created Node Agent. See "How the fenced-off portswere allocated to the various servers" on page 16 for more information on TCP ports.

7

This is what the Node Agent's short name will be. See "The naming convention used" onpage 24 for a discussion of the naming convention we used. The long name is a fixed valueof nodeagent.

6

Save customization variables

The variables for this federation operation were saved into a separate SAVECFG data setcalled WAS502.AZFEDA.SAVECFG:

Save Customization Variables Specify the name of a sequential data set to contain the customization variables. If the data set does not exist, the dialog displays the Allocate New Data Set panel, through which you can allocate a data set. Press Enter to continue. Data set name: 'WAS502.AZFEDA.SAVECFG'

Variables for federation of node on SYSA saved into separate SAVECFG data set

Generate customized jobs

The customized jobs were generated into the target data sets defined earlier. We madecertain the JOB card was updated with the userid and password of the WebSphereAdministrator ID:

Jobs and data files will get generated into data sets: 'WAS502.AZFEDA.CNTL' 'WAS502.AZFEDA.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=AZADMIN,PASSWORD=AZADMIN //* /*JOBPARM SYSAFF=SYSA

Only CNTL was actually used. DATA

was empty.

Add the USER= and PASSWORD= to the JOB card so the job runs under the authority of the

WebSphere Administrator ID

Federation jobs generated into target data sets; WebSphere Admin ID set on job card

The USER setting on the JOB card must be set so the job runs underthe authority of the WebSphere administrator. The value for theWebSphere Administrator was set way back during the definition of theSecurity Domain. (Or a UID=0 ID may be used)

You must manually code the value and password on the JOB cardprovided on this panel .

Important Point!




Three members were written to the CNTL data set:

BROWSE WAS502.AZFEDA.CNTL Command ===> Name _________ BBOANINS _________ BBOTCPIA _________ BBOWADDN

Instruction member

TCP port reservation text for cut/paste into

TCP profileCustomized job that

was submitted to federate the node

Three customized members written into the CNTL target data set for federation of node on SYSA

BBOANINS instructions

The target data set WAS502.AZFEDA.CNTL contained a member called BBOANINS, which isthe instruction set for performing the federation. See "Appendix D - BBOANINS for Federationof Node into DM on SYSA" on page 116 for the actual member that was created for the WSCconfiguration.

The BBOANINS instruction member will include directions for starting the new Node Agent andthe application server. The node value in the ENV= string will not be correct. The node namewill be shown as simply NODENAME, rather than the actual node name. Why? Recall that theDMGR's SAVECFG was loaded as input. That SAVECFG file may not have the actual node nameof the Base Application Server node being federated. Rather than try to take a guess at thevalue, the customization dialogs simply provide a placeholder name of NODENAME for the actualnode name. A value of <nodename> would have been a better way to indicate that you shouldprovide your actual value.

Similarly, the server short name for the application server will be listed as BBOS001.

Note:

Preparing to run the customized BBOWADDN job on SYSA

Before the BBOWADDN job was run, a few things were done to insure success.

Deployment Manager running

The federation process will not work if the Deployment Manager is stopped. We made sureit was up and running.

Base Application Server and Daemon shut down

Before a node can be federated, the server inside the node must be stopped. Thefederation process will attempt to stop the server if it sees it up and active. (You providedthe ORB port of the Base Application Server to the federation process for this purpose.)

We prefer to manually stop the Base Application Node's Daemon prior to running theBBOWADDN job. We have two reasons for doing this:

1. It's a guaranteed way of making certain the server is stopped. (The automated stopprocess can hang up if for whatever reason the server doesn't stop as it should.)

2. The automated stop process will stop the server only, but leave the Daemon running.After federation only one Daemon is necessary. Having that other unused Daemonhanging around causes no harm, but it is confusing.

Stopping the Daemon will stop all associated server tasks. That's the easiest way to stopthe Base Application Server node.




Two Daemons running ... which one should be shut down?

The Daemon controlling the Base Application Server was the one with the "temporary"JOBNAME value of AZDEMN1:

Deployment Manager

CR SR

Daemon

CR

Cell "AZCELL"

Base

CR SR

Daemon

CR

Cell "AZCELLA"

Jobname: AZDEMNProc AZDMN

ENV: AZCELL.AZCELL.SYSA

Jobname: AZDEMN1Proc AZDMN

ENV: AZCELL.AZCELL.AZDEMN1

Daemon with the "temporary" JOBNAME

of AZDEMN1

Two Daemons up and running; BaseApp Daemon is one with "temporary" JOBNAME value

Access to /tmp directory

If you look in the BBOWADDN job you'll see that it writes output to two files:/tmp/bbowaddn.out/tmp/bbowaddn.err

If those two files already exist in the /tmp directory and the permissions on those files didn'tpermit write access by the AZADMIN ID, the job would fail. Therefore, we made certainthose two files didn't exist before we ran BBOWADDN.

The only reason those files would exist in the /tmp directory is if the BBOWADDN job had beenrun before. If the BBOWADDN job was incorrectly run with a UID=0 ID, rather than theWebSphere Administrator ID, for example, the permissions might prevent the WebSphereAdministrator ID from writing to the file.

???

BBOWADDN job run

We suggest you run the BBOWADDN job on the MVS image where the Base Application Serverresides.

Note:

The BBOWADDN job was submitted, which federated the Base Application Server node into theDeployment Manager cell. It also resulted in the creation of the Node Agent.

Several things happened during federation:

The symbolic link for the Base Application Server was changed:

AZCELL.AZNODEA.AZSR01ATo

AZCELLA.AZNODEA.AZSR01AFrom:

The directory structure was changed to reflect the new cell for the node:

/wasv5config/azcell/AppServerNodeA/To

/wasv5config/azcella/AppServerNodeA/From:




The Node Agent was created with symbolic link AZCELL.AZNODEA.AZAGNTA

Various XML files were updates to reflect the change of cell for the node that wasfederated.

HTTP ports of federated server added to virtual host list

The application server of the node just federated had two HTTP ports defined to it: a standardHTTP port and an SSL port. For the Base Application Server node on SYSA, those two portswere 9548 and 9549. In order for clients to successfully reach applications installed in thatapplication server, a valid "virtual host alias" must be defined to WebSphere. A virtual hostalias consists a pair of things: a host name identifier and a port designation:

wsc1.washington.ibm.com:9548

"Host Name" "Port"

Virtual Host Alias

Virtual host alias has two components

Symptom if virtual host alias not present

If a URL is sent to an application server and a virtual host alias that will match the inboundURL is not present, you'll see an error like this:

Browser message when inbound URL not matched to a virtual host alias

Why did the application work in the Base Application Server node?

When the original Base Application Server node was created, a virtual host alias wasautomatically created for the HTTP and HTTP SSL ports as well. The aliases consisted of asingle asterisk for the "Host Name" portion and the HTTP ports you provided on the ISPFpanels during customization.

A single asterisk (" * ") value for the "Host Name" on the virtual host alias is interpreted byWebSphere to mean, "Any host value found on the URL will be accepted." The "Port" valuemust, however, be explicit. You can't code a virtual host alias of " *.* ".

Note:

Unfortunately, when that node (and the application server inside of it) was federated into theDeployment Manager cell, those virtual host aliases were not carried over to theDeployment Manager. Without that virtual host alias present, applications installed into theapplication server will not work.




How a virtual host alias is added

Adding virtual host aliases was simple enough. We logged onto the administrative consoleof the Deployment Manager and navigated down to the Host Aliases "General Properties"panel:

Environment Virtual Hosts default host Host Aliases

Host name of " * " means any host value received will be accepted

Created an alias of 9548, and then another for 9549 (the SSL port).

9548

Creating virtual host alias through the admin console of the Deployment Manager

Normally, when a new alias is created like this, it is required that the application serverhosting the HTTP port defined on the alias be restarted. Since the newly-federatedapplication server hadn't yet been started, we knew the change would be properly picked upwhen the server was started later.

Note:

Node Agent started

Node Agents must be started manually. Recall that the design of this configuration was tominimize the number of JCL procedures, and minimize the number of RACF identities. For theNode Agents that means the common controller JCL (AZACR) was used to start the NodeAgent, and the common controller ID was used (AZACRU).

The JOBNAME planned for the node agent was AZAGNTA (see "The naming convention used"on page 24).

Therefore, the start command for the Node Agent was:

START AZACR,JOBNAME=AZAGNTA,ENV=AZCELL.AZNODEA.AZAGNTA

The Node Agent initializes much more quickly than an application server. It consists of acontroller only.

Note:

Server in the newly-federated node started

The application server AZSR01A in node AZNODEA can be started in two ways:

1. Manually with an MVS START command

2. From the administrative console.

Starting server manually

The only difference in starting the server manually after federation as compared to before isthe ENV= string that's used. The ENV= string on the start command points the symbolic linkfor the server being started. During federation the symbolic link for the server was modifiedto reflect the cell short name of the Deployment Manager cell. Therefore, the startcommand for server AZSR01A is now:




START AZACR,JOBNAME=AZSR01A,ENV=AZCELL.AZNODEA.AZSR01A

Starting server from administrative console

The start command string shown in the previous paragraph is also known to theadministrative application. Through the administrative console you can tell the applicationto start the server on your behalf:

Status of a red "X" means server is not yet started

All the application servers in the Deployment Manager cell will be in

this list. Right now there's only one.

Select server

1Click

"Start"

2

x

Starting a server from the administrative console

A "Status" of a green arrow pointing the right is an indication of the server having started.But be careful: that only means that the controller has started, and does not necessarilymean that the servant is running. We have seen people point their browsers at the serverimmediately after the green arrow appearing, only to have their request fail (because theservant is not up, or their application has not yet started). The other possible problem is afaulty start parameter coding in a static WLM application environment. (Dynamic WLMapplication environments will not have this problem.) A faulty start string coded there -- typoin the procedure name, for example -- will mean the servant doesn't start. You'll still see agreen arrow on the administrative console even though the server is in no shape to serveapplications.

Note:






SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL



SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZSR01A

CR SR

AZDEMN

CR

SYSB

Node: AZNODEA

Cell: AZCELL

Nothing yet in SYSB





Base Application Server node created on SYSBThis is where this section of the document will focus:


node on SYSB






cell on SYSA




Domain

Creating the Base Application Server node over on SYSB

Overview

This process was virtually identical to the process done back under "Base Application Servernode created on SYSA" starting on page 37. The only differences were the values supplied tothe ISPF panels. This section will show the panels, but will not provide as much commentary.

It's important to visualize what's going on here: we're building a Base Application Server nodeon SYSB that will get federated into the Deployment Manager cell on SYSA:

SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Daemon

CR

SYSB

This portion already exists

Building this portion in this

section

Next section this will be federated into DM on SYSA

What is being done in this section of the process

This is how WebSphere for z/OS cells are scaled horizontally.

Note about where to run ISPF panels for Base Application Server on SYSB

The ISPF panels may be run from on any system in the Sysplex. The only thing the ISPFdialogs do is generate a set of a set of customized jobs in the two target data sets.

Where you run the customized jobs may matter, depending on the degree of sharing that'sgoing on in your Sysplex. In the WSCPLEX environment, nearly everything is shared so the jobscould be run from anywhere.


Section: Base Application Server on SYSBVersion Date: Tuesday, March 09, 2004- 73 -© 2003, IBM Americas Advanced Technical Support


But the BBOWCHFS job -- the one that creates and mounts the HFS -- should be run on thesystem that you intend to own the HFS. In this "everything shared" environment, that was SYSA.Why? Because the Deployment Manager lives on SYSA, and that makes a lot of updates to theHFS.

Note:

ISPF Panels for the Base Application Server node on SYSB

Variables Loaded

We had two sets of variables to load: the SAVECFG from the BaseApp server on SYSA, andthe Security Domain SDCFG file.

BaseApp SAVECFG from SYSA loaded

Since the Base Application Server node on SYSB is very similiar to the one we createdearlier on SYSA, we made use of the SAVECFG from that configuration as input to thisBase Application Server. Option L was selected:

Load Customization Variables Specify the name of a data set containing the customization variables. IBM-supplied defaults are in 'WAS502.WAS.SBBOEXEC(BBOWVARS)' Press Enter to continue. Data set name: 'WAS502.AZBASEA.SAVECFG'

SAVECFG from the BaseApp for SYSA

Loading SAVECFG from Base Application Server configuration on SYSA

Though it was not absolutely necessary to use the SAVECFG from the first BaseApplication Server node, it did save a lot of time typing and helps insure consistency ofsome of the common values.

Note:

Security Domain SDCFG loaded

Option 1 was selected and the Security Domain variables loaded:

Load Customization Variables Specify the name of a data set containing the customization variables. IBM-supplied defaults are in 'WAS502.WAS.SBBOEXEC(BBOWSECV)' Press Enter to continue. Data set name: 'WAS502.AZSECDM.SDCFG'

SDCFG from the Security Domain

Loading SDCFG from Security Domain

What is critical is that the "WebSphere Configuration Group" be thesame here as it was on SYSA. By loading the SDCFG from the SecurityDomain customization, that value is loaded into these panels.

Important Point!


High Level Qualifier: WAS502.AZBASEB .CNTL .DATA

Separate set of target data sets

Allocation of separate target data sets for customized output for BaseApp Server on SYSB




We recommend storing each configuration component in separate target data sets. Itmakes things much easier.

Note:



System name.: SYSB Sysplex name : WSCPLEX Full Names of Data Sets PROCLIB.: SYS1.PROCLIB PARMLIB.: SYS1.PARMLIB SYSEXEC.: SYSS.WSC.SYSEXEC In LNKLST or LPA (Y or N)? SCEERUN..: CEE.SCEERUN Y SBBOLOAD.: WAS502.WAS.SBBOLOAD N SBBOLD2..: WAS502.WAS.SBBOLD2 N SBBOMIG..: WAS502.WAS.SBBOMIG N SBBOLPA..: WAS502.WAS.SBBOLPA N SGSKLOAD.: SYS1.CRYPTO.SGSKLOAD N SBBOEXEC.....: WAS502.WAS.SBBOEXEC SBBOMSG......: WAS502.WAS.SBBOMSG

Note: different System name

System Locations, panel 1 of 2

The "System name" field will be populated with whatever system name you're on whenyou run the ISPF dialogs. We recommend you run the ISPF dialogs on the MVS imageon which this server structure will run.

Note:


Locations of HFS Resident Components WebSphere SMP/E home directory.: /usr/lpp/zWebSphere/V5R0M2 WebSphere JMS Client Java Feature SMP/E home directory.: /usr/lpp/mqm/V5R3M1 java home directory.: /usr/lpp/java2/J1.3

Same values as on SYSA

System Locations, panel 2 of 2



Note: common, shared HFS for all elements of this

configuration

System Environment Customization, panel 1 of 3

The job BBOWCHFS will be customized to create the HFS. But since we're sharing anHFS, it's already there from before. We didn't run BBOWCHFS for this BaseApp. But theinformation still needs to be supplied because this panel also provides the mount point,which is a key piece of information for some of the other jobs.

Note:





WebSphere Error Logstream Information Name.................: AZCELL.ERROR.LOG Data class ..........: STANDARD Storage class........: HLQ for data sets....: LOGGER Is logstream CF resident (Y|N) : Y If yes, specify structure name.: AZCELL_ERRORLOG If no, specify: logstream size.: 3000 staging size...: 3000 RRS Logstream Information Group name...........: WSCPLEX Data class...........: STANDARD Storage class........: HLQ for data sets....: LOGGER Is logstream CF resident (Y|N).: Y

Exact same information as

used for the first Base Application

Server



CTRACE Writer Definitions Procedure name.: AZCTRW User ID........: STCRACF Group..........: SYS1 Trace Data Set Information Name...................: SYS1.SYSB.WAS390.CTRACE Volume, or "*" for SMS.: * Primary space in cylinders...: 10 Secondary space in cylinders.: 0 Trace Parmlib member suffix....: AZ

Note: slightly different

information






Application Server definitions WAS home directory.....: /wasv5config/azcell / AppServerNodeB Cell name (short)......: AZCELLB Cell name (long).......: azcellb Node name (short)......: AZNODEB Node name (long).......: aznodeb Server name (short)....: AZSR02B Server name (long).....: azsr02b Cluster transition name: AZSR02

See Note 1

See Note 2

See Note 3

Server Customization, panel 1 of 4

Why a server number of AZSR02B, and not AZSR01B? Because one of the design objectivs isto consider all servers as members of a cluster. (See "Application servers are considered tobe a member of a cluster" on page 20.) Naming the initial application server on SYSBAZSR02B "makes room" on SYSB so the server over on SYSA can be extended to form acluster. The cluster would consist of servers AZSR01A (on SYSA) and AZSR01B (on SYSB).Both server members in the cluster will have as their root the string AZSR01. That's key: that's also the WLM application environment name for this cluster. Similarly, the serverAZSR02B on SYSB can joined with a cloned server called AZSR02A on SYSA to form anothercluster with a WLM application environment of AZSR02.This is somewhat confusing at first, but very elegant. See "Cluster created across SYSA andSYSB" on page 91 for information on how the AZSR01 cluster was created.

3

Since this node will be federated into the Deployment Cell immediately after construction, thecell short and long names are "throwaway" names; that is, they're used only until the node isfederated. The DM cell name is AZCELL. This is made unique and disposable with the "B" atthe end of it. See "Temporary nature of Base Application Server node Daemons" on page 46.

2

Note how the mount point is the same (we're sharing an HFS between SYSA and SYSB), butthe directory under that is different from the one used for the BaseApp on SYSA: /AppServerNodeB. This directory and everything under it represents the node structure.This is something we carefully made sure was unique for each Base Application Server nodethat was inside the same HFS.

1





Application Server definitions Controller information Jobname........: AZSR02B Procedure name.: AZACR User ID........: AZACRU UID............: 2431 Servant information Jobname........: AZSR02BS Procedure name.: AZASR User ID........: AZASRU UID............: 2432

Jobname values are specific to

this set of servers on SYSB

PROC and Userid information is the

same as the earlier BaseApp

server

Able to do this only because of shared HFS and shared PROCLIB


The job name values are unique to make it easier to manage the started tasks when thewhole configuration is started. We're using the same RACF userids for everything, asoutlined under "Minimize RACF userids and groups" on page 7.


Application Server definitions Node host name...........: wsc2.washington.ibm.com SOAP JMX Connector port...................: 9550 DRS Client Address port...................: 9551 ORB Listener host name...: * ORB port..................................: 9552 ORB SSL port..............................: 9553 HTTP transport host name.: * HTTP port.................................: 9558 HTTP SSL port.............................: 9559

See Note 1 below

See Note 2 below


This Base Application Server has a different set of TCP ports from the server over on SYSA.The numbering scheme is related, however. See "How the fenced-off ports were allocated tothe various servers" on page 16 to understand how the ports were allocated.

2

This Base Application Server node is over on SYSB, which has a different TCP host namefrom SYSA.

1





Location Service Daemon definitions Daemon Home Directory: /wasv5config/azcell/Daemon Daemon Job Name: AZDEMN2 Procedure Name.: AZDMN User ID........: AZACRU UID............: 2411 IP Name........: wsc2.washington.ibm.com Port...........: 9506 SSL Port.......: 9507 Register Daemon with WLM DNS: N

See Note 1 below

See Note 2 below

See Note 3 below

See Note 4 below


Two things here:The IP name is the system-specific IP name for SYSBThe ports here are the same "interim port" values used for the Base Application ServerDaemon for SYSA. See "Temporary nature of Base Application Server node Daemons" onpage 46 for an explanation of this.

4

The exact same information as used for the Daemons over on SYSA. Client access toDaemon ports are handled through Sysplex Distributor. See "Utilize Sysplex Distributor" onpage 18.

3

The job name is made unique with the number "2" at the end. After federation, this server willmake use of a new Daemon, created during the federation process, that'll have the samename as the Deployment Manager's Daemon.

2

This is the same mount point and directory as the Deployment Manager's Daemon over onSYSA. The HFS is shared. The two daemon's have unique directories, but further down in theHFS. Each Daemon has its own unique symbolic link used when starting the Daemon.

1




Similar to what has been done for the other customization runs:

Data set name: 'WAS502.AZBASEB.SAVECFG' Another separate data set

SAVECFG file for this customization run, saved into a separate data set





Jobs and data files will get generated into data sets: 'WAS502.AZBASEB.CNTL' 'WAS502.AZBASEB.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=SYSADM1,PASSWORD=xxxxxx //* /*JOBPARM SYSAFF=SYSB

Target data sets for this configuration

USER= and PASSWORD= for UID=0 ID manually coded

Generate customized jobs for Base Application Server node on SYSB


Important Point!

Manual updates made and customized jobs run

The process was very similar to what was done for the Base Application Server node on SYSA,as discussed back under "Manual updates made" on page 48 and "Customized jobs run" onpage 49.

However, because this configuration is making use of a shared HFS and minimized RACFprofiles, not all the jobs had to be run. Here's what was run:

Members copied when this job run on SYSA sufficient.NoBBOWCPY1

Configures a directory for UDDI registry. This configuration doesn't useUDDI, but running this causes no harm and prevents one of the later jobsfrom getting a RC 4.

YesBBOMCFGU

This is what creates the /AppServerNodeB directory structure andsub-directories.

YesBBOMCFG

Shared HFS used; already allocated when BBOWCHFS run on SYSA.NoBBOWCHFS

Ditto.NoBBOCBRAK

Used modified RACF script with generic profiles. Run once and sufficient forentire configuration. But if you use the generated RACF profiles, you would runthis job to create profiles for this BaseApp server.

NoBBOCBRAJ

Job run on SYSA sufficient for SYSB as well.NoBBOWCTR

Common log streams used; not run on SYSB.NoBBORRSLS

We ran this job for the first Base Application Server node and re-used the sameerror log stream for other servers.

NoBBOERRLG

Not run on SYSA either; we're not using message translation.NoBBOMSGC

Notes on why run or not runRun?Job




Finalized the HFS.YesBBOMCFG2

Administrative application installed so the server could be validated priorto federation.

YesBBOWIAPP

Creates the was.env from the information stored in many different placesthroughout the Base Application Server node HFS.

YesBBOWC2N

This is what copies XML files and shell scripts into directory structure.YesBBOWCPY2

Notes on why run or not runRun?Job

Base Application Server started on SYSB

The command to start your Base Application Server on SYSB was provided in the BBOSSINSinstruction member. The command was:

S AZACR,JOBNAME=AZSR02B,ENV=AZCELLB.AZNODEB.AZSR02B



short name

Cell short

Node short

Server short


Sequence of events:

Start command for the Base Application Server node

Starting the server at this point in time servers two purposes: one, it validates things; and two, itresults in the the running of the applyPTF step in the JCL. That's a prerequisite to federatingthe node later.

Note:

Base Application Server validated

We feel that driving the administrative application (installed into the Base Application Serverwith the BBOWIAPP job) is a pretty good initial test.http://wsc2.washington.ibm.com:9558/admin/

The TCP port 9558 is the "HTTP Port" defined on "Server Customization, Panel 3 of 4" in theISPF dialogs. That's the port on which the Base Application Server is listening for non-SSL HTTP.The context root for the administrative application is /admin/.

???

If you get the logon panel and can get to the primary panel of the administrative application, youcan be fairly certain the server is up and running properly.






SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL



Almost there: the node on SYSB is created, but not yet federated into the DeploymentManager cell. That was the next step.

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN2

CR

AZSR01A

CR SR

AZDEMN

CR

SYSB

AZSR02B

CR SR

Node: AZNODEA

Node: AZNODEB

Cell: AZCELL

Cell: AZCELLB

Two completely separate cells at this

point in time

Temporary names





Federated Base Application Server node on SYSB into the DM cellThis section of the document will focus on:


node on SYSB






cell on SYSA




Domain

Federating the SYSB Base Application Server node into the Deployment Manager's cell

Federating a node on an MVS image other than where the Deployment Manager lives

By this we mean the following:

SYSA SYSB

Deployment Manager

Cell



This Base Application Server node resides on a different MVS image from the Deployment Manager.

Federating a node may be within the same MVS image, or from another image in the Sysplex

But it must be within the same Sysplex. A cell may not span Sysplexes.Note:

Recall from the discussion back in "Federated Base Application Server node on SYSA into theDM cell" on page 61 a few things about the process of federating a node:

The process requires the IP host name and the JMX Soap port of the Deployment Managerserver. The initial "handshake" used to start the federation is done across the IP network.The federation process is designed to work the same whether the node being federated ison the same MVS image or a different one.

The Base Application Server node's HFS (in other words, the HFS of the node beingfederated) is not moved, it is altered. The references to the old cell name are updated tothe Deployment Manager's cell name, but the HFS itself is not moved.

Updates to HFS made by shell script process

The BBOWADDN job is actually nothing more than a batch running of the addNode.sh shellscript. That shell script knows about the node being federated based on the mount pointdirectory and node directory information supplied to the addNode.sh shell script. TheaddNode.sh shell script communicates with the Deployment Manager to get informationabout the target cell, and it's the shell script that makes the changes to the HFS:


Section: Federation of BaseApp on SYSBVersion Date: Tuesday, March 09, 2004- 83 -© 2003, IBM Americas Advanced Technical Support


SYSA SYSB

Deployment Manager

Cell

Base Application Server node HFS

addNode.shBBOWADDN

Deployment Manager updates its directories to reflect

node joining cell

Shell script updates

directories of node being

federated

Shell script makes changes to the HFS of the node being federated

Running BBOWADDN when HFS is un-shared

If the configuration data is being held in unshared HFS, then it's important to run theBBOWADDN job on the MVS image where the Base Application Server node resides. Theinstructions in the BBOANINS member suggest this:

RULES: 1. If you created the target data sets (*.CNTL and *.DATA) on another (driving) system, you must copy them to the target system and give them the same data set names. 2. You must perform these instructions on your target system.

CNTLBBOANINS

"Target system" means the MVS image on which the Base Application Server node being federated resides.

Instructions in BBOANINS indicate job must be run on "target" system

Running BBOWADDN when HFS is shared

The AZCELL configuration is using a single, shared HFS between all the MVS images tohold the WebSphere configuration data.

Regardless of the shared/unshared nature of your configuration HFS, run theBBOWADDN job on the MVS image where the node being federated resides.

Important Point:

Same TCP ports used by both Node Agents

Because this cell configuration is making use of Sysplex Distributor (see "Utilize SysplexDistributor" on page 18 for more on this), the two Node Agents will have the same TCPports:




SYSA

Server

CR SR

Node Agent

CR

DM

CR SR

Daemon

CR

Server

CR SR

Daemon

CR

Node Agent

CR

SYSB

wsc1.washington.ibm.comTCP Stack

wsc2.washington.ibm.comTCP Stack

SOAP JMX Connector port........: 9520DRS Client Address port........: 9521Node Discovery port............: 9524Node Multicast Discovery port..: 9525ORB port.......................: 9522ORB SSL port...................: 9523

Both Node Agents utilize the same TCP ports

Both Node Agents in this configuration use the exact same TCP ports

ISPF Panels for federating the Base Application Server node on SYSB


In keeping with the practice of having a separate set of target data sets for each task, anew set was allocated:

High Level Qualifier: WAS502.AZFEDB .CNTL .DATA

HLQ Indicates this is federation job for

node on SYSB

Allocating a separate set of target data sets for customized federation jobs

Load customization variables

The SAVECFG from the Deployment Manager was loaded into the ISPF dialogs. Thisprovides information on how to contact the Deployment Manager:

Data set name: 'WAS502.AZDMGR.SAVECFG'Deployment

Manager

Loading SAVECFG from Deployment Manager

And then SDCFG from the Security Domain was loaded:

Data set name: 'WAS502.AZSECDM.SDCFG'Security Domain

Loading SDCFG from Security Domain




Define variables

A single panel is used to define the variables needed to federate the Base ApplicationServer node on SYSB into the Deployment Manager cell, also on SYSB:

Define variables for Federate Base Application Server node (1 of 1) Specify the following to customize your WebSphere for z/OS server. Press Enter to continue. WAS home directory.....: /wasv5config/azcell / AppServerNodeB Deployment Manager access: Node host name........: wsc1.washington.ibm.com JMX Soap port.........: 9510 Deployment Manager Security is Enabled: N Userid.............: AZADMIN Include Apps..........: Y Base server ORB port..: 9552 Node Agent definitions: Server name (short)...: AZAGNTB Server name (long)....: nodeagent SOAP JMX Connector port........: 9520 DRS Client Address port........: 9521 Node Discovery port............: 9524 Node Multicast Discovery port..: 9525 ORB Listener host name...: * ORB port.......................: 9522 ORB SSL port...................: 9523

1

2

4

5

3

Defining the customization variables for the federation of the node

All the ports that will be used by the newly-created Node Agent. These are the exact sameTCP ports as given the other Node Agent over on SYSA. See "Utilize Sysplex Distributor" onpage 18.

6

This is what the Node Agent's short name will be. See "The naming convention used" onpage 24 for a discussion of the naming convention we used. The long name is a fixed valueof nodeagent.

4

The ORB port of the BaseApp server on SYSB. This may or may not be property filled in foryou. It all depends on what values are the SAVECFG loaded. In any event, you should insurethis accurately points to the ORB port of the BaseApp server being federated.

3

Since the SAVECFG from the Deployment Manager was loaded for this federation job, thevalues found in the "Deployment Manager access" section were the same as seen under thefederation done on SYSA.

2

You should make certain the "WAS home directory" value correctly points to the node beingfederated.

1


The variables for this federation operation were saved into a separate SAVECFG data setcalled WAS502.AZFEDB.SAVECFG:




Data set name: 'WAS502.AZFEDB.SAVECFG'

Variables for federation of node on SYSB saved into separate SAVECFG data set


The customized jobs were generated into the target data sets defined earlier:

Jobs and data files will get generated into data sets: 'WAS502.AZFEDB.CNTL' 'WAS502.AZFEDB.DATA' If you wish to generate using other data sets, then END from this panel and select option 1 (Allocate target data sets). All the jobs that will be tailored for you will need a jobcard. Please enter a valid jobcard for your installation below. The file tailoring process will update the jobname for you in all the generated jobs, so you need not be concerned with that portion of the job cards below. If continuations are needed, replace the comment cards with continuations as needed. Specify the job cards. Press ENTER to continue. //jobname JOB (ACCTNO,ROOM),'HUTCH',CLASS=A,REGION=0M, // USER=AZADMIN,PASSWORD=AZADMIN //* /*JOBPARM SYSAFF=SYSB

Only CNTL was actually used. DATA

was empty.

Add the USER= and PASSWORD= to the JOB card so the job runs under the authority of the

WebSphere Administrator ID

Federation jobs generated into target data sets; WebSphere Admin ID set on job card

The USER setting on the JOB card must be set so the job runs underthe authority of the WebSphere administrator. (Or a UID=0 ID) Thevalue for the WebSphere Administrator was set back in the SecurityDomain configuration.

You must manually code the value and password on the JOB cardprovided on this panel .

Important Point!

Three members are written to the CNTL data set:

BROWSE WAS502.AZFEDB.CNTL Command ===> Name _________ BBOANINS _________ BBOTCPIA _________ BBOWADDN

Instruction member

TCP port reservation text for cut/paste into

TCP profileCustomized job that

was submitted to federate the node

Three customized members written into the CNTL target data set for federation of node on SYSA

BBOANINS instructions

The instructions for this federation effort were nearly identical to the ones issued for thefederation on SYSA. They were written into the BBOANINS member of theWAS502.AZFEDB.CNTL data set. (For a peek at the BBOANINS member from the SYSA




federation, see "Appendix D - BBOANINS for Federation of Node into DM on SYSA" on page116.)

Again, the START string examples in the BBOANINS member for the server and Node Agent willbe incorrect. They will have a fixed name of NODENAME for the node component of the ENV=string. The values shown in this document are correct for this configuration.

Note:

Preparing to run the customized BBOWADDN job

Similar to what was done back under "Preparing to run the customized BBOWADDN job onSYSA" on page 67:

Deployment Manager running

The Deployment Manager must be running and listening on the SOAP port you specified inthe ISPF panels.

Base Application Server and Daemon shut down

On the SYSB system there was the Base Application server (controller and servant) and aDaemon. Stopping the Daemon on SYSB (with JOBNAME=AZDEMN2) stopped all theWebSphere tasks on SYSB.

Could this have been left running? Yes. The addNode.sh process would have detected therunning server and would have attempted to stop it. We advocate manually shutting down theserver and Daemon prior to running BBOWADDN for two reasons:

1. It's a guaranteed way of insuring the server actually is stopped2. It results in the Daemon be stopped as well. BBOWADDN would not stop the Daemon. It

would only stop the application server. That running Daemon wouldn't cause any harm,but it could prove confusing.

???

Access to /tmp directory

If BBOWADDN was run previously, it's possible that the files bbowaddn.err andbbowaddn.out are in the /tmp directory. If the permissions on those existing files don'tpermit write access by BBOWADDN, running under the WebSphere administrator ID(AZADMIN in this configuration), the job will fail.

It's not the mere presence of the file in the /tmp directory that's the issue. It's if those filesexist and the permissions are too restrictive. This might be the case if, for example, you ranthe BBOWADDN job under the authority of a UID=0 ID rather than the WebSphereadministrator ID. That job would fail because the ID wasn't the WebSphere administrator ID,but the files would be written under the UID=0 ID's authority with permissions 644. Thesecond running of BBOWADDN would then fail because the WebSphere administrator's IDcouldn't overwrite the files.

Note:

BBOWADDN job run

As before, the customized BBOWADDN job was submitted. This invokes the addNode.sh shellscript in batch mode, and supplies the parameters as specified in the ISPF panel.

HTTP ports of federated server added to virtual host list

Just like what was done back under "HTTP ports of federated server added to virtual host list"on page 69, the HTTP ports of the application server on SYSB (9558 and 9559) needed to beadded to new "virtual host aliases" defined in the Deployment Manager.




Node Agent started

Node Agents must be started manually. Recall that the design of this configuration was tominimize the number of JCL procedures, and minimize the number of RACF identities. For theNode Agents that means the common controller JCL (AZACR) was used to start the NodeAgent, and the common controller ID was used (AZACRU).

The JOBNAME planned for the node agent was AZAGNTB (see "The naming convention used"on page 24).

Therefore, the start command for the Node Agent was:

START AZACR,JOBNAME=AZAGNTB,ENV=AZCELL.AZNODEB.AZAGNTB

Server in the newly federated node started

The application server AZSR01B in node AZNODEB can be started in two ways:

1. Manually with an MVS START command

2. From the administrative console.

Starting server manually

The only difference in starting the server manually after federation as compared to before isthe ENV= string that's used. The ENV= string on the start command points the symbolic linkfor the server being started. During federation the symbolic link for the server was modifiedto reflect the cell short name of the Deployment Manager cell. Therefore, the startcommand for server AZSR01B is now:

START AZACR,JOBNAME=AZSR02B,ENV=AZCELL.AZNODEB.AZSR02B

Starting server from administrative console

The start command string shown in the previous paragraph is also known to theadministrative application. Through the administrative console you can tell the applicationto start the server on your behalf:

Status of a red "X" means server is not yet started

Select server

1

Click "Start"

2x

Server on SYSA

Starting a server from the administrative console

As mentioned before, a green arrow indicates only that the controller is started, notnecessarily that the servant is up and ready to service applications. Be aware of that.

Note:






SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL



SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR02B

CR SR


Cell: AZCELL





Cluster created across SYSA and SYSBThis this point we had a configuration where a single server existed on SYSA and a single server onSYSB. Those were the servers that were part of the Base Application Server nodes that werefederated into the Deployment Manager cell. Our configuration looked like this:

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR02B

CR SR


Cell: AZCELL

Notice this gap right here? This is where the clone of

server AZSR01A will be created. It

will be called AZSR01B.

Together they'll formed the

two-member cluster called

AZSR01

Configuration just prior to the creation of the cluster across SYSA and SYSB

The creation of a server cluster within WebSphere for z/OS is done through the administrativeconsole.

New cluster created

A new cluster is created by navigating to the clusters panel in the administrative console:

Click "New"

Servers Clusters

How a new cluster is created


Section: Create Cluster across SYSA and SYSBVersion Date: Tuesday, March 09, 2004- 91 -© 2003, IBM Americas Advanced Technical Support


Existing server azsr01a selected as starting server in cluster

There are two options when creating a cluster: start your cluster by creating a brand newserver, or start your cluster by choosing an existing server as the first member. For theAZCELL configuration, we chose the azsr01a server as the starting point:

Cluster long name of azsr01Cluster typed here

Objective was to use server azsr01a on SYSA as the

starting server. That server selected from the pulldown list of available servers for

clustering.azcell/aznodea/azsr01a

Existing server azsr01a on SYSA chosen as initial server in cluster




New clustered server created on AZNODEB

Once the first -- or initial -- server member was defined, the second server was defined. Thisresulted in a clone of the initial server being created over on SYSB:

Name of the new -- or second member -- in the

cluster: azsr01b

Node on which it was created:

SYSB (or aznodeb)

Objective: same TCP ports; therefore, UNchecked box

azsr01a aznodeaThe initial server

"Apply" clicked to include this second server into the cluster that was being defined

Note 1

Note 2

Note 3

Note 4

Creation of the second server in cluster

After clicking the "Apply" button, your new server -- azsr01b -- will appear4

Clicking this "Apply" button is very important. It updates the application servers shown in the list at thebottom of the panel. If you don't click "Apply," this new server will not be included in the list of serversthat will be part of the cluster.

3

UN-checking this box means the HTTP ports will be identical. But it does not insure the other ports willbe the same. That's a manual step that must be done after the cluster is created. See "TCP ports ofnew clustered server remapped" on page 93.

2

This cluster made use of azsr01a (the long name) as its initial server. That server was over onSYSA. We're extending the cluster horizontally to the SYSB node. In keeping with our namingconvention, the second server was named azsr01b -- the trailing "b" being the system indicator. Butthe azsr01 portion is the same, as it must be: see "Application servers are considered to be amember of a cluster" on page 20.

1

Then the change was saved to the master configuration.

TCP ports of new clustered server remapped

It turns out that while WebSphere for z/OS will create the second server with the same HTTPports as the first server, but it did not give us the opportunity to specify that all TCP ports be thesame. So the second server -- the one created over on SYSB -- was created withWebSphere-generated TCP ports. Recall that our objective was to tightly control the TCP portsthat were being used, and to not allow any default TCP ports. Therefore, we had to go into theadministrative console and re-map the TCP ports.




We accessed the non-HTTP ports used by navigating down to the "End Points" function underthe "Additional Properties" for server azsr01b, and mapped the values to the same port valuesas used by azsr01a:

9542

9541

9542

9543

9540

Port values for AZSR01B remapped to equal the ports

assigned to AZSR01A

TCP ports for new server azsr01b mapped to equal ports defined earlier for azsr01a

Change new cluster member's short name from default

The default short name given to the new server will be BBOS001, which didn't align with ournaming convention. The default short name was changed to AZSR01B (uppercase) in theAdmin Console, under "Servers" "Application Servers," and then under "General Properties"for the new server.The change was saved to the master configuration.




The Final ConfigurationAnd we return to the configuration presented at the very beginning of this paper:

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZDEMN

CR

AZSR01A

CR SR

AZAGNTB

CR

AZDEMN

CR

SYSB

AZSR01B

CR SR

AZSR02B

CR SR

Cluster: AZSR01


Cell: AZCELL

Sysplex Distributor

The final configuration of AZCELL




Appendix A - BBOSSINS for Base Application Server node on SYSAWhat follows is the actual BBOSSINS member created for the Base Application Server nodecreated on SYSA:-----------------------------------------------Instructions for customizing WebSphere for z/OSfor a base application server node.

The customization dialog has created jobs based on the information youprovided. These instructions tell you how to modify the operatingsystem and run the jobs to customize WebSphere for z/OS.

RULES:

1. If you created the target data sets (*.CNTL and *.DATA) on another (driving) system, you must copy them to the target system and give them the same data set names.

2. You must perform these instructions on your target system.

Doing manual configuration updates----------------------------------

The customization dialog for WebSphere for z/OS does not attempt toupdate configuration data for your base operating system or existingsubsystems. You must do the following manual steps prior to runningthe WebSphere for z/OS configuration jobs.

BEFORE YOU BEGIN: You must copy the target data sets (*.CNTL and*.DATA) to your target system and give them the same data set names.

You must be running on your target system.

Perform these steps to do manual configuration updates:

1. Update the workload management application environment as follows.

ATTENTION: If you have already installed the WLM-DAE support PTF (APAR OW54622, on z/OS 1.2 or higher) you may skip this step.

Using these parameters, run IWMARIN0 to create the AZSR01 application environment:

Appl Environment Name AZSR01 Description WebSphere for z/OS V5 servant Subsystem type CB Procedure name AZASR Start parameters JOBNAME=&IWMSSNM.S, ENV=AZCELLA.AZNODEA.&IWMSSNM Limit on starting server address spaces for a subsystem instance: 2. Single address space per system

NOTE: For the start parameter string, you must continue typing with ENV on the same line as JOBNAME. We show the parameters on separate lines for aesthetics only.

For information about IWMARIN0, the ISPF dialog application for MVS workload management, see OS/390 MVS Planning: Workload Management (GC28-1761) or z/OS MVS Planning: Workload Management (SA22-7602).

For more information about workload management and WebSphere for z/OS, see related topics in the WebSphere for z/OS Information Center at


Section: Appendix A - BBOSSINS InstructionsVersion Date: Tuesday, March 09, 2004- 96 -© 2003, IBM Americas Advanced Technical Support


http://www.ibm.com/software/webservers/appserv/zos_os390/library/.

-------------------------------------------------------------------

2. Update BLSCUSER. Refer to member BBOIPCSP in

'WAS502.AZBASEA.CNTL'

In order to use the IPCS support provided by the product, append the contents of this member to the BLSCUSER member in your IPCSPARM or system PARMLIB datasets.

ATTENTION: If you are migrating from WebSphere for z/OS v4.0.1 to v5, you may skip this step.

-------------------------------------------------------------------

3. Update SCHEDxx. Refer to member BBOSCHED in


In order to set the correct program properties for the WebSphere for z/OS run-time executables, append the contents of this member to the SCHEDxx member in your system PARMLIB concatenation.

Note: When you are finished, issue the command SET SCH=(xx,xx) to activate SCHEDxx and load a new program properties table.

ATTENTION: If you are migrating from WebSphere for z/OS v4.0.1 to v5, you may skip this step.

-------------------------------------------------------------------

4. Make sure the following data sets are APF-authorized:

WAS502.WAS.SBBOLPA WAS502.WAS.SBBOLOAD WAS502.WAS.SBBOLD2 CEE.SCEERUN

Add these datasets to your PROGxx or IEAAPFxx parmlib members, as appropriate, ensuring you specify the correct volsers.

-------------------------------------------------------------------

5. If you want to collect the SMF120 records created by the run-time servers, update SMFPRMxx via the following:

a. Update the SYS or SUBSYS(STC,...) statement for started tasks to include the 120 record. b. (Optional) You can specify designated subtypes 1-6.

EXAMPLE:

SUBSYS(STC,EXITS(IEFU29,IEFACTRT),INTERVAL(SMF,SYNC), TYPE(0,30,70:79,88,89,120,245)) ---

For details on the SMF records, see related topics in the WebSphere for z/OS Information Center.

-------------------------------------------------------------------

6. Update your active BPXPRMxx member to have the following WebSphere




for z/OS configuration HFS:

OMVS.WAS.AZCELL.CONFIG.HFS

mounted at:

/wasv5config/azcell

in read/write mode.

EXAMPLE:

MOUNT FILESYSTEM('OMVS.WAS.AZCELL.CONFIG.HFS') MOUNTPOINT('/wasv5config/azcell') TYPE(HFS) MODE(RDWR)

-------------------------------------------------------------------

7. Update TCP/IP by reserving the following ports for WebSphere for z/OS:

SOAP JMX Connector port - 9540 ORB port - 9542 ORB SSL port - 9543 HTTP port - 9548 HTTP SSL port - 9549 Daemon IP port - 9506 Daemon SSL port - 9507

View member BBOTCPIP in


Add the contents of this member to the PORT section of the file referenced by the DD statement for the TCP/IP profile in the TCP/IP start procedure. Cut and paste from this member into the data set used by your installation.

ATTENTION: If another application has already reserved any of these ports for its own use, you must resolve the resulting conflict before you continue. If you update the WebSphere for z/OS customization dialog with new port specifications, be sure to regenerate the customization jobs, data, and instuctions.

-------------------------------------------------------------------

8. If you are running a single version of WebSphere for z/OS on your system, proceed as follows:

Load the contents of the following data set into the system link pack area (LPA).

WAS502.WAS.SBBOLPA

Load the contents of the following data set into the LPA. If your system has LPA constraints, you can place this data set into the system linklist.

WAS502.WAS.SBBOLOAD

Place the following data set in the system linklist. You must NOT load it into the LPA.




WAS502.WAS.SBBOLD2

If an existing version of WebSphere for z/OS is in your system LPA or linklist, OR if you choose to not put WebSphere for z/OS V5 in the system LPA or linklist, proceed as follows:

Load the BBORTSS5 member of the data set

WAS502.WAS.SBBOLPA

into the system LPA using the SETPROG LPA command issued from the MVS console or from a COMMNDxx parmlib member:

SETPROG LPA,ADD,MODNAME=BBORTSS5, DSNAME=WAS502.WAS.SBBOLPA

The BBORTSS5 member is version-specific and MUST be present in the LPA.

Make sure you have specified in the dialog that the following data sets are NOT in LPA or linklist:

WAS502.WAS.SBBOLPA WAS502.WAS.SBBOLOAD WAS502.WAS.SBBOLD2

Instead, they will be placed in started task STEPLIBs as needed. If you change dialog variables at this point, rerun the Generate Customization Jobs step in the dialog to make this change effective.

Because these data sets are PDS-Es, you cannot place them in the LPA using IEALPAxx or LNKLSTxx parmlib members. Instead, load the data sets into the LPA using the SETPROG LPA command issued from the MVS console or from a COMMNDxx parmlib member:

SETPROG LPA,ADD,MASK=*,DSNAME=WAS502.WAS.SBBOLPA SETPROG LPA,ADD,MASK=*,DSNAME=WAS502.WAS.SBBOLOAD

To place the WebSphere for z/OS data sets in the linklist, use LNKLST statements in a PROGxx member.

ATTENTION: Be sure that your MLPA size is large enough to hold the z/OS modules (170K for SBBOLPA and 30M for SBBOLOAD). For more information, see related topics in the WebSphere for z/OS Information Center.

-------------------------------------------------------------------

9. WebSphere for z/OS regions open a large number of files (more than 1024). Make sure your BPXPRMxx parmlib member(s) specify a value of MAXFILEPROC that is greater than or equal to 2000. Use the following MVS console command to see your current MAXFILEPROC setting:

D OMVS,OPTIONS

-------------------------------------------------------------------

10. Grant AZACRU read access to SYS1.PARMLIB and any other parmlibs that precede SYS1.PARMLIB in the parmlib concatenation of the LOADzz member in IPLPARM. Use




the D IPLINFO command to determine which LOADzz member is current and where it resides.

-------------------------------------------------------------------

11. Update the CFRM Policy. Prior to using log streams that have been indicated as CF-resident, you must update the CFRM policy to define the structures to be used. Tailor member BBOWCFRM in the following data set to define the log streams:


-------------------------------------------------------------------

Running the customized jobs---------------------------

The customization dialog built a number of batch jobs with thevariables you supplied. You must run the jobs in the order listedbelow using user IDs with the appropriate authority.

BEFORE YOU BEGIN: Complete the section above entitled "Doing manualconfiguration updates."

Follow the table below, which lists in order the jobs you must submitand the commands you must enter. Special handling notes are includedin the table. All jobs are members of

WAS502.AZBASEA.CNTL

Attention: After submitting each job, carefully check the output.Errors may exist even when all return codes are zero.

+-----------+----------------------------------------------------------+| BBOMSGC | User ID requirement: Update authority for data set |+-----------+ SYS1.MSGENU and/or SYS1.MSGJPN. || Done: | || | ATTENTION: This is optional unless you require message || | translation. || By: | || | This job sets up MMS to translate messages for WebSphere || | for z/OS. || | || | There are two steps to update SYS1.MSGENU and || | SYS1.MSGJPN. Remove the unneeded step and change the || | target libraries, if necessary. |+-----------+----------------------------------------------------------+| BBOERRLG | User ID requirement: Authority to define a log stream. |+-----------+ || Done: | ATTENTION: If your installation already has a WebSphere || | for z/OS error log stream named the following, skip this || | step. || | || | AZCELL.ERROR.LOG || | || | This job defines the error log stream. || By: | || | The customization dialog supplied the required || | parameters on the define log stream command. Review and || | supply any options you require. For more information, || | see z/OS MVS Setting Up a Sysplex (SA22-7625). || | || | RESULT: Upon successful completion of this job, you will || | see the following message in SYSPRINT: |




| | || | IXG004I LOGR POLICY PROCESSING ENDED WITHOUT ERROR || | |+-----------+----------------------------------------------------------+| BBORRSLS | User ID requirement: Authority to define a log stream. |+-----------+ || Done: | ATTENTION: If your installation already has Resource || | Recovery Services (RRS) active, skip this job. (To check || | if RRS is active, go to SDSF or the operator console and || | look for an address space named "ATRRRS".) || By: | || | This job defines the RRS log streams. || | || | The RRS group name is, by default, the resource sharing || | group name. || | || | RESULT: Upon successful completion of this job, you will || | see the following message in SYSPRINT: || | || | IXG004I LOGR POLICY PROCESSING ENDED WITHOUT ERROR || | |+-----------+----------------------------------------------------------+| BBOWCTR | User ID requirement: Authority to allocate data set |+-----------+ || Done: | SYS1.SYSA.AZCELL.CTRACE || | || | This job allocates the CTRACE data set used by || | || By: | AZCTRW || | || | ATTENTION: Skip this step if the CTRACE data set is || | already allocated. || | |+-----------+----------------------------------------------------------+| BBOCBRAJ | User ID requirement: Authority to update data set |+-----------+ || Done: | WAS502.AZBASEA.DATA || | || | This job builds (but does not execute) the RACF commands || By: | for the WebSphere for z/OS run-time clusters and places || | them into member BBOWBRAK of data set || | || | WAS502.AZBASEA.DATA || | || | Carefully review these definitions with your security || | administrator. |+-----------+----------------------------------------------------------+| BBOCBRAK | User ID requirement: RACF special authority. |+-----------+ || Done: | This job executes the RACF commands set up in the || | previous job. || | || | RESULT: You may receive errors, such as INVALID USER || By: | messages, from this job because a user ID is already || | defined. || | |+-----------+----------------------------------------------------------+| -------- | Check user ID authorizations. |+-----------+ || Done: | Make sure the AZCFG group has read access to all || | WebSphere product data sets, as well as to || | CEE.SCEERUN || | || | Make sure the following user IDs have read access to |




| By: | the resolver configuration file in use on your system. || | Depending on your IP setup, this file may be || | /etc/resolv.conf, SYS1.TCPPARMS(TCPDATA), or another || | data set. || | || | AZACRU || | AZASRU || | || | See the z/OS eNetwork Communication Server IP || | Configuration manual for the resolver search order. || | || | Ensure the following user ID has read access to the data || | sets in your system parmlib concatenation: || | || | AZACRU || | || | ATTENTION: || | || | If operator commands are protected by the z/OS security || | server at your installation, you must ensure that || | sufficient authority is given to WebSphere tasks to || | control operations. || | || | The Application Server Controller user ID (AZACRU), || | the Application Server Servant user id (AZASRU), and || | the Service Daemon user ID (AZACRU) need the ability || | to perform operations on started tasks belonging to || | WebSphere Application Server for z/OS in the same cell || | (or security domain). || | || | The RACF commands to authorize these user IDs are not || | generated by the previous job (BBOCBRAJ). The following || | example commands show what needs to be done, || | substituting your profile names: || | || | PERMIT START_profile_name CLASS(OPERCMDS) || | ID (AZACRU AZASRU AZACRU) || | ACCESS(UPDATE) || | || | PERMIT STOP_profile_name CLASS(OPERCMDS) || | ID (AZACRU AZASRU AZACRU) || | ACCESS(UPDATE) || | || | PERMIT MODIFY_profile_name CLASS(OPERCMDS) || | ID (AZACRU AZASRU AZACRU) || | ACCESS(UPDATE) || | || | PERMIT CANCEL_profile_name CLASS(OPERCMDS) || | ID (AZACRU AZASRU AZACRU) || | ACCESS(UPDATE) || | || | PERMIT FORCE_profile_name CLASS(OPERCMDS) || | ID (AZACRU AZASRU AZACRU) || | ACCESS(UPDATE) || | |+-----------+----------------------------------------------------------+| BBOWCHFS | User ID requirement: UID=0 and authority to allocate |+-----------+ || Done: | OMVS.WAS.AZCELL.CONFIG.HFS || | || | This job: || | || By: | o Creates a mount point directory || | |




| | /wasv5config/azcell || | || | o Allocates the configuration HFS || | || | OMVS.WAS.AZCELL.CONFIG.HFS || | || | and mounts it at the above mount point. || | || | BEFORE YOU BEGIN: The BBOWCHFS job assumes your root HFS || | is mounted in read/write mode. If the root HFS is not in || | read/write mode, manually create the directory || | || | /wasv5config/azcell || | || | and any needed higher directories, set file permissions || | to 775, and set the owning user ID and group to AZADMIN || | and AZCFG before running BBOWCHFS. || | || | EXAMPLE: If you plan to use /WebSphere/V5R0M0 as your || | directory, issue the following commands from within the || | OMVS shell: || | || | mkdir -p -m 775 /WebSphere/V5R0M0 || | chown -R AZADMIN:AZCFG /WebSphere || | |+-----------+----------------------------------------------------------+| BBOMCFG | User ID requirement: UID=0. |+-----------+ || Done: | This job populates the previously-created HFS. || | || | Upon completion, examine the job output. Success is || By: | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| BBOMCFGU | User ID requirement: UID=0. |+-----------+ || Done: | This job configures the runtime HFS to include the || | directory for UDDIReg. || | || By: | Upon completion, examine the job output. Success is || | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| BBOWCPY1 | User ID requirement: update authority for: |+-----------+ || Done: | SYS1.PROCLIB || | || By: | SYS1.PARMLIB || | || | SYSS.WSC.SYSEXEC || | || | ATTENTION: This job modifies SYS1.PROCLIB. Because || | master subsystem address spaces like ATRRRS and BBOWTR || | must have their cataloged procedures in a PROCLIB listed || | in the master scheduler JCL, we copy members to || | SYS1.PROCLIB. You may have a private master subsystem || | PROCLIB to which you want to copy the members. || | || | This job copies the tailored start procedures, || | parameters, and EXECs to the run-time libraries. || | || | ATTENTION: Be aware that you may overlay existing || | members in the above data sets. || | |




+-----------+----------------------------------------------------------+| BBOWCPY2 | User ID requirement: UID=0 or AZADMIN |+-----------+ || Done: | || | This job copies files, such as shell scripts, XML files, || By: | properties and trace data, into the HFS. |+-----------+----------------------------------------------------------+| BBOWC2N | User ID requirement: UID=0 or AZADMIN |+-----------+ || Done: | This step creates the was.env file for the location || | service daemon and the application servers. || | || By: | Upon completion, examine the job output. Success is || | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| BBOWIAPP | User ID requirement: UID=0 or AZADMIN |+-----------+ || Done: | This job installs the administrative console and || | the IVT application. || | || By: | Upon completion, examine the job output. Success is || | indicated by the following messages: || | || | ADMA5013I: Application adminconsole installed || | successfully. || | ADMA5013I: Application ivtApp installed successfully. |+-----------+----------------------------------------------------------+| BBOMCFG2 | User ID requirement: UID=0. |+-----------+ || Done: | This job will complete the HFS initialization. || | || | Upon completion, examine the job output. Success is || By: | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| -------- | If Resource Recovery Services (RRS) is not active, issue |+-----------+ the following MVS command. (To check if RRS is active, || Done: | go to SDSF or the operator console and see if "RRS" is || | listed as active.) || | || By: | START ATRRRS,SUB=MSTR || | || | Note: You know you were successful if the following || | appears in the SYSLOG: || | || | ASA2011I RRS INITIALIZATION COMPLETE. COMPONENT || | ID=SCRRS |+-----------+----------------------------------------------------------+| -------- | Issue the MVS command: |+-----------+ || Done: | TRACE CT,WTRSTART=AZCTRW || | || | This command starts the CTRACE writer used by WebSphere || By: | for z/OS. || | || | RESULT: Check the SYSLOG for the following: || | || | ITT110T INITIALIZATION OF CTRACE WRITER COMPLETE. || | |+-----------+----------------------------------------------------------+| -------- | User ID requirement: UID=0. |+-----------+ || Done: | ATTENTION: This step is optional unless you make use of |




| | full function MQ in combination with WebSphere for z/OS || By: | or you plan to install the integral JMS provider. || | || | Set authorization bits for the following MQ files: || | || | /usr/lpp/mqm/V5R3M1 || | /java/lib/libwmqjbind.so || | /libwmqjbatch.so || | /libwmqjrrs.so || | || | Running in a UNIX System Services shell, invoke the || | following commands (each are all on one line): || | || | extattr +a || | /usr/lpp/mqm/V5R3M1 || | /java/lib/libwmqjbind.so || | || | extattr +a || | /usr/lpp/mqm/V5R3M1 || | /java/lib/libwmqjbatch.so || | || | extattr +a || | /usr/lpp/mqm/V5R3M1 || | /java/lib/libwmqjrrs.so || | || | Note: You may need to reset these attributes for any || | future MQ service upgrades. || | |+-----------+----------------------------------------------------------+| -------- | Start the Application Server |+-----------+ || Done: | Issue the MVS command || | || | START AZACR,JOBNAME=AZSR01A, || | ENV=AZCELLA.AZNODEA.AZSR01A || | || By: | This command starts the Application Server. Wait until || | the server is finished initializing before proceeding. || | || | RESULT: The following message appears on the console and || | in the job log of || | || | AZACR || | || | BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR || | z/OS CONTROL PROCESS AZSR01A || | |+-----------+----------------------------------------------------------+| BBOWIVT | User ID requirement: Any user ID |+-----------+ || Done: | This job runs the IVT application. See related topics in || | the WebSphere for z/OS Information Center for information|| | about how to run this job. || By: | |+-----------+----------------------------------------------------------+| The product is now configured and verified. || || To start the application server, issue the MVS command: || || START AZACR,JOBNAME=AZSR01A, || ENV=AZCELLA.AZNODEA.AZSR01A || || To stop the application server, enter the MVS command: || |




| STOP AZDEMN1 |+----------------------------------------------------------------------+

Use the following jobs to configure samples and then deletethese samples from a server. The information is provided forreference purposes only.

+-----------+----------------------------------------------------------+| BBODEFR | User ID requirement: AZADMIN |+-----------+ || Done: | This job defines the resources needed for the || | technology samples. || | || | You must stop the application server in order to run || By: | this job. |+-----------+----------------------------------------------------------+| BBOINST | User ID requirement: AZADMIN |+-----------+ || Done: | This job installs the technology samples. || | || | You must stop the application server in order to run || By: | this job. |+-----------+----------------------------------------------------------+| BBOUNIN | User ID requirement: AZADMIN |+-----------+ || Done: | This job uninstalls the technology samples. || | || | You must stop the application server in order to run || By: | this job. |+-----------+----------------------------------------------------------+| --------- | User ID requirement: AZADMIN |+-----------+ || Done: | To reset the sample EARs to their original state, log on || | to the OMVS shell under AZADMIN and run the following || | sample shell script: || | || By: | /wasv5config/azcell || | /AppServerNodeA || | /bin/samples_reset.sh || | |+-----------+----------------------------------------------------------+

The following is a useful script that helps you define securitycontrols for clusters. It is in data set

'WAS502.AZBASEA.DATA'

+-----------+----------------------------------------------------------+| BBOWBRAC | This is a sample exec you can modify to include |+-----------+ installation-specific RACF controls. This exec defines || Done: | all the user IDs and groups that are necessary and || | sufficient for installing WebSphere for z/OS. || | || By: | Additionally, there are commented sections for other || | components that might be used (SSL, for example). |+-----------+----------------------------------------------------------+




Appendix B - Customized RACF profile used for this configurationThe following RACF commands originally came from the running the BBOCBRAJ job for the BaseApplication Server on SYSA. The commands came out of the BBOCBRAK members in the DATAdata set. As was explained back in "How the RACF profiles are created" on page 9, we did notwant to use the commands generated by BBOCBRAJ. Why not? Because they were too specific,and didn't allow us to use the same profiles for many different servers.

What about the Security Domain RACF commands? We allowed those to be what were generatedby the customization dialog. Those variables are cell-wide values, not specific to a given server.Rather than modify those, we simpy ran the job BBOSBRAK based on the RACF commands thatcame out of the ISPF customization.

Note:

So we took the output from BBOCBRAJ (the BBOWBRAK member) and modified it. What's includedhere is the modified script used to create the profiles used for the AZCELL configuration.

"Note" boxes like this have been inserted into the RACF commands to explain key things about themodifications made.

Note:

/* REXX *//* * Activate the classes that we are going to rely upon up front. */ "SETROPTS CLASSACT(CBIND)""SETROPTS RACLIST(CBIND) GENERIC(CBIND)""SETROPTS CLASSACT(SERVER)""SETROPTS RACLIST(SERVER) GENERIC(SERVER)""SETROPTS CLASSACT(STARTED)""SETROPTS RACLIST(STARTED) GENERIC(STARTED)""SETROPTS CLASSACT(FACILITY)""SETROPTS RACLIST(FACILITY) GENERIC(FACILITY)""SETROPTS CLASSACT(LOGSTRM)""SETROPTS GRPLIST""SETROPTS GRPLIST"/* * Add the userids to their default groups */

The user names are the generated values, which came from the ISPF panels. The generated UIDvalues inside the OMVS() parenthesis was overwritten with the string AUTOUID -- that's whatautomatically generates the UID values. The group values (AZCFG, AZSRVRG) were created whenthe Security Domain BBOSBRAK job was run.

Note:

"ADDUSER AZACRU DFLTGRP(AZCFG) OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin" || ,"/sh)) NAME('WAS DAEMON CR') NOPASSWORD NOOIDCARD""ADDUSER AZASRU DFLTGRP(AZSRVRG) OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/" || ,"sh)) NAME('WAS APPSVR SR') NOPASSWORD NOOIDCARD"

No changes were made to the following commands.Note:

"RDEFINE LOGSTRM AZCELL.ERROR.LOG UACC(READ)""PERMIT AZCELL.ERROR.LOG CLASS(LOGSTRM) ID(AZCFG) ACCESS(UPDATE)"/* * Setup a CBIND profile for all servers in AZCELL */


Section: Appendix B - Custom RACF ScriptVersion Date: Tuesday, March 09, 2004- 107 -© 2003, IBM Americas Advanced Technical Support


By default the CBIND profiles will have a format of CB.BIND.<WLM applenv>. But that makes theprofile specific to a given cluster. (Recall that by design every server is considered to be a memberof a cluster, and the cluster name is equal to the WLM application environment for the cluster. See"Application servers are considered to be a member of a cluster" on page 20.) To make the CBINDprofiles more generic, the third element of the profile was changed from AZSR01 -- the WLMapplication environment name provided on the ISPF panels -- to AZ*. The profile is thereforeapplicable to every server (and cluster) in this configuration.

Note:

"RDEFINE CBIND CB.BIND.* UACC(NONE)""RDEFINE CBIND CB.BIND.AZ* UACC(READ)""PERMIT CB.BIND.AZ* CLASS(CBIND) ID(AZCFG) ACCESS(CONTROL) ""RDEFINE CBIND CB.* UACC(NONE)""RDEFINE CBIND CB.AZ* UACC(READ)""SETROPTS RACLIST(CBIND) GENERIC(CBIND) REFRESH"/* * Define server class profiles for all servants in the AZCELL */

By default the SERVER profiles will have a format of CB.*.<WLM applenv>. Just like the CBINDprofile, that was too specific for what we were trying to accomplish. So just like the CBIND profiles,the value AZSR01 was changed to AZ* to make the profiles apply to all servers in the configuration.

Note:

"RDEFINE SERVER CB.* UACC(NONE)""RDEFINE SERVER CB.*.AZ* UACC(NONE)""PERMIT CB.*.AZ* CLASS(SERVER) ID(AZCFG) ACC(READ)""RDEFINE SERVER CB.*.AZ*.* UACC(NONE)""PERMIT CB.*.AZ*.* CLASS(SERVER) ID(AZCFG) ACC(READ)""SETROPTS RACLIST(SERVER) GENERIC(SERVER) REFRESH"/* * Associate the correct userid to all started tasks. */

Some of the STARTED profiles were modified to make them more generic:AZDMN*.* -- modified from original AZDMN.* , but probably not necessary since JCL AZDMNused for all daemons.AZACR.* -- not modified; all controllers use AZACR proc, so this is fine as is.AZSR*.* -- modified from the original AZSR01AS.*, which is very specific to the first server'sJOBNAME value. Changing this to AZSR*.* made it apply to all servers in this configuration, sinceall will start with the string AZSR.AZDMGRS.* -- this was manually added to take care of the Deployment Manager when it wasconfigured later. We knew the Deployment Manager's controller would be started with the AZACRproc, so the STARTED profile AZACR.* was fine for it. We knew also that the DeploymentManager's servant would have a JOBNAME of AZDMGRS (servants are started by WLM and theSTARTED profile is based on the JOBNAME value). So we add this line to handle the DeploymentManager's servant, even though at the time we executed this script -- prior to the first BaseApplication Server node -- the Deployment Manager hadn't yet been configured.AZCTRW*.* -- made slightly more generic by adding the * before the dot.

Note:

"RDEFINE STARTED AZDMN*.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))""RDEFINE STARTED AZACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))""RDEFINE STARTED AZSR*.* STDATA(USER(AZASRU) GROUP(AZCFG) TRACE(YES))""RDEFINE STARTED AZDMGRS.* STDATA(USER(AZASRU) GROUP(AZCFG) TRACE(YES))""RDEFINE STARTED AZCTRW*.* STDATA(USER(STCRACF) GROUP(SYS1) TRACE(YES))""SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH"


Section: Appendix B - Custom RACF ScriptVersion Date: Tuesday, March 09, 2004- 108 -© 2003, IBM Americas Advanced Technical Support


Appendix C - BBOCCINS for Deployment Manager on SYSAWhat follows is the actual BBOCCINS member created for the Deployment Manager on SYSA:

-----------------------------------------------Instructions for customizing WebSphere for z/OSfor a Deployment Manager node.


RULES:



3. You must first complete the customization of a base application server before starting these instructions.

4. This set of instructions assumes that you are configuring the Deployment Manager using the same data sets you used for the application server. It further assumes use of the same PROCLIB and PARMLIB. If your installation is configured differently, you need to make accommodations for such differences (such as separate SYS1.PROCLIB data sets on different systems).

Doing manual configuration updates----------------------------------

The customization dialog for WebSphere for z/OS does not attempt toupdate configuration data for your base operating system or existingsubsystems. You must do the following manual steps prior to runningthe WebSphere for z/OS configuration jobs.

BEFORE YOU BEGIN: You must copy the target data sets (*.CNTL and*.DATA) to your target system and give them the same data set names.

You must be running on your target system.

Perform these steps to do manual configuration updates:

1. Update the workload management application environment as follows.

ATTENTION: If you have already installed the WLM-DAE support PTF (APAR OW54622, on z/OS 1.2 or higher), you may skip this step.

Using these parameters, run IWMARIN0 to create the AZDMGR application environment:

Appl Environment Name AZDMGR Description WebSphere for z/OS V5 servant Subsystem type CB Procedure name AZASR Start parameters JOBNAME=&IWMSSNM.S, ENV=AZCELL.AZDM.&IWMSSNM Limit on starting server address spaces for a subsystem instance: 2. Single address space per system

NOTE: For the start parameter string, you must continue typing with


Section: Appendix C - BBOCCINS InstructionsVersion Date: Tuesday, March 09, 2004- 109 -© 2003, IBM Americas Advanced Technical Support


ENV on the same line as JOBNAME. We show the parameters on separate lines for aesthetics only.

For information about IWMARIN0, the ISPF dialog application for MVS workload management, see OS/390 MVS Planning: Workload Management (GC28-1761) or z/OS MVS Planning: Workload Management (SA22-7602).

For more information about workload management and WebSphere for z/OS, see related topics in the WebSphere for z/OS Information Center at http://www.ibm.com/software/webservers/appserv/zos_os390/library/.

-------------------------------------------------------------------

2. Update your active BPXPRMxx member to have the following WebSphere for z/OS configuration HFS:

OMVS.WAS.AZCELL.CONFIG.HFS

mounted at:

/wasv5config/azcell

in read/write mode.

EXAMPLE:

MOUNT FILESYSTEM('OMVS.WAS.AZCELL.CONFIG.HFS') MOUNTPOINT('/wasv5config/azcell') TYPE(HFS) MODE(RDWR)

ATTENTION: Skip this step if this HFS is already in BPXPRMxx.

-------------------------------------------------------------------


SOAP JMX Connector port - 9510 CELL DISCOVERY ADDRESS port - 9514 ORB port - 9512 ORB SSL port - 9513 HTTP port - 9518 HTTP SSL port - 9519 Daemon IP port - 9500 Daemon SSL port - 9501

View member BBOTCPID in

'WAS502.AZDMGR.CNTL'


ATTENTION: If another application has already reserved any of these ports for its own use, you must resolve the resulting conflict before you continue. If you update the WebSphere for z/OS customization dialog with new port specifications, be sure to regenerate the customization jobs, data, and instuctions.

-------------------------------------------------------------------




4. WebSphere for z/OS regions open a large number of files (more than 1024). Make sure your BPXPRMxx parmlib member(s) specify a value of MAXFILEPROC that is greater than or equal to 2000. Use the following MVS console command to see your current MAXFILEPROC setting:

D OMVS,OPTIONS

-------------------------------------------------------------------

5. Grant AZACRU read access to SYS1.PARMLIB and any other parmlibs that precede SYS1.PARMLIB in the parmlib concatenation of the LOADzz member in IPLPARM. Use the D IPLINFO command to determine which LOADzz member is current and where it resides.

-------------------------------------------------------------------

Running the customized jobs---------------------------

The customization dialog built a number of batch jobs with thevariables you supplied. You must run the jobs in the order listedbelow using user IDs with the appropriate authority.

BEFORE YOU BEGIN: Complete the section above entitled "Doing manualconfiguration updates."

Follow the table below, which lists in order the jobs you must submitand the commands you must enter. Special handling notes are includedin the table. All jobs are members of

WAS502.AZDMGR.CNTL

Attention: After submitting each job, carefully check the output.Errors may exist even when all return codes are zero.

+-----------+----------------------------------------------------------+| BBODBRAJ | User ID requirement: Authority to update data set |+-----------+ || Done: | WAS502.AZDMGR.DATA || | || | This job builds (but does not execute) the RACF commands || | for the WebSphere for z/OS run-time clusters and places || By: | them into member BBOWBRAK of data set || | || | WAS502.AZDMGR.DATA || | || | Carefully review these definitions with your security || | administrator. |+-----------+----------------------------------------------------------+| BBODBRAK | User ID requirement: RACF special authority. |+-----------+ || Done: | This job executes the RACF commands set up in the || | previous job. || | || | RESULT: You may receive errors, such as INVALID USER || By: | messages, from this job because a user ID is already || | defined. || | || | ATTENTION: |




| | || | If operator commands are protected by the z/OS security || | server at your installation, you must ensure that || | sufficient authority is given to WebSphere tasks to || | control operations. || | || | The Deployment Manager Location Service Daemon user ID, || | (AZACRU), the Deployment Manager Controller user || | ID (AZACRU), and the Deployment Manager Servant user || | ID (AZASRU) need the ability to perform operations on || | started tasks belonging to WebSphere Application Server || | for z/OS in the same cell (or security domain). || | || | The RACF commands to authorize these user IDs are not || | generated by the previous job (BBODBRAJ). The following || | example commands show what needs to be done, || | substituting your profile names: || | || | PERMIT START_profile_name CLASS(OPERCMDS) || | ID(AZACRU AZACRU AZASRU) || | ACC(UPDATE) || | || | PERMIT STOP_profile_name CLASS(OPERCMDS) || | ID(AZACRU AZACRU AZASRU) || | ACC(UPDATE) || | || | PERMIT MODIFY_profile_name CLASS(OPERCMDS) || | ID(AZACRU AZACRU AZASRU) || | ACC(UPDATE) || | || | PERMIT CANCEL_profile_name CLASS(OPERCMDS) || | ID(AZACRU AZACRU AZASRU) || | ACC(UPDATE) || | || | PERMIT FORCE_profile_name CLASS(OPERCMDS) || | ID(AZACRU AZACRU AZASRU) || | ACC(UPDATE) || | |+-----------+----------------------------------------------------------+| BBODCHFS | User ID requirement: UID=0 and authority to allocate |+-----------+ || Done: | OMVS.WAS.AZCELL.CONFIG.HFS || | || | ATTENTION: Skip this step if the mount point is already || | created, such as for the application server. || | || By: | This job: || | || | o Creates a mount point directory || | || | /wasv5config/azcell || | || | o Allocates the configuration HFS || | || | OMVS.WAS.AZCELL.CONFIG.HFS || | || | and mounts it at the above mount point. || | || | BEFORE YOU BEGIN: The BBODCHFS job assumes your root HFS || | is mounted in read/write mode. If the root HFS is not in || | read/write mode, manually create the directory || | || | /wasv5config/azcell || | |




| | and any needed higher directories. Set file permissions || | to 775 and set the owning user ID and group to AZADMIN || | and AZCFG before running BBODCHFS. || | || | EXAMPLE: If you plan to use /WebSphere/V5R0M0 as your || | directory, issue the following commands from within the || | OMVS shell: || | || | mkdir -p -m 775 /WebSphere/V5R0M0 || | chown -R AZADMIN:AZCFG /WebSphere || | |+-----------+----------------------------------------------------------+| BBODCFG | User ID requirement: UID=0. |+-----------+ || Done: | This job populates the previously-created HFS. || | || | Upon completion, examine the job output. Success is || By: | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| BBOMCFGU | User ID requirement: UID=0. |+-----------+ || Done: | This job configures the runtime HFS to include the || | directory for UDDIReg. || | || By: | Upon completion, examine the job output. Success is || | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| BBODCPY1 | User ID requirement: update authority for: |+-----------+ || Done: | SYS1.PROCLIB || | || By: | SYS1.PARMLIB || | || | SYSS.WSC.SYSEXEC || | || | ATTENTION: This job modifies SYS1.PROCLIB. Because || | master subsystem address spaces like ATRRRS and BBOWTR || | must have their cataloged procedures in a PROCLIB listed || | in the master scheduler JCL, we copy members to || | SYS1.PROCLIB. You may have a private master subsystem || | PROCLIB to which you want to copy the members. || | || | This job copies the tailored start procedures, || | parameters, and EXECs to the run-time libraries. || | || | ATTENTION: Be aware that you may overlay existing || | members in the above data sets. || | |+-----------+----------------------------------------------------------+| BBODCPY2 | User ID requirement: UID=0. |+-----------+ || Done: | This job copies files, such as shell scripts, XML files, || | properties and trace data, into the HFS. || By: | |+-----------+----------------------------------------------------------+| BBODC2N | User ID requirement: UID=0 or AZADMIN |+-----------+ || Done: | This step creates the was.env file for the location || | service daemon and the Deployment Manager. || | || By: | Upon completion, examine the job output. Success is || | indicated with a RC=0 in the job output. |




| | |+-----------+----------------------------------------------------------+| BBODIAPP | User ID requirement: UID=0 or AZADMIN |+-----------+ || Done: | This job installs the administrative console and || | the filetransfer application. || | || By: | Upon completion, examine the job output. Success is || | indicated by the following messages: || | || | ADMA5013I: Application adminconsole installed || | successfully. || | ADMA5013I: Application filetransfer installed || | successfully. |+-----------+----------------------------------------------------------+| BBODCFG2 | User ID requirement: UID=0. |+-----------+ || Done: | This job will complete the HFS initialization. || | || | Upon completion, examine the job output. Success is || By: | indicated with a RC=0 in the job output. || | |+-----------+----------------------------------------------------------+| -------- | If Resource Recovery Services (RRS) is not active, issue |+-----------+ the following MVS command. (To check if RRS is active, || Done: | go to SDSF or the operator console and see if "RRS" is || | listed as active.) || | || By: | START ATRRRS,SUB=MSTR || | || | Note: You know you were successful if the following || | appears in the SYSLOG: || | || | ASA2011I RRS INITIALIZATION COMPLETE. COMPONENT || | ID=SCRRS |+-----------+----------------------------------------------------------+| -------- | Start the Deployment Manager. |+-----------+ || Done: | Issue the MVS command || | || | START AZACR,JOBNAME=AZDMGR, || | ENV=AZCELL.AZDM.AZDMGR || | || By: | This command starts the Deployment Manager and also || | starts the location service daemon. Wait until the || | server is finished initializing before proceeding. || | || | RESULT: The following message appears on the console and || | in the job log of AZACR || | || | BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR || | z/OS CONTROL PROCESS AZDMGR || | |+-----------+----------------------------------------------------------+| || The product is now configured for a Deployment Manager. || |+-----------+----------------------------------------------------------+

Note: If you want to federate one or more base application servernodes, you need to run option 4 of the dialog: Federate BaseApplication Server node.

+-----------+----------------------------------------------------------+




| To start the Deployment Manager, node agent, and application server, || issue the following MVS commands: || || START AZACR,JOBNAME=AZDMGR, || ENV=AZCELL.AZDM.AZDMGR || || START AZACR,JOBNAME=BBON001, || ENV=AZCELL.AZNODEA.BBON001 || || START AZACR,JOBNAME=AZSR01A, || ENV=AZCELLA.AZNODEA.AZSR01A || || To stop the WebSphere for z/OS servers, enter the MVS command: || || STOP AZDEMN || |+----------------------------------------------------------------------+

The following is a useful script that helps you define securitycontrols. It is in data set

'WAS502.AZDMGR.DATA'

+-----------+----------------------------------------------------------+| BBODBRAC | This is a sample exec that you may modify to include |+-----------+ installation-specific RACF controls. This exec defines || Done: | all the user IDs and groups that are necessary and || | sufficient for installing WebSphere for z/OS. || | || By: | Additionally, there are commented sections for other || | components that might be used (SSL, for example). |+-----------+----------------------------------------------------------+




Appendix D - BBOANINS for Federation of Node into DM on SYSA-----------------------------------------------Instructions for customizing WebSphere for z/OSfor Federate Base Application Server node.


RULES:




SOAP JMX Connector port - 9520 Node Discovery port - 9524 Node Agent's ORB port - 9522 Node Agent's ORB SSL port - 9523 Base Server's ORB port - 9542

View member BBOTCPIA in

'WAS502.AZFEDA.CNTL'.


Note: The addNode process introduces a special utility server to the node. This utility server is called a nodeagent and exists to support administrative functions on the node. By default the nodeagent takes over ORB port 2809. Note on WebSphere z/OS the ORB port doubles as the INS CosNaming bootstrap port. By default, this port (2809) was assigned to the base server. Normally you want the nodeagent to be the INS CosNaming bootstrap point for the entire node, so that RMI/IIOP clients that do not override the INS CosNaming bootstrap defaults can locate within the namespace, EJBs installed on any server on that node. In order for the nodeagent to take over port 2809, the base server must be assigned a new ORB port. The default new ORB port for the base server is 9810. The nodeagent will take over a base server's ORB port if and only if the nodeagent's ORB port is equal to a base server's ORB port. You can specify the nodeagent's ORB port in the 'ORB port' field. You can specify the new ORB port for the base server in the 'Base Server ORB Port' field.

ATTENTION: Skip this step if the ports are already defined in the TCP/IP profile.

4. You must first complete the customization of a base application server and the customization of a deployment manager server before starting these instructions. Also, ensure that the deployment manager server is started before starting these instructions.


Section: Appendix D - BBOANINS InstructionsVersion Date: Tuesday, March 09, 2004- 116 -© 2003, IBM Americas Advanced Technical Support


+-----------+----------------------------------------------------------+| BBOWADDN | User ID requirement: AZADMIN |+-----------+ || Done: | Add the application server(s) associated with the base || | application server node to the deployment manager's || | cell. || By: | || | ATTENTION: Before you run this job (BBOWADDN) to || | federate the Base AppServer Node, you must have started || | the Base AppServer that you are federating at least once || | so the applyPTF step runs. Otherwise, the BBOWADDN job || | will fail with an error such as: || | java.lang.NullPointerException at || | com.ibm.ws.management.tools.NodeFederationUtility || | .createNDProductFile(NodeFederationUtility.java:1929)|| | || | Note: Run this job only once for each node that you || | federate, regardless of how many application servers the || | node contains. || | || | RESULT: Upon successful completion of this job, you will || | see the following message in SYSPRINT: || | || | ADMU0003I: Node <nodename> has been successfully || | federated. || | |+-----------+----------------------------------------------------------+| -------- | Update the application server's WLM application |+-----------+ environment. || Done: | || | ATTENTION: If you have already installed the WLM DAE || | APAR (APAR OW54622, available on z/OS 1.2 or higher), || By: | you may skip this step. || | || | If you do not have this WLM DAE APAR, you will need to || | update your static WLM definitions for the application || | server(s) on the base application server node you just || | federated into a Network Deployment cell. This is || | because the WLM APPLENV definitions for each server || | includes a reference to the server's cell short name in || | the ENV parameter that is part of the start parameters || | in APPLENV definition. The ENV parameter is encoded as || | follows: || | || | ENV=<CellShortName>.<NodeShortName>.<ServerShortName> || | || | After federating a base application server node into a || | Network Deployment cell, the cell identity of the base || | application server(s) changes from whatever it was to || | the cell identity of the Network Deployment cell. || | This means you have to update the ENV parameter in || | the WLM APPLENV definition(s) for the server(s) on the || | newly federated node. || | || | To obtain the name(s) of the WLM application || | environments to be changed, access the WebSphere || | adminconsole application running on the || | deployment manager node by pointing a Web browser || | to the following address: || | || | http://wsc1.washington.ibm.com: || | 9518/admin || | |




| | Select Servers, then Application Servers. For each || | application server, click on the server name, then || | scroll down to find the application server "short Name". || | Find and select the server's "Custom Properties". In || | the Custom Properties list, you will find a property || | named 'ClusterTransitionName', which is also the || | server's WLM application environment. Use the IWMARIN0 || | application under TSO to modify these WLM application || | environment(s) so that the ENV= field begins with the || | deployment manager cell name AZCELL instead of the || | base server cell name. Install and apply the updated || | WLM service definition before continuing. || | || | |+-----------+----------------------------------------------------------+| -------- | Start the node agent server (optional) |+-----------+ || | If your Application Server node name (short) || | is NODENAME, issue the MVS command || Done: | || | START AZACR,JOBNAME=AZAGNTA, || By: | ENV=AZCELL.NODENAME.AZAGNTA |

See how the node component of the ENV= string is shown as NODENAME? That's because theSAVECFG from the Deployment Manager may not necessarily have the original node name of theBase Application server. Rather than guess, the process simply puts NODENAME as a placeholder.

Note:

| | || | This command starts the node agent server. || | || | RESULT: The following message appears on the console and || | in the job log of AZAGNTA. || | || | BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR || | z/OS CONTROL PROCESS AZAGNTA. || | |+-----------+----------------------------------------------------------+| -------- | Start the JMS Server |+-----------+ || Done: | Note: If your server is configured for IJP, this step is || | required. Otherwise, you may skip this step. || | || | If your Application Server node name (short) || | is NODENAME, issue the MVS command || By: | || | START AZACR,JOBNAME=BBOJ001, || | ENV=AZCELL.NODENAME.BBOJ001 |

Same as previous "Note" box.Note:| | || | RESULT: The following message appears on the console and || | in the job log of || | || | BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR || | z/OS CONTROL PROCESS BBOJ001. || | |+-----------+----------------------------------------------------------+| -------- | Start the Application Server (optional) |+-----------+ || Done: | Note: You must start the node agent before you start the || | Application Server. || | || | For example, if your server short name is BBOS001, || | and your Application Server node name (short) is |




| | NODENAME, issue the MVS command || By: | || | START AZACR,JOBNAME=BBOS001, || | ENV=AZCELL.NODENAME.BBOS001 |

Here the application server name is shown as BBOS001, which is the default value. The actualapplication server name was still AZSR01A, but the federation process didn't know that. TheDMGR's SAVECFG was loaded, not the BaseApp's SAVECFG. Use the START string you know to becorrect rather than relying what's in this member.

Note:

| | || | This command starts the Application Server. || | || | RESULT: The following message appears on the console and || | in the job log of BBOS001. || | || | BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR || | z/OS CONTROL PROCESS BBOS001 || | |+-----------+----------------------------------------------------------+




Appendix E - MiscellaneousThis section is used to offer explanations of things that are of interest, but that explaining in-linewith the configuration information wasn't critical.

The applyPTF.sh process

Starting with W501000, the JCL start procedures created by the ISPF customization dialogscontain a STEP that runs a shell script called applyPTF.sh. The reason why applyPTF.shwas introduced was to provide a way to apply maintenance to the configuration HFS.

Relationship between Config HFS and Code HFS

The relationship between the "Config HFS" and the "Code HFS" bears repeating:

SYSA

AZAGNTA

CR

AZDMGR

CR SR

AZSR01A

CR SR

AZDEMN

CR

/wasv5config/azcellHFS/AppServerNodeA

/bin

HFS /usr/lpp/zWebSphere/V5R0M0

/bin

Symbolic Links

"Config HFS"

"Code HFS"

Relationship between "Config HFS" and "Code HFS"

A configuration has access only to its Config HFS. Symbolic links in the Config HFSprovide access to the code in the "Code HFS," otherwise known as the "WebSphereSMP/E Home Directory."

Key Point:

SMP/E maintenance applied to Code HFS, not Config HFS

Maintenance released by IBM is applied to the code libraries (PDS data sets) as well as the"Code HFS" (the "WebSphere SMP/E Home Directory). The SMP/E process does notapply the maintenance against the "Config HFS." Why not? Because there's no limit to thenumber of Config HFS's that link to the Code HFS:

/<Config 1>HFS

HFS /usr/lpp/zWebSphere/V5R0M0

"Config HFS"

"Code HFS"

/<Config 2>HFS /<Config N>HFS

SymLinks SymLinks SymLinks

SMP/E

???Config HFS

Many different Config HFS structures ... which ones should SMP/E apply maintenance against?


Section: Appendix E - Miscellaneous Version Date: Tuesday, March 09, 2004- 120 -© 2003, IBM Americas Advanced Technical Support


Maintenance to Config HFS necessary

Maintenance provides not only fixes to existing files, it also is a way to introduce new files.And since the primary way the Config HFS accesses the Code HFS is through symboliclinks, the ability to introduce a new file (symbolic link) to the Config HFS is critical tointroducing new function to the product.

Prior to the applyPTF.sh process, updates to the Config HFS were done manually,through ++HOLD instructions of the PTF. This was time consuming, prone to human error,and was sometimes overlooked.

What applyPTF.sh does

The applyPTF.sh is run every time a server controller starts up. It checks the level of theConfig HFS against the level of the Code HFS. If the two are at the same maintenancelevel, the server is started. If the Config HFS is at a lower level than the Code HFS, thenapplyPTF.sh performs the changes to the Config HFS specified by the maintenance levelof the Code HFS and then starts the server. If the Config HFS is at a level higher than theCode HFS, as might be the case if maintenance is backed off, the server is not allowed tostart.

Check Config HFS vs. Code HFS

StartStart

Server

Config at lower level than Code

Config at HIGHER LEVEL than Code

Config = Code

Update Config HFS according to instructions

found in Code HFS

Stop Server

Flowchart of applyPTF.sh processing

Maintenance places instruction files in Code HFS

When SMP/E maintenance is applied against a WebSphere for z/OS Version 5 Code HFS,files are placed in that HFS that provide information to the applyPTF.sh process. Thoseinstructions tell the applyPTF.sh process what updates to the Config HFS are necessary.When a server is started, and applyPTF.sh is run, it checks these files in the Code HFSand if updates are necessary, then applyPTF.sh performs those updates as directed to bythe instructions.

This is what solves the problem of manual ++HOLD updates.

When Code HFS is lower level than Config HFS

This would be the case if the Code HFS was backed down to a previous maintenance level.The applyPTF.sh process would still be invoked by the controller JCL, and it would seethat the Code HFS was at a lower level than the Config HFS. The server would not bepermitted to start.

To correct this, it is necessary to "back out" the PTF from the Config HFS prior to droppingthe Code HFS to a lower level. This is done by running the backoutPTF.sh shell script,which is found in the /AppServer/bin directory.

backoutPTF.sh must be run before Code HFS is dropped back to lower level.Key Point:




The reason for this "key point" is this: the backoutPTF.sh shell script needs to see whatthings to back out of the Config HFS. The only way it can know this is by reading theupdate instructions of the maintenance level being backed out. So the Code HFS with themaintenance being backed out has to be available to backoutPTF.sh. Once the ConfigHFS has been backed out to the lower maintenance, then you can drop the Code HFS backas well.

Why WLM Dynamic Application Environments helps in configuring horizontal clusters

If you want to configure a horizontal cluster, having WLM Dynamic Application Environments(DAE) enabled makes things considerably easier. To understand why, recall that a horizontalcluster is defined as consisting of servers on different nodes on different MVS images:

MVS System or LPAR MVS System or LPAR

DM

CR SRA

Server_A

CR SR

Node Agent

CR

Daemon

CR

Server_B

CR SR

Node Agent

CR

Daemon

CR

Server_C

CR SR

Server_D

CR SRCluster

Horizontal cluster: different nodes, different MVS images

Clusters and WLM application environment names

We start with a key fact about WLM application environment names and WebSphereclusters:

All members (servers) in a cluster use the same WLM application environment name.Key Fact:

The reason why horizontal clusters require Dynamic Application Environments is becausethe WLM application environment definition for two members of the cluster will be containdifferent information. Same WLM application environment name, different information.Static WLM application environments have some trouble handling this; Dynamic WLMapplication environments can handle it quite easily.

Horizontal clusters and JCL start procedure names

The first piece of information that may be different between members of a horizontal clusteris the JCL start procedure name. If you're using the same JCL start procedure for allmembers of a cluster -- and this is possible if you're using shared HFS and a commonconfiguration root -- then this reason for DAE goes away. But if you're not using sharedHFS, and the SET ROOT= value in one cluster member's JCL is different from anothercluster member's, that implies separate JCL. That then would require DAE since the sameWLM application environment name would need to contain JCL "X" for one member andJCL "Y" for another member. Static WLM can't do this.

You may or may not be using different JCL start procedure names. But your two clustermembers will definitely have different node values in the ENV= string. That's next.




Horizontal clusters and node names in the ENV= string

We just saw that separate JCL start procedures for different members in a cluster would byrequire DAE. But what if the same JCL was being used for all cluster members? If that wasthe case, then it would imply passing an ENV= string on the START command to the sameJCL could be used to start different servers.

Recall the format of the START command when the ENV= parameter is present:START JOBNAME=<jobname>,ENV=<cell_short>.<node_short>.<server_short>

Recall our picture of a horizontal cluster, and take note of the different <node_short>values that would be required:

MVS System or LPAR MVS System or LPAR

DM

CR SRA

Server_A

CR SR

Node Agent

CR

Daemon

CR

Server_B

CR SR

Node Agent

CR

Daemon

CR

Server_C

CR SR

Server_D

CR SRCluster

Node Short: NODEA

Node Short: NODEB

Different nodes implies different <node_short> value in ENV= string

So we see that cluster member Server_C in this example would require an ENV= stringwith a node short name of NODEA, while cluster member Server_D would require an ENV=string with a different node short name of NODEB. Static WLM application environmentswould require a symbolic variable to handle this. One such variable is &SYSNAME. Thatmeans that your node names must be configured to equal your system name, and the staticWLM definition would then containt he following start parameters:

JOBNAME=&IWMSSNM.S,ENV=<cell_short>.&SYSNAME..&IWMSSNM

The JCL start procedure name must still be common across all cluster members.Note:

Dynamic Application Environments (DAE) to the rescue

The key to understanding how DAE addresses this is to understand the following:

Every WebSphere for z/OS Version 5 server maintains within its configuration file(was.env) information used to create the dynamic application environment: the nameof the dynamic application environment, the JCL start procedure name and the ENV=string to use.

WebSphere for z/OS Version 5 creates these dynamic application environments on thefly, at the time they're needed.

And here's the key:




WLM keeps dynamic application environments separate per system. So you can havean environment name of XYZ on SYSA with completely different information than thesame environment name -- XYZ -- on SYSB.

That's why WLM Dynamic Application Environments make configuring horizontal clustersmuch easier.

What about vertical clusters?

You can get by with static WLM application environments only if all the cluster membersreside on the same node on the same MVS image and they all use the same JCL startprocedure.

If for whatever reason they use different JCL start procedures, then you'd have to use DAE.

And if you have two application server nodes in a cell on a single MVS image (somethingwe ruled out for the AZCELL, see "Allow no more than one node per system in the cell" onpage 20), and you attempt to cluster across those two nodes, then even DAE can't helpyou. That configuration -- two separate nodes, same MVS image, same cell -- won't workwith static WLM (even using &SYSNAME in the node field of ENV= won't help because bothnodes are on the same system); and it won't work with DAE either because DAE maintainsseparation of the application environment name space at the system level, not within asystem.

More on the role of Daemons and Node Agents

Daemons and Node Agents serve a number of different purposes. Node Agents, for example,are the servers the Deployment Manager talks to when it wishes to "push" configurationchanges out to the nodes. But there's another function of the Daemon/Node Agent pair, andthey have to do with how Java clients external to the cell gain access to EJBs in the cell.

This discussion does not apply to servers within the cell; this is all about Java clients outside thecell looking to make use of EJBs running inside the cell.

Note:

There are two processes that go on there:

1. Getting an IOR for an EJBHome

2. Using the IOR that was received

"IOR" stands for "Interoperable Object Reference."Terminology:

Requesting an IOR

The first thing an external client must do is "bootstrap" into the cell somewhere. For aNetwork Deployment configuration (like the AZCELL configuration) the client bootstraps intoa Node Agent, not a specific server. The client will do this with a URL that looks somethinglike this:PROVIDER_URL="//IIOP:<host_name>:<port_number>"

Here's the interesting part: it doesn't matter which Node Agent the client bootstraps into; allNode Agents have the same information.

This is why in the AZCELL configuration we configured all Node Agents to use the sameports, and in particular the "Bootstrap" and ORB ports. Recall that for the AZCELLconfiguration, the Node Agent port allocations scheme was:




Daemons Dep. Manager Node Agents azsr01 azsr02JMX Soap 9510 9520 9540 9550DRS 9511 9521 9541 9551Bootstrap 9512 9522 9542 9552ORB IIOP 9500 9512 9522 9542 9552ORB SSL 9501 9513 9523 9543 9553Discovery 9514 9524Multi-cast 9525HTTP 9518 9548 9558HTTP SSL 9519 9549 9559

Server Clusters

Notice how the "Bootstrap" and ORB IIOP are the

same value

Bootstrap and ORB ports for all Node Agents in cell

Recall further that the Node Agent's Bootstrap and ORB ports were part of our TCP profilefor Sysplex Distributor handling:

:VipaDistribute 9.82.25.13 port 9500 9501 9522 9523 DESTIP ALLVipaDistribute 9.82.25.13 port 9548 9549 DESTIP ALL :

wsccb.washington.ibm.com DNS

Node Agent Bootstrap and ORB ports

Node Agent ports subject to balancing with Sysplex Distributor

So now we can pull it together:

External client needs IOR, and gets the indirect form of that from Node Agent

It does not matter which Node Agent it goes to; all Node Agents have same information

In AZCELL configuration, all Node Agents are configured with the same ports

Sysplex Distributor configured to distribute Node Agent Bootstrap and ORB ports

Therefore, external clients seeking initial indirect IOR may bootstrap into:wsccb.washington.ibm.com:9522

and Sysplex Distributor will route request to one of the Node Agents in the cell.

This is really more for availability than for load balancing. External clients typically won't bebootstrapping into the name space that often.

Note:

Using the IOR received

The IOR received from the Node Agent will be an indirect IOR. Before the EJB can beaccessed, that indirect IOR needs to be turned into a direct IOR. Daemons provide thatservice.

It turns out that all Daemons in a Network Deployment configuration have full knowledge ofall the servers to which an indirect IOR could be resolved. So it doesn't matter whichDaemon a client comes into to turn the indirect IOR into a direct one.

All Daemons in this AZCELL configuration utilize ports 9500 and 9501. In addition, thosetwo ports are handled by Sysplex Distributor in the AZCELL configuration.




So again, we can pull it together:

External clients get indirect IOR by boostrapping into Node Agent

All Node Agents listen on the same ports, and Bootstrap and ORB ports handled bySysplex Distributor

External clients turn indirect IOR into direct IOR by going to Daemon

All Daemons listen on the same ports, and those ports are handled by SysplexDistributor

Whatever Daemon a client is sent to, that Daemon will know if the target server is active,and the Daemon has input from WLM it can use to balance when multiple servers hold theEJB being sought (as would be the case with clusters, for example).




Document Change HistoryCheck the date in the footer of the document for the version of the document.

Continued next page ...

Fixed discussion under "How the fenced-off ports were allocated to the variousservers" on page 16 that incorrectly stated that HTTP ports were not subject tobalancing with Sysplex Distributor. They in fact are, with these important caveats: only servers within a server cluster share the same HTTP ports, no "vertical clusters"were permitted (avoiding the issue of TCP port sharing), and maintaining sessionaffinity was assumed not to be a concern for this configuration.Provided a more in-depth discussion of why Daemons and Node Agents can shareports across configuration. See "More on the role of Daemons and Node Agents" onpage 124.

December 12, 2003

Emphasized more firmly that the use of minimized RACF profiles is something thatshould be coordinated with your security administrator. This document's"genericized" profiles was a way of illustrating how it could be done, not necessarily arecommendation that it should be done.Pointed out that the number of bytes allocated for cell identifier and componentidentifier in the naming convention was something that could be modified. (See "Thenaming convention used" on page 24.) We used two bytes for the cell identifier, butyou could just as easily use one ... or three for that matter. Same thing for thecomponent ID: we used four bytes, but you may use less or more as needed. Butyou only have eight characters to work with, the last character should be reserved forthe "S" servant flag, and the first character should be common throughout the cell.Described in better detail the Daemon server, and how Base Application Server nodeDaemons are temporary. Illustrated what Daemons are used before federation andafter. Illustrated how new Daemon is created when a Base Application Server nodeon a different MVS image from Deployment Manager is federated, and how that newDaemon has the same short name, JOBNAME and TCP ports as DeploymentManager Daemon. See "Daemons" on page 13.Pointed out how Dynamic WLM Application Environments (DAE -- OW54622) isrequired when configuring horizontal clusters.Pointed out that using Sysplex Distributor for HTTP ports is possible, but we decidednot to for the AZCELL configuration.Fixed the discussion of clustering to more correctly describe where the "cluster shortname" came frame. In the first version of this document it said the value was set byWebSphere was BBOC001. That's true, but only if the first server of the cluster is abrand new one you create as part of the process of creating a cluster. If you chosean existing server to act as the intial server, that server's "Cluster Transition Name"(WLM application environment) will become the cluster short name.In both sections related to federation, the original document stated you should loadthe SAVECFG from the Base Application Server node into the ISPF panels thatcustomize the BBOWADDN job. That may still be true, depending on what level ofmaintenance you have for WebSphere. At level W502000 and later therecommendation changes to loading the SAVECFG from the Deployment Manager.The reasons for this are documented under "Load customization variables" on page63. One way to quickly tell if W502000 is on your system is described under"Overview of federation process" on page 62. See "Appendix D - BBOANINS forFederation of Node into DM on SYSA" on page 116 for an example of the symptomof problem when loading the Base Application Server node's SAVECFG.Added Appendix E to offer a place to explain interesting things like what theapplyPTF.sh process is for, and why WLM Dynamic Application Environments arenecessary for horizontal clusters. See "Appendix E - Miscellaneous" on page 120.

November 30, 2003

Original document.October 29, 2003


Section: Document Change HistoryVersion Date: Tuesday, March 09, 2004- 127 -© 2003, IBM Americas Advanced Technical Support


Added the SGSKLOAD data set to the "System Locations 1 of 2" panels.Replaced the BBOCCINS instruction member (Appendix C - BBOCCINS forDeployment Manager on SYSA" on page 109). Previous edition of document usedcopy of member that had the wrong configuration HFS mount point.

March 9, 2004

Updated entire manual for W502000 maintenance level. Changes made throughoutthe document. Modications were made in the following subject areas:

Security Domain configurationLoading Security Domain saved variables into BaseApp, DMGR and FederationHLQ of data sets changed to WAS502.* from WAS500.*

Made stronger the emphasis about running BBOWADDN on the MVS image where thenode being federated resides. Previous versions were a bit soft on this.Provided information on changing the short name of the new cluster member toAZSR01B. By default that value will be BBOS001 when the cloned cluster member iscreated.

February 13, 2004

Fixed discussion of horizontal clusters and Dynamic Application Environments. Itturns out DAE isn't strictly required for horizontal clusters. If you configure your nodename equal to your system name, then you can code a static WLM applicationenvironment with the symbolic &SYSNAME as the node short name in the ENV= stringof the start parameters. Vertical clusters across two nodes on the same MVS imagestill present unique problems and should be avoided.

December 17, 2003

The naming convention used


Section: Document Change HistoryVersion Date: Tuesday, March 09, 2004- 128 -© 2003, IBM Americas Advanced Technical Support


Other Documents on the Techdocs websiteThe following is a list of other documents available on the Techdocs website. Updates to the siteare made frequently, so check back to see what's new:

http://www.ibm.com/support/techdocs

FLASH10243 Classify the Application Control Region in WLM OMVS rules after Service level W500104FLASH10245 Cautions when creating an ND configuration with WebSphere for z/OS V5 SL W500104

WP100339 Introduction to WebSphere for z/OS Version 5WP100367 WSC Sample WebSphere ND configuration on z/OSWP100396 Wepshere for z/OS Version5 - Planning for Test, Production and Maintenance

PRS708 WebSphere for z/OS Version 5 - "Gen 5" Wildfire Workshop PresentationzPRS752 Performance Summary Report for SMF 120 records from WAS V.5 for z/OS PRS733 zSeries and TotalStorage Technical Update (zSTSU)

TD101072 Using DB2 for z/OS in WebSphere for z/OS Version 5TD101073 Using the WebSphere for z/OS V5 Customization DialoguesTD101074 Enabling JCE & JSSE Security in WebSphere for z/OS Ver. 5TD101075 WebSphere Version 5 for z/OS: 10 Steps for an Easy InstallationTD101087 Directing SYSPRINT Output to an HFS File in WebSphere for z/OSTD101115 RACF Tools for WebSphere for z/OS Version 5TD101116 How to manage operator message routing in WebSphere for z/OS V5TD101118 RACF Tips for customizing WebSphere for z/OS Version 5TD101121 How to Update the CFRM Policy to include the WAS error logstreamTD101124 How to use WLM Dynamic Application Environments with WebSphere for z/OSTD101128 RACF Backout Tool for WebSphere for z/OS Version 5TD101150 Enabling Global Security in WebSphere V5 for z/OSTD101151 How to Classify Transactions in WebSphere for z/OS V5TD101152 How to Manage the Number of Servant Regions with WebSphere for z/OS V5 and WLMTD101198 Application Problem Isolation using the WSAD Distributed Debugger with WAS 5.0 for z/OSTD101199 Enabling the WSAD Application Profiler in a WAS 5.0 for z/OS EnvironmentTD101216 Tracing and Analyzing Java Garbage Collection in WebSphere for z/OS V5TD101242 How-to set up the Tivoli Performance Viewer with WebSphere V.5.0.1 for z/OSTD101245 Important Steps in Configuring WAS V5 NDTD101246 Using Log4j in J2EE Applications Under WebSphere Application Server v5 for z/OSTD101255 Implementing Enhanced Form Based Authentication with Servlet Filters in WAS v5 for z/OS

FQ102864 How big should my /tmp directory for WebSphere V5 for z/OS?FQ102865 How do I turn on SMF 120 recording for WebSphere V5 for z/OS?FQ102895 SRVE0079E: Servlet host not found with WebSphere Version 5FQ102912 How can I put a Local copy of the WebSphere InfoCenter on my workstation?


Section: Other Techdoc DocumentsVersion Date: Tuesday, March 09, 2004- 129 -© 2003, IBM Americas Advanced Technical Support


Index

0/AppServerNodeA

why made unique for SYSA, 44/AppServerNodeB

why unique for SYSB, 77/tmp directory

insuring access for BBOWADDN, 68, 88AaddNode.sh

batch invoked in BBOWADDN, 62administrative console

starting application server, 71validating on BaseApp SYSA, 50

administrative IDnamed during federation, 65specified in ISPF panels, 33used in AZCELL, 9

allocationdefault parameters for target data sets, 41of BaseApp SYSA target data sets, 40of BaseApp SYSB target data sets, 74of DM target data sets, 54of federation target data sets, BaseApp SYSA, 64of federation target data sets, BaseApp SYSB, 85of TCP ports, 16

APAROW54622 and BaseApp SYSA updates, 49OW54622, dynamic WLM application environments, 19

applicationenvironments, WLM dynamic, 19including during federation, 65server, starting through admin console, 71server, summary of naming convention, 30

applyPTFexplanation of what it does, 121step in BaseApp SYSA proc, 50

arrowgreen, status indicator for server, 71

AUTOGIDand BBOWCHFS job, 11function introduced, 11

AUTOUIDfunction and BBOWCHFS job, 11function introduced, 11

AZACRstart procedure for controllers, 26

AZAGNTserver name for node agents, 29

AZASRstart procedure for servants, 26

AZCELLcell long and short name, 28in summary table for naming conventions, 29long name convention, 27short name convention, 27userid and groups used, 8

AZDEMNJOBNAME in summary table for Daemons, 29same name used on SYSA and SYSB, 29

AZDEMN1temporary name given BaseApp Daemon on SYSA, 29

AZDEMN2temporary name given BaseApp Daemon on SYSB, 29

AZDMNin summary table for Daemon servers, 29start procedure for Daemon, 26

AZNODEAin summary table for naming conventions, 29

AZNODEBin summary table for naming conventions, 29

AZSR01server cluster, ports assigned, 18

AZSR02server cluster, ports assigned, 18

BbackoutPTF

explained, 121balancing

using Sysplex distributor, 18BaseApp Server

allocating target data sets, 40federation on SYSA, allocating target data sets, 64HFS not moved during federation, 62home directory, used in federation, 65main option panel in ISPF, 39on SYSA stopped prior to federation, 67on SYSA, listing of customized jobs, 49on SYSA, symbolic link changed, 68on SYSB, SAVECFG from SYSA loaded, 74option to configure in ISPF, 39why virtual host alias present there, 69

BBOANINSincorrect START string, 67instruction member for federation on SYSA, 67instruction member or federation, 62

BBOC00ninitial cluster short name, 23

BBOCBRAJcontrol over when commands issued, 10used to create RACF, 10

BBOCBRAKjob containing RACF commands, 10pointing to customized RACF member, 11

BBOCTLprogram module for controllers, 26

BBODMNprogram module for Daemon, 26

BBOMCFG2finalizes HFS, 12

BBOS001default name of application server, 67

BBOSRprogram module for servants, 27

BBOSSINSinstructions, BaseApp SYSA, 48manual updates for BaseApp SYSA, 48

BBOWADDNand creation of Node Agent, 17generated by ISPF federation option, 62output to /tmp directory, 68recommendation where to run, 68run for federation on SYSA, 68


Section: IndexVersion Date: Tuesday, March 09, 2004- 130 -© 2003, IBM Americas Advanced Technical Support


when HFS not shared, 84will attempt to stop BaseApp on SYSA, 67

BBOWBRAKcustomizing contents, 10DATA member pointed to by BBOCBRAK, 10

BBOWCHFSjob and AUTOUID/AUTOGID function, 11not run for BaseApp SYSB, 75should run on system that owns HFS, 74

BBOWCPYDhow mount point owner is assigned, 12

bootstrap portwhy two nodes on same MVS ruled out, 20

Ccell

BaseApp SYSA short and long name, in ISPF, 44Deployment Manager short and long name, in ISPF, 55long and short name, 28

cluster transition nameBaseApp SYSA, in ISPF, 44Deployment Manager, in ISPF, 55

clustersand HTTP port assignments, 17can't cluster two existing servers, 22changing default short name, 94consider servers as part of from beginning, 23creating second server on SYSB, 93creating through admin console, 91creation of, high level, 21definition of, 17first server, new or existing server, 22long name given, 92members have same ports, 17members have same WLM ApplEnv, 23, 122picture of, 21ports assigned, 18second server, copies of first, 22selecting AZSR01A as starting, 92short name equals WLM ApplEnv, 23short names, 22, 28vertical and dynamic WLM, 124vertical, ruled out, 17why BaseApp SYSB has name of AZSR02B, 77

CNTLallocation of target data sets, 40three members created for federation, 67

commandstart, for BaseApp on SYSA, 50start, for BaseApp on SYSB, 81

commonmount point, 6mount point, illustrated, 7

Config HFSrelationship to Code HFS, 120

config rootshared in AZCELL, 6

configuration groupimportant that it be consistent, 74specified in ISPF panels, 33

controllersJCL start procedure name, 26multiple started with same JCL, 4specifying JCL for BaseApp SYSA, in ISPF, 45specifying JCL for Deployment Manager, 56

specifying JOBNAME for BaseApp SYSA, in ISPF, 45specifying userid for BaseApp SYSA, in ISPF, 45specifying userid for Deployment Manager, 56start command used, 5

conventionnaming, discussed, 24

CTRACEdefined in ISPF panels, 43

customized RACF profilesmodifying BBOWBRAK contents, 10

DDaemon

created during federation, 15federation process will leave running, 67generic nature of DM's Daemon, 57home directory, BaseApp SYSA, 46home directory, Deployment Manager, 57JCL start procedure name, 26JOBNAME, BaseApp SYSA, 46JOBNAME, Deployment Manager, 57knowing which to shut down prior to federation, 68long name doesn't apply, 27more on its role, 124ORB traffic handled by Sysplex Distributor, 18overview, 13ports, BaseApp SYSA, 46ports, Deployment Manager, 57proc name, BaseApp SYSA, in ISPF, 46proc name, Deployment Manager, in ISPF, 57stopping BaseApp Daemon SYSB, 88temporary names given BaseApp Daemons, 29temporary nature of BaseApp, explained, 46

DATAallocation of target data sets, 40

default valuesfor target data set allocation, 41not used in this configuration, 3TCP ports, illustrated, 16

Define Variablespanel of federation of BaseApp SYSA, 64

Deployment Managercell, node, server names, 55consider cell-wide when naming, 15customized jobs, 58generating customized jobs, 58JOBNAME, proc and userid, 56loading SAVECFG into federation customization, 63long name doesn't apply, 27making sure up for federation, 67no system indicator in name, 27on SYSA, ISPF panels, 52ports assigned, 17SAVECFG file created for, 57SDCFG file from Security Domain loaded, 53starting, 59summary of names used, 29

distributorSysplex, and HTTP ports, 19Sysplex, described, 18Sysplex, in design, 4

DRS clientport, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56




DVIPAand ORB traffic, 18part of Sysplex distributor, 18

dynamicWLM application environments, 19

EENV= string

coded in JCL, 7for federated server on SYSA, 71for Node Agent on SYSA, 70for Node Agent on SYSB, 89passed in on START command, 5

errorcalling application, symptom explained, 69logstream, single, 20logstream, specified in ISPF panels, 43

Ffederation

adding virtual host alias, 69and BaseApp Daemon's JOBNAME, ports, 46and instruction member BBOANINS, 62BaseApp on SYSA, 61BaseApp on SYSB, 83BaseApp server stopped, 67Daemon used changes during, 13Define Variables panel, 64, 86defining Node Agent during, 65from another MVS image, 83HFS not moved during, 62insuring WAS admin ID used on SYSA, 66knowing which Daemon to shut down, 68loading SAVECFG from DMGR, 63making sure Deployment Manager is up, 67overview of process, 62security domain variables loaded, SYSA, 64two nodes on same MVS image, 20variables saved on SYSA, 66what it does, 61will leave BaseApp Daemon running, 67

fencing offTCP ports, 16

Ggenerating

custom jobs, federating on SYSA, 66customized jobs, BaseApp SYSA, 47customized jobs, BaseApp SYSB, 80customized jobs, Security Domain, 35

genericmaking RACF profiles more, 11

GIDuse of AUTOGID function, 11values in jobs other than BBOCBRAK, 11

groupconfiguration, specified in ISPF panels, 33

groupsmapping used in AZCELL, 8minimized in design, 4used by BaseApp, illustrated, 8, 31

HHFS

BBOWADDN when not shared, 84of BaseApp not moved during federation, 62ownership of finalized by BBOMCFG2, 12

run BBOWCHFS on system that owns, 74shared not a requirement, 42

home directoryDaemon BaseApp SYSA, in ISPF, 46Daemon Deployment Manager, in ISPF, 57for BaseApp on SYSA, 44for Deployment Manager, 55made unique for BaseApp SYSA, 44

horizontal scalingdesign objective, 3

host nameBaseApp SYSA node, 45BaseApp SYSB node, 78capability to have dual IP stacks, 57Deployment Manager node, 56HTTP transport, BaseApp SYSA, 45HTTP transport, Deployment Manager, 56ORB listener, BaseApp SYSA, 45ORB listener, Deployment Manager, 56

HTTPand Sysplex Distributor, 19port, adding to virtual host after federation, 69port, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56port, used when validating Deployment Manager, 59ports assigned during creation of cluster, 17transport host name, BaseApp SYSA, in ISPF, 45transport host name, Deployment Manager, in ISPF, 56

HTTP SSLport, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56

IImportant Point

cell name for BaseApp is temporary, 7, 44federation must run under WAS admin ID, 66, 87load SDCFG from Security Domain into DM config, 54many customized jobs require UID=0, 35, 48, 58, 80Security Domain variables key input elsewhere, 36Security Domain variables must be loaded into BaseApp,

40WebSphere Configuration Group stays consistent, 74

include appsspecified during federation, 65

install rootor mount point, specified in ISPF dialogs, 42

instructionsviewing, BaseApp SYSA, 48

Integral JMSnot covered in this document, 1

interim portsof BaseApp Daemon, explained, 46

IORand Node Agent, Daemon roles, 124

IP NameDaemon, BaseApp SYSA, 46Daemon, Deployment Manager, 57

ISPF Dialogsfor BaseApp on SYSA, 37illustration of schematic flow for BaseApp, 37invoking, 32license agreement, 32main option panel for BaseApp, 39note about staring on different MVS system, 73option to configure BaseApp, 39




Server Customization 1 of 4, BaseApp SYSA, 44Server Customization 1 of 4, BaseApp SYSB, 77Server Customization 1 of 4, Deployment Manager, 55Server Customization 2 of 4, BaseApp SYSA, 45Server Customization 2 of 4, BaseApp SYSB, 78Server Customization 2 of 4, Deployment Manager, 56Server Customization 3 of 4, BaseApp SYSA, 45Server Customization 3 of 4, BaseApp SYSB, 78Server Customization 3 of 4, Deployment Manager, 56Server Customization 4 of 4, BaseApp SYSA, 46Server Customization 4 of 4, BaseApp SYSB, 79Server Customization 4 of 4, Deployment Manager, 57System Environment 1 of 1, Deployment Manager, 55System Environment 1 of 3, BaseApp SYSA, 42System Environment 1 of 3, BaseApp SYSB, 75System Environment 2 of 3, BaseApp SYSA, 43System Environment 2 of 3, BaseApp SYSB, 76System Environment 3 of 3, BaseApp SYSA, 43System Environment 3 of 3, BaseApp SYSB, 76System Locations 1 of 2, BaseApp SYSA, 41System Locations 1 of 2, BaseApp SYSB, 75System Locations 1 of 2, Deployment Manager, 54System Locations 2 of 2, BaseApp SYSA, 42System Locations 2 of 2, BaseApp SYSB, 75System Locations 2 of 2, Deployment Manager, 55

JJava

home directory, specified in panels, 42JCL

controller start procedure name, 26Daemon start procedure name, 26different procs and dynamic WLM, 122minimized in design, 4proc, Daemon BaseApp SYSA, 46proc, Daemon Deployment Manager, 57servant start procedure name, 26start proc for BaseApp SYSA, in ISPF, 45start proc for Deployment Manager, 56start proc name for application servers, 30start proc name for Deployment Manager, 29start proc name for Node Agents, 29start procedures and naming convention, 26starting controller, 5using separate, 7

JMS Providernot covered in this document, 1

JOBcard, customized jobs BaseApp SYSA, 47card, customized jobs Security Domain, 35

JOBNAMEand naming convention, 25Daemon, Base Application Server node, 25Daemon, BaseApp SYSA, 46Daemon, Deployment Manager, 25, 57displaying on SDSF DA panel, 26for application servers, 30for Deployment Manager, 29illustration of naming structure, 25relationship to server short, 27table relating with short and long names, 27temporary nature of BaseApp Daemon, 14used for Node Agents, 29

jobscustomized jobs, running sequentially, 49Deployment Manager, running sequentially, 58

generating custom, BaseApp SYSA, 47generating custom, BaseApp SYSB, 80generating custom, Deployment Manager, 58generating custom, federation on SYSA, 66generating custom, federation on SYSB, 87generating custom, Security Domain, 35insuring SYSA federation runs under WAS admin ID, 66

Llength restrictions

and short names, 27LNKLST

indicating if modules reside in, 41logstream

error, single, 20error, specified in ISPF dialogs, 43

long namesand short names, explained, 27AZCELL convention used, 27don't apply to Daemons, DM and Node Agents, 27for nodes, 28summary for application servers, 30summary for cell and nodes, 29summary for Daemon servers, 29summary for Deployment Manager, 29summary for Node Agents, 29

lowercaselong names in, 27

Mmaintenance

backing out and applyPTF, 121manual updates

BaseApp SYSA and WLM ApplEnv, 49for BaseApp SYSB, 80in creation of BaseApp on SYSA, 48

mount pointand use of common JCL, 5and userid/group assigned, 11for Deployment Manager, specified in ISPF, 55of SBBOHFS data set, 42owner assigned in BBOWCPYD, 12shared in AZCELL, 6

MVSlength restrictions and short names, 27

Nnaming convention

and JCL start procedures, 26and MVS JOBNAME, 25controller JCL start procedure, 26Daemon JCL start procedure, 26discussed, 24for cell, 28for clusters, 28for nodes, 28objective of configuration, 3servant JCL start procedure, 26summary for application servers, 30summary for cell and nodes, 29summary for Daemon servers, 29summary for Deployment Manager, 29summary for Node Agents, 29table of short, long and JOBNAME, 27

nodeBaseApp SYSA short and long, in ISPF, 44




Deployment Manager short and long, in ISPF, 55Node Agents

defining during federation, 65long name doesn't apply, 27more on their role, 124ORB traffic handled by Sysplex distributor, 18ports assigned, 17same ports used by all, 17same ports used SYSA and SYSB, 84starting after federation on SYSA, 70starting after federation on SYSB, 89summary of names used, 29

NODENAMEfound in BBOANINS member, 67

nodeshost name, BaseApp SYSA, 45host name, Deployment Manager, 56little value in multiple per MVS image, 20long and short names, 28must have access to Daemon services, 13short names and dynamic WLM, 123two in same MVS image ruled out, 20

OORB

listener host name, BaseApp SYSA, in ISPF, 45listener host name, Deployment Manager, in ISPF, 56port traffic handled by Sysplex distributor, 18port, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56

ORB SSLport, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56

ownerof mount point assigned, 12

ownershipof configuration HFS, 12

PParallel Sysplex

WSCPLEX described, 2PARMLIB

specified in Systems Locations panel, 41ports

and Sysplex distributor, 18assigned to clusters, 18assigned to Deployment Manager, 17assigned to Node Agents, 17Daemon, BaseApp SYSA in ISPF, 46, 57for Node Agents, defined, 65HTTP assigned for clusters, 17of new cluster server remapped, 93same used for both Node Agents, 84sharing, not considered for clusters, 17TCP, actual allocation used, 16TCP, default assignments illustrated, 16TCP, used by Websphere, 15

pre-W502000and which SAVECFG to load into federation, 63

proceduresminimized in design, 4

PROCLIBspecified in Systems Locations panel, 41

profilesRACF, minimized, 4

RRACF

administrative and unauthorized, 9administrator ID, specified in ISPF, 33AUTOUID and AUTOGID, 11BBOCBRAJ used to create profiles, 10how profiles for BaseApp work for DM as well, 56profiles minimized, 4server-specific profiles, 9unauthenticated user, specified in ISPF, 33userids and groups used in AZCELL, 8

rangeof TCP ports fenced off, 16

remappingports of new cluster member, 93

ROOTin JCL, 6passing in on START, 6

RRSlogstream, specified in ISPF panels, 43

SSAVECFG

created for BaseApp on SYSA, 47created for BaseApp on SYSB, 79created for Deployment Manager, 57for federation on SYSA, 66for federation on SYSB, 86from BaseApp SYSA loaded for DM, 53from BaseApp SYSA loaded for SYSB, 74from DMGR loaded into federation customization, 63of BaseApp SYSB loaded for federation, 85

savingcustomization variables, BaseApp SYSA, 47customization variables, Security Domain, 35

scalingobjective of configuration, 3

SDCFGcreated for Security Domain, 35loaded into BaseApp customization, SYSA, 40loaded into BaseApp customization, SYSB, 74loaded into federation, SYSA, 64loaded into federation, SYSB, 85variables file from security domain, 9

SDSFbenefit of good naming convention, 26

securitynot covered in this document, 1

Security Domainintroduced, 9ISPF panel, 33listing of customized jobs, 36variables loaded into BaseApp customization SYSA, 40variables loaded into BaseApp customization SYSB, 74variables loaded into SYSA federation customization, 64variables, loaded into DMGR configuration, 53

separateJCL, using, 7

sequentialrunning custom jobs, 49

servantscommon group, specified in ISPF panels, 33JCL start procedure name, 26multiple started with same JCL, 4




relationship to green status arrow, 71specifying JCL proc for BaseApp SYSA, in ISPF, 45specifying JCL proc for Deployment Manager, 56specifying JOBNAME for BaseApp SYSA, in ISPF, 45specifying JOBNAME for Deployment Manager, 56

serverapplication, summary of naming, 30BaseApp SYSA short and long, in ISPF, 44can't cluster two existing, 22clustered, definition of, 17Deployment Manager short and long, in ISPF, 55naming for additional application servers, 30short name and relationship to JOBNAME, 27starting from admin console, 71, 89table of short, long and JOBNAME, 27

Server Customization 1 of 4BaseApp SYSA, 44BaseApp SYSB, 77Deployment Manager, 55




server-specificRACF profiles, 9

shared HFSand BBOWADDN, 84BBOWADDN when not shared, 84Deployment Manager same HFS as BaseApp, 55possible but not required, 42

short namesand long names, explained, 27AZCELL convention used, 27changing default short in new cluster, 94for cell, 28for clusters, 28for nodes, 28relationship in clusters, 24relationship to JOBNAME, 27summary for application servers, 30summary for cell and nodes, 29summary for Daemon servers, 29summary for Deployment Manager, 29summary for Node Agents, 29

SMP/Emaintenance against Code HFS, not Config, 120

SOAPport of Deployment Manager, used in federation, 65port, BaseApp SYSA, in ISPF, 45port, Deployment Manager, in ISPF, 56

SSLHTTP port, BaseApp SYSA, in ISPF, 45HTTP port, Deployment Manager, in ISPF, 56ORB port, BaseApp SYSA, in ISPF, 45ORB port, Deployment Manager, in ISPF, 56port, Daemon BaseApp SYSA, 46

port, Daemon Deployment Manager, 57START

command and ENV=, 5command for Deployment Manager, 59command for federated server on SYSA, 71command for Node Agent SYSA, 70command, BaseApp SYSA, 50command, BaseApp SYSB, 81

start commandfor BaseApp on SYSA, 50for BaseApp on SYSB, 81

start proceduresminimized in design, 4

STARTED profileexample of BBOWBRAK contents, 10when separate JCL used, 7

statusafter BaseApp on SYSA, 51after BaseApp on SYSB, 82after Deployment Manager, 60after federation on SYSA, 72after federation on SYSB, 90final configuration, 95indicator for started server, 71

symbolic linksfor BaseApp changed during federation, 68of BaseApp updated during federation, 62

Sysplexdistributor, described, 18distributor, in design, 4WSCPLEX described, 2

System Environment 1 of 1Deployment Manager, 55

System Environment 1 of 3BaseApp SYSA, 42BaseApp SYSB, 75



system indicatorand application server name, 30for nodes, 28not used for Deployment Manager, 27

System Locations 1 of 2BaseApp SYSA, 41BaseApp SYSB, 75Deployment Manager, 54

System Locations 2 of 2BaseApp SYSA, 42BaseApp SYSB, 75Deployment Manager, 55

system specificmount point, 6

Ttarget data sets

allocating for BaseApp SYSA, 40allocating for BaseApp SYSB, 74allocating for Deployment Manager, 54allocating for federation of BaseApp SYSA, 64allocating for federation of BaseApp SYSB, 85




default allocation values, 41use different for each configuration, 54

TCPactual allocation used, 16assignment of HTTP ports for clusters, 17ports assigned to clusters, 18ports assigned to Deployment Manager, 17ports assigned to Node Agents, 17ports for Node Agents, defined, 65ports of new cluster server remapped, 93ports use by WebSphere, 15ports, default assignments illustrated, 16profile and Sysplex distributor, 18temporary nature BaseApp Daemon ports, 14

TechdocsURL for this white paper, 2

temporarynames given BaseApp Daemons, 29nature of BaseAppDaemons, explained, 46

trafficORB handled by Sysplex distributor, 18using Sysplex distributor, 18

UUID

use of AUTOUID function, 11values in jobs other than BBOCBRAK, 11

UID=0applied to JOB card, BaseApp SYSA, 47applied to JOB card, Deployment Manager, 58applied to JOB card, Security Domain, 35

unauthenticated userspecified in ISPF dialogs, 33

unauthorized user IDused in AZCELL, 9

uppercaseshort names in, 27

URLfor this document on Techdocs, 2

useridsadministrative and unauthorized, 9Daemon, BaseApp SYSA, in ISPF, 46Daemon, Deployment Manager, in ISPF, 57for BaseApp server SYSA, in ISPF, 45for Deployment Manager, 56mapping used in AZCELL, 8minimized in design, 4re-using IDs for other servers, 8used by BaseApp, illustrated, 8, 31

Vvalidation

of BaseApp SYSA, 50of BaseApp SYSB, 81

variablesfrom BaseApp SYSA loaded into BaseApp SYSB, 74from BaseApp SYSA loaded into DM config, 54saved for Deployment Manager, 57saved, BaseApp SYSA, 47saved, BaseApp SYSB, 79saved, federation on SYSA, 66saved, Security Domain, 35

vertical scalingdesign objective, 3

virtual addressand Sysplex distributor, 18

virtual host aliasadding after federation, 69, 88adding to definition, 70built automatically in BaseApp server, 69symptom if not present, 69use of single asterisk for host, 69

WW502000

and which SAVECFG to load into federation customization,63

WAShome directory, BaseApp SYSA, 44home directory, Deployment Manager, 55

WAS home directoryspecified on federation panel, 65

was.envpointer to in JCL, 5

WebSphere Administratornamed during federation, 65specified on SYSA federation JOB card, 66

WLMApplEnv and clusters, 23ApplEnv for application servers, 30ApplEnv name for Deployment Manager, 29cluster short name equals ApplEnv, 23dynamic ApplEnv and manual updates in BBOSSINS, 49horizontal cluster and different definitions, 122use of dynamic application environments, 19

WP100396Test, Production and Maintnenance white paper, 42

wsc1.washington.ibm.comIP name, Daemon, BaseApp SYSA, 46IP name, Daemon, Deployment Manager, 57node host name, BaseApp SYSA, 45node host name, Deployment Manager, 56

WSCPLEXdescribed, 2




End of Document WP100367

WP100367 - Washington Systems Center Sample Configuration

Section: Last Page of DocumentVersion Date: Tuesday, March 09, 2004- 137 -© 2003, IBM Americas Advanced Technical Support
