The Profile Management Tool has created jobs based on the information you
provided. These instructions tell you how to modify the operating
system and run the jobs to customize WebSphere Application Server for z/OS.
When you upload the customization jobs to the target system, a text version of
these instructions will be written to:
${zTargetHLQ}.CNTL(BBOMNINS)
The Profile Management Tool does not attempt to
update configuration data for your base operating system or existing
subsystems. You need to perform the following manual steps prior to running
the WebSphere for z/OS configuration jobs.
-
Update BLSCUSER. To use the IPCS support provided by the product,
append the contents of the
cntl/bboipcsp
file within this customization definition to the BLSCUSER member in your
IPCSPARM or system PARMLIB dataset.
-
Update SCHEDxx.
Refer to the
cntl/bbosched
file within this customization definition.
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
to activate SCHEDxx and load a new program properties table.
-
Check that the following data sets are APF-authorized:
${zBbolpaName}
${zBboloadName}
${zBbgloadName}
${zBbolod2Name}
${zAppServerBbolpaName}
${zAppServerBboloadName}
${zAppServerBbgloadName}
${zAppServerBbolod2Name}
Add these datasets to your PROGxx or IEAAPFxx parmlib members, as
appropriate, ensuring you specify the correct volsers.
Note: You must add the actual data set names to your parmlib members and not any aliases you may have specified.
-
Update SMFPRMxx. To collect the SMF120 records created by the run-time servers,
update SMFPRMxx to include record type 120, as in the following 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.
-
Update your active BPXPRMxx member to have the following WebSphere Application Server
for z/OS configuration file system:
${zConfigHfsName}
mounted at:
${zConfigMountPoint}
in read/write mode.
Example:
MOUNT FILESYSTEM('${zConfigHfsName}') MOUNTPOINT('${zConfigMountPoint}') TYPE(${zFilesystemType}) MODE(RDWR) PARM('AGGRGROW')
MOUNT FILESYSTEM('${zConfigHfsName}') MOUNTPOINT('${zConfigMountPoint}') TYPE(${zFilesystemType}) MODE(RDWR)
If you are configuring in a sysplex environment, you may wish to use the NOAUTOMOVE parameter as follows:
MOUNT FILESYSTEM('${zConfigHfsName}') MOUNTPOINT('${zConfigMountPoint}') TYPE(${zFilesystemType}) MODE(RDWR) PARM('AGGRGROW') SYSNAME(${zSystemName}) NOAUTOMOVE
MOUNT FILESYSTEM('${zConfigHfsName}') MOUNTPOINT('${zConfigMountPoint}') TYPE(${zFilesystemType}) MODE(RDWR) SYSNAME(${zSystemName}) NOAUTOMOVE
Note: The NOAUTOMOVE parameter prevents the configuration file system from being mounted on a different z/OS
system in a shared file system configuration, which could cause performance problems.
If you have specified aggrgrow=on in your IOEFSPRM parmlib member, you can omit the AGGRGROW parm shown in the above examples
-
Update TCP/IP by reserving the following ports for WebSphere Application Server for z/OS.
These will be used during the federation process of your managed node.
Type |
Number |
SOAP JMX Connector port |
${zFederateJmxSoapConnectorPort} |
Node Discovery port |
${zFederateNodeDiscoveryPort} |
Node Multicast Discovery Port |
${zFederateNodeMulticastDiscoveryPort} |
Node IPv6 multicast discovery port |
${zFederateNodeIPv6MulticastDiscoveryPort} |
Node Agent's ORB port |
${zFederateOrbPortName} |
High Availability Manager Communication port |
${zFederateHamCommPort} |
Node Agent's ORB SSL port |
${zFederateOrbSslPortName} |
Add the contents of the
cntl/bbotcpim
file within this customization definition to the PORT section of the file
referenced by the DD statement for the TCP/IP profile in the
TCP/IP start procedure. Copy and paste from this file 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 use the Profile Management Tool to update the
port specifications, be sure to upload the updated customization jobs.
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 Application 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 Application Server must
be assigned a new ORB port. The default new ORB port for the
Application Server is 9810. The nodeagent will take over a
Application Server's ORB port only if the nodeagent's ORB
port is equal to an Application 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 Application Server in
the 'Appplication Server's ORB Port' field.
Attention: Skip this step if the ports are already defined in the
TCP/IP profile.
- The WebSphere product libraries will be placed in the system link
pack area (LPA) and system link list.
Check that no other copies of WebSphere Application server, from any
release, reside in the link pack area or the system link list. Also,
check that the target MVS system has at least 40MB of free storage in the
extended CSA if SBBOLOAD is placed in the link pack area, or 8MB
of free storage in extended CSA for the daemon and for each node
(deployment manager node or application server node), if SBBOLOAD
is placed in the link list.
SBBOLOAD
You can either load the SBBOLOAD modules into the dynamic link pack
area, which we recommend, or place SBBLOAD in the system link list.
- To load the SBBOLOAD modules into the dynamic link pack area,
enter the following MVS console command:
SETPROG LPA,ADD,MASK=*,DSNAME=${zBboloadName}
Alternatively, you can place the following statement in a parmlib
PROGxx member which is activated with the SET PROG=xx
command after system IPL is complete:
LPA ADD MASK(*) DSNAME(${zBboloadName})
Check that sure that the SBBOLOAD modules are loaded into LPA after each
system IPL.
- To put the SBBOLOAD data set into the system link list.
Determine whether your system uses static (LNKLSTxx) or dynamic
(PROGxx) link list definition, and add the following data set name to the
appropriate LNKLSTxx or PROGxx member. (An IPL will normally be required.)
${zBboloadName}
SBBGLOAD
If your servers will be running in 64-bit mode, the SBBGLOAD data
set must be added to the system link list or link pack area
following the same procedure as for the SBBOLOAD data set.
SBBOLD2
Place the SBBOLD2 data set into the system link list. This data
set must NOT be placed in the system link pack area; separate
copies of the SBBOLD2 modules need to be loaded into each WebSphere
Application Server address space.
- To put the SBBOLD2 data set into the system link list
Determine whether your system uses static (LNKLSTxx) or dynamic (PROGxx)
link list definition, and add the following data set name to the
appropriate LNKLSTxx or PROGxx member. (An IPL will normally be required.)
${zBbolod2Name}
- The WebSphere product libraries are placed in STEPLIB as
needed, rather than in the system link pack area and system link
list.
Make sure that the target MVS system has at least 8MB
of free storage in extended CSA for the daemon and for EACH
node (deployment manager node or application server node).
SBBOLOAD, SBBGLOAD and SBBOLD2
The following data sets will be placed in the STEPLIB concatenation
for the location service daemon, controller and servant regions,
and in the setupCmdLine.sh script in the WebSphere Configuration
file system. You must not remove these STEPLIB statements.
${zBboloadName}
${zBbgloadName}
${zBbolod2Name}
The following data sets will be placed in the STEPLIB concatenation
for the location service daemon, deployment manager controller and servant
regions, and in the setupCmdLine.sh script in the WebSphere Configuration
file system for the deployment manager. You must not remove these STEPLIB
statements.
${zBboloadName}
${zBbgloadName}
${zBbolod2Name}
The following data sets will be placed in the STEPLIB concatenation
for the application server controller, controller adjunct and servant
regions, and in the setupCmdLine.sh script in the WebSphere Configuration
file system for the application server. You must not remove these STEPLIB
statements.
${zAppServerBboloadName}
${zAppServerBbgloadName}
${zAppServerBbolod2Name}
BBORTS61
The BBORTS61 module is used by WebSphere Application Server for
component trace support. A copy of this module (any maintenance
level) must be in the system link pack area in order for CTRACE
to work correctly.
If a copy of BBORTS61 is currently loaded into LPA, no further action is required.
Otherwise, issue the following MVS console command to load BBORTS61 into dynamic LPA:
SETPROG LPA,ADD,MODNAME=BBORTS61,DSNAME=${zBbolpaName}
Alternatively, you can place the following statement in a parmlib
PROGxx member, which is activated with the SET PROG=xx command after
system IPL is complete:
LPA ADD MODNAME(BBORTS61) DSNAME(${zBbolpaName})
Check that the BBORTS61 module is loaded into LPA after each system IPL.
-
WebSphere Application Server for z/OS customization assumes that the following system data sets are in the system link list:
Language Environment SCEERUN
SCEERUN2
System SSL SIEALNKE (z/OS 1.6 and above)
See the Language Environment Customization manual and the System
SSL Programming manual for your z/OS release for advice on placing
members from the libraries into the system link pack area.
Placing these data sets in the link list insulates your WebSphere Application Server
for z/OS configuration from changes in data set names (for example,
when migrating to z/OS 1.6).
If the Language Environment or System SSL load module libraries are
not in your system link list, you need to perform the following steps
before starting any WebSphere Application Server for z/OS servers:
- Check that the data sets are APF-authorized
- Complete the optional step below to add the data sets to STEPLIB in the server JCL and setupCmdLine.sh script(s).
If you regenerate server cataloged procedures at any point, make
sure the data sets are added to the new cataloged procedures.
-
If the error logstream ${zErrorLogstreamName} does not already exist on your target system,
make a copy of the appropriate job in the SBBOJCL data set, customize it according to the comments in the job, and run:
BBOERRLC Create an error logstream in a coupling facility
BBOERRLD Create a DASD-only error logstream
-
WebSphere Application Server 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
The Profile Management Tool built a number of batch jobs with the
variables you supplied. You need to run the jobs in the order listed
below, using user IDs with the appropriate authority.