Migrating a z/OS deployment manager

After you generate JCL jobs for migrating a deployment manager to WebSphere® Application Server Version 7.0, you can perform the actual migration by running those jobs. When you generated your custom migration jobs, you also created customized instructions for preparing and running the migration jobs in the BBOMDINS members of the CNTL dataset that was used to generate your jobs. Follow these customized instructions to complete the process of migrating your deployment manager to Version 7.0.

Before you begin

For help, read Troubleshooting migration.

Procedure

  1. Create and mount a new Version 7.0 configuration file system.

    Before you perform the migration, Version 7.0 requires a configuration file system to be present for your new configuration. You can run BBOMDHFS or BBOMDZFS to create and mount a new configuration file system, or you can mount one manually. Either way, you must have a configuration file system for your Version 7.0 configuration created and mounted before you proceed. This configuration file system is the target of the migration; your Version 5.1.x or Version 6.x configuration file system is the source.

    BBOMDHFS or BBOMDZFS creates a mount point directory, allocates the configuration's file system, and mounts the file system at whatever value you specified for the mount point when you generated you migrations jobs.

    Ensure that you have allocated, created, and mounted your configuration file system data sets either manually or using BBOMDHFS or BBOMDZFS before you proceed. The mount point should be owned by the WebSphere Admin ID, and have permissions of at least 755. The new configuration file system structures 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 7.0 configuration must use different JCL procedures from those used by your Version 5.1.x or Version 6.x configuration. This utility will update the new Version 7.0 configuration, substituting your new JCL names in place of the names that existed in your original Version 5.1.x or Version 6.x configuration.

    Caution: This utility copies the generated JCL to your procedure library. If you specified the same names as you used in your Version 5.1.x or Version 6.x configuration when you generated your migration jobs, this utility will overlay the existing procedures. If you are using the same names, make sure that you back up the existing Version 5.1.x or Version 6.x procedures before running this utility in case you need to roll back later.

    Submit BBOMDCP, and verify a return code of 0.

  3. If you specified new procedure names, update your RACF® STARTED profiles for the controller and daemon.
    The STARTED profile used by controller regions is based on the procedure name and JOBNAME. 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.1.x or Version 6.x deployment manager controller JCL procedure name is AZDCR, and you specified AZ1DCR for Version 7.0, then you would need to create a STARTED profile for that new procedure name:
                  new controller      same identity used in
                     JCL name         V5.1.x or V6.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 other changes would also be required if you change the user ID.
    • If your original STARTED profile was generic, STARTED AZ*.* ... for example, 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. Perform one of the following actions:
    1. Submit the BBOWMG3D job.

      A deployment manager migration does not require bringing the node into and out of Peer Restart and Recovery (PRR) mode as standalone application server and federated node migrations do. There are two less jobs to submit for a deployment manager migration, therefore, and you are ready to perform the physical migration.

      BBOWMG3D is the job that performs the physical migration of the Version 5.1.x or Version 6.x deployment manager to Version 7.0 based on the information that you supplied when you generated your migration jobs. Submit BBOWMG3D. Verify that you are getting return codes of 0, and review the log files in the migration temp directory on the configuration file system. The migration temporary directory is temporary_directory_location/nnnnn, where temporary_directory_location is the directory specified for the temporary directory location (/tmp/migrate by default) and nnnnn is the numeric value generated for the migration identifier when you generated your migration jobs.

    2. Submit the following three jobs:
      1. Submit the BBOWDPRO job.

        BBOWDPRO creates the WebSphere Application Server home and default profile.

      2. Submit the BBOWDPRE job.

        BBOWDPRE runs the migration pre-upgrade process.

      3. Submit the BBOWDPOS job.

        BBOWDPOS runs the migration post-upgrade and finish-up (change file permission) processes.

  5. [Updated in July 2012] Examine your trace control settings prior to migration. There are specific configuration settings that require manual changes in order to migrate WebSphere Application Server. Use the Administrative console to examine the list of environmental variables as follows:
    1. Click Environment > Manage WebSphere Variables.. On the Configuration Tab check for the ras_trace_outputlocation variable and note its setting if present. If ras_trace_outputlocation is set to TRCFILE you must manually modify the start procedure for the new WebSphere Application Server to include a TRCFILE DD statement.
    Avoid trouble Avoid trouble: The manual modification of the start procedure gotcha
    Note: must be performed before the new WebSphere Application Server and associated daemons are started.
    [Updated in July 2012]
    jul2012
  6. Shut down the old application servers and daemon.

    Ensure that all nodes on the deployment manager's LPAR in the same cell are shut down.

  7. Update daemon JCL procedure if necessary.

    WebSphere Application Server Version 7.0 requires that the daemon process be at the highest level of code of any of the servers that it manages on the same LPAR. It will be at the Version 7.0 level when the deployment manager is started.

    After you migrate all nodes to Version 7.0 and before you remove the previous version's libraries from the system, you must update the daemon JCL procedure. Failure to do so will result in a failure of the daemon to start.

    Note:
    • If you are migrating from Version 5.1.x to Version 7.0, the daemon needs to have a STEPLIB that includes the Version 5.1.x SBBOLD2 and SBBOLPA datasets.
    • If you are migrating from Version 6.0.1.x to Version 7.0, the daemon needs to have a STEPLIB that includes the Version 6.0.1.x SBBOLD2 and SBBOLPA datasets.
    • If a Version 7.0 cell has a Version 7.0 server that is communicating with a Version 6.0.1.x server in a Version 6.0.1.x cell that is on the same system as the Version 7.0 cell, you also need to add the version 6.0.1.x SBBOLD2 and SBBOLPA datasets to the STEPLIB of the Version 7.0 daemon.
  8. Start the new deployment manager.

    Use the existing commands that you would use to start a Version 5.1.x or Version 6.x application server, but replace the RACF STARTED procedure name with the value that you entered in the deployment manager panel for the controller procedure name when you generated your migration jobs. This command starts the Version 7.0 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 BBODMGR:
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
  9. If you are migrating from Version 5.1.x to Version 7.0, restart the node agents.

What to do next

After you verify a successful migration to Version 7.0 and are successfully running a migrated configuration, you should delete the following items:
  • Everything in the source configuration's file system
  • Everything in the target configuration's temporary_directory_location/nnnnn directory, where temporary_directory_location is the directory specified for the temporary directory location (/tmp/migrate by default) and nnnnn is the numeric value generated for the migration identifier when you created your migration jobs
  • The bbomigrt2.sh file



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 Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 2:48:53 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=tmig_z_adm
File name: tmig_z_adm.html