This topic applies only on the z/OS operating system.

Migrating a deployment manager node

After you use the Customization Dialog to generate JCL jobs for migrating a deployment manager to WebSphere Application Server for z/OS Version 6.0.x, you can perform the actual migration by running those jobs.

About this task

The deployment manager node is always migrated first. Review the applicable coexistence requirements for your system. If you are migrating from Version 5.0.2 or lower, you need to migrate other nodes in the same cell and on the same MVS image as the deployment manager sequentially, one immediately after the other.

The BBOWMG3D job referenced below must be submitted by a WebSphere Administrator User ID. All other jobs must be submitted by a user ID that has control over the file system.

Note on maintaining high availability during migration from Version 5.x to Version 6.0.x:

Migrating a deployment manager from Version 5.x to Version 6.0.x redeploys all application binaries when the deployment manager is restarted. This action results in the deployment manager recycling all the applications across the sysplex and causes an outage in a sysplex that is set up for high availability.

To maintain high availability during the migration, turn off all synchronization options for all of the node agents in the sysplex before restarting the deployment manager.
  1. Open the administrative console.
  2. Go to System administration > Node agents.
  3. For each node agent in the sysplex, go to node_agent_server_name > File synchronization service and disable all synchronization processing.

Procedure

  1. Create and mount a new Version 6.0.x HFS.

    Before you perform the migration, Version 6.0.x requires an HFS to be present for your new configuration. You can run BBOWMDMT to create and mount a new HFS, or you can mount one manually. Either way, you must have an HFS for your Version 6.0.x configuration created and mounted before you proceed. This HFS is the target of the migration; your Version 5.x configuration HFS is the source.

    BBOWMDMT creates a mount point directory, allocates the configuration's HFS, and mounts the HFS at whatever value you specified on the field called "Mount Point" in the "System Environment Customization" panel in the Customization Dialog.

    Before you proceed, ensure that you have, either manually or using BBOWMDMT, allocated, created, and mounted your HFS data sets. The mount point should be owned by the WebSphere Admin ID, and have permissions of at least 755. The new HFS structures in should be included in BPXPARM so that they will be mounted at the next IPL.

  2. Copy your generated JCL procedures.

    The migration utility BBOMDCP copies the generated JCL procedures to start the servers to the specified procedure library. Your Version 6.0.x configuration must make use of different JCL start procedure names; this utility will update the new Version 6.0.x configuration, substituting your new JCL names in place of the names that existed in your original Version 5.x configuration. Submit BBOMDCP, and verify a return code of 0.

  3. Update your RACF STARTED profiles.
    The STARTED profile used by controller regions is based on the procedure name and JOBNAME. Because Version 6.0.x requires new start procedures, you must ensure that a STARTED profile will apply so that the proper identity will be assigned to the started task. For example, if your Version 5.x deployment manager controller JCL procedure name is AZDCR, and you specified AZ1DCR for Version 6.0.x, then you would need to create a STARTED profile for that new procedure name:
                  new controller      same identity used in
                     JCL name         V5.x configuration
                        |                    |
     RDEFINE STARTED AZ1DCR.* STDATA(USER(AZDCRU) GROUP(AZCFG) TRACE(YES))
    Note:
    • Do not use a different user ID to start. There are other things tied to the user ID, and if you change the user ID other changes would also be required.
    • If your original STARTED profile was generic, for example, STARTED AZ*.* ... , you would not need to create a new STARTED profile.
    • Servant region STARTED profiles are based on JOBNAME, not procedure name. So there is no issue with the servant when you use a different procedure name.
    • Daemons and node agents are controllers, so using different procedure names for those implies a new STARTED profile.
  4. Stop the Version 5.x deployment manager.

    You must stop the Version 5.x deployment manager before submitting BBOWMG3D.

  5. Submit BBOWMG3D.

    A deployment manager migration does not require bringing the node into and out of PRR mode as standalone application server and federated node migrations do. Hence, there are two less jobs to submit for a deployment manager migration, and, at this point, you are ready to perform the physical migration.

    BBOWMG3D is the job that performs the physical migration of the Version 5.x deployment manager to Version 6.0.x, based on the information you supplied in the Customization Dialog. Submit BBOWMG3D. Verify that you are getting return codes of 0, and review the log files in the migration temp directory on the HFS (this directory is /tmp/migrate/directory, where directory is the numeric value specified in the Deployment Manager Customization panel in the Customization Dialog.

  6. Update the deployment manager's servant keyring.

    If you use separate user IDs to run your deployment manager's controller and servant regions, you must add a WASKeyring to the deployment manager's servant user ID then connect the WebSphere CA certificate to the WASKeyring:

    RACDCERT ADDRING(WASKeyring) ID(dmgr_servant_user_ID)
    RACDCERT ID(dmgr_servant_user_ID) CONNECT(RING(WASKeyring) LABEL('WebSphereCA') CERTAUTH) 
  7. Shut down the application servers and daemon.

    The daemon must be at the highest version level of any of the servers that it manages on the same LPAR. It will be at the Version 6.0.x level when the deployment manager is started. At this point, ensure that all nodes on the deployment manager's LPAR have been shut down.

  8. Start the deployment manager.

    Use the existing commands that you would use to start a Version 5.x Application Server, but replace the RACF STARTED procedure name with the value you entered in the Deployment Manager Customization Dialog (2 of 2) for Controller Procedure name. This command starts the Version 6.0.x deployment manager. Wait until the server is finished initializing before proceeding.

    The following message is displayed on the console and in the job log of BBOS001:
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
    At this point, your migration to Version 6.0.x is complete.
  9. Perform the post-migration tasks.
    After you have verified a successful migration to Version 6.0.x, and are successfully running a migrated configuration, you should delete:
    • Everything in the source configuration's HFS
    • Everything in the target configuration's /tmp/migrate/nnnnn/ directory
    • The bbomigrt2.sh file

    WebSphere Application Server for z/OS Version 6.0.x requires that the daemon process be at the highest level of code of any of the servers that it manages. If your Version 6.0.x deployment manager manages any Version 5.1 nodes on the same LPAR, you must update the Version 5.1 daemon STARTED procedure to STEPLIB to the Version 6.0.x libraries.

    For example, add the following to your Version 5.1 daemon procedure's "Z=BBO5DMNZ" member, using your library names:
    //*STEPLIB Setup
    //*
    //STEPLIB  DD DSN=hlq.SBBOLD2,DISP=SHR
    //         DD DSN=hlq.SBBOLOAD,DISP=SHR
    //         DD DSN=hlq.SBBOLPA,DISP=SHR
    //*                                      



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 8:25:23 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=rins51migappz
File name: rins_51migappz.html