WebSphere Application Server for z/OS V8.5 federation instructions:

The Profile Management Tool has created a response file based on the information you provided. These instructions tell you how to convert this response file into a set of customization jobs and how to 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(BBOANINS)

Guidelines

• Create the customization jobs and upload them to the following data sets on the target system:

      ${zTargetHLQ}.CNTL
      ${zTargetHLQ}.DATA
  

  Use the Process action to create the customization jobs and upload them to the target z/OS system.

• You need to use these instructions on your target system.
• Complete the customization of a stand-alone application server and the customization of a deployment manager server. Also, ensure that the deployment manager server has been started before starting these instructions.

Manual configuration updates

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.

1. Update TCP/IP by reserving the following ports for WebSphere Application Server for z/OS:
   
   Attention: Skip this step if the ports are already defined in the TCP/IP profile.
   
   

   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}
   Admin local port	${zFederateAdminLocalPort}
   High Availability Manager Communication port	${zFederateHamCommPort}
   Node Agent's ORB SSL port	${zFederateOrbSslPortName}
   Middleware Agent RPC port	${zMiddlewareAgentPort}
   Administration Overlay UDP port	${zAdminOverlayUDPPort}
   Administration Overlay TCP port	${zAdminOverlayTCPPort}
   Application Server's ORB Port	${zFederateAppServerOrbPort}

   
   

   Add the following contents to the PORT section of the TCP/IP profile that is used by the TCP/IP start procedure.

   Alternatively, once the customization jobs are uploaded to the target z/OS system, you may append the contents of the following partitioned data set member to the PORT section of the TCP/IP profile:

       ${zTargetHLQ}.CNTL(BBOTCPIA)
   

   
   

   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. Be aware that 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. Usually 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 an Application Server's ORB port if and 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: 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 z/OS Profile Management tool with new port specifications, be sure to regenerate the customization jobs, data, and instuctions.
   
   

   Status of task	Date

   
   
   

Running the customized jobs

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.

Some of the customization jobs write temporary files to the /tmp directory. For each of these jobs, the customization process provides an alternate job that will write temporary files to the directory specified by the TMPDIR environment variable. If the TMPDIR environment variable is not defined, then the /tmp directory is used. These alternate jobs require a minimum WebSphere Application Server for z/OS service level of 8.5.5.0 on the target system. Refer to Customizing your .profile in z/OS UNIX System Services User's Guide (SA22-7801-14) for information on defining environment variables.

1. Run Job BBOWADDN
   
   User ID requirement: File system update authority.
   

   If the Network Deployment cell uses a z/OS LocalOS (SAF) registry, then the user ID used to run this job must be connected to the Network Deployment cell's configuration group.

   If SSL certificates are stored in the SAF keyrings, then the user ID used to run this job must have a SAF keyring whose name matches the value of com.ibm.ssl.keyStore in the application server's WAS_HOME/profiles/default/properties/ssl.client.props file, and this keyring must contain the Network Deployment cell's CA certificate.

   
   Add the application server or servers associated with the stand- alone application server node to the deployment manager's cell.
   
   For security enablement on the Deployment Manager:
   
   
   • If both your target Network Deployment cell and the cell containing the node you are federating use WebSphere- managed security, and both cells are using file-based keystores, run the retrieveSigners.sh script from the home directory of the node being federated: ${zConfigMountPoint}/${zWasServerDir}/bin/retrieveSigners.sh CellDefaultTrustStore ClientDefaultTrustStore -port ${zFederateDmaPort} -conntype ${zFederateDmaPortType} -user ${zFederateDmaSecurityUserID} -password ${zFederateDmaSecurityPassword} -autoAcceptBootstrapSigner
   • Verify that your target Network Deployment cell is running without administrative security. You should enable administrative security after federation to prevent unauthorized access to the Network Deployment cell.
   
   
   If your application server is using z/OS log streams for transaction XA partner logs, delete and recreate the log streams before federation.
   
   Note: If your system is busy, you may want to include a rule in your WLM policy that OMVS work for job ${zFederateServerShortName} (such as the postinstaller step) is to run in a service class with a high service objective.
   
   If you choose to start the node agent automatically, the user ID used to run BBOWADDN will also need the authority to issue the MVS START command.
   
   
   Attention: Before you run the BBOWADDN job to federate the stand-alone Application Server node, you must have started the stand-alone Application server 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: You can run job BBO855UF instead of BBOWADDN if the target WebSphere Application Server for z/OS installation image is at least at the 8.5.5.0 service level. The BBO855UF job will use the directory specified by the TMPDIR environment variable, if defined, for temporary files. The user ID requirements for the BBO855UF and BBOWADDN jobs are the same.
   
   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.
   

   Status of task	Date

   
   
   
   
   
2. Start the node agent server
   
   
   Note: If your server is already running, this step is not necessary.
   
   Example: If your Application Server proc name is XXXXXXXX, and your Application Server node name (short) is YYYYYYYY, and your Deployment Manager cell name (short) is ZZZZZZZZ, issue the MVS command:
   START XXXXXXXX,JOBNAME=${zFederateServerShortName}, ENV=ZZZZZZZZ.YYYYYYYY.${zFederateServerShortName}
   
   Result: The following message appears on the console and in the job log of ${zFederateServerShortName}.
   BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS ${zFederateServerShortName}.
   

   Status of task	Date

   
   
   
   


3. Start the Application Server (optional)
   
   Note: You must start the node agent before you start the Application Server, if the node agent has not already been started.
   
   Example: If your Application Server proc name is XXXXXXXX, and your Application Server node name (short) is YYYYYYYY, and your server short name is BBOS001, and your Deployment Manager cell name (short) is ZZZZZZZZ, the MVS command you would issue would be similar to the following:
   START XXXXXXXX,JOBNAME=BBOS001,ENV=ZZZZZZZZ.YYYYYYYY.BBOS001
   
   
   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
   
   
   

   Status of task	Date