WebSphere Enterprise Service Bus for z/OS, Version 6.2.0 Operating Systems: z/OS


Migrating a deployment manager

Migrate an older version deployment manager to a newer version.

Before you begin

Do the following before you start migrating a deployment manager:
Procedure
  1. On the version 6.0.x or 6.1.x system, generate the migration jobs from the WebSphere Application Server Customization ISPF panels:
    1. In a TSO session, enter the following command:
      'ex 'high_level_qualifier.sbboclib(bbowstrt)' 'appl(bb61) lang(enus)'
      Where high_level_qualifier is the high-level qualifier of the WebSphere Application Server installation libraries.
    2. Select 4 - Migrate a Node, then select 2 - Migrate a deployment manager. The WebSphere Application Server migration jobs are generated in two PDS data sets that you create when you work through the WebSphere Application Server Customization ISPF panels.
  2. Customize the generated migration jobs to pick up the user supplied parameters. For a deployment manager, only the job BSBWMG3B needs to be customized.
    1. In the installed WebSphere ESB JCL PDS(ZWESB.**.SBPZJCL), locate the sample WebSphere ESB migration job BSBWMG3D. This job invokes the WebSphere ESB script wbimigrt2.sh, which is very similar to the WebSphere Application Server script bbomigrt2.sh. The wbimgrt2.sh script invokes the migration utilities WBIPreUpgrade.sh and WBIPostUpgrade.sh.
    2. Edit your copy of the sample job BSBWMG3D to make use of the parameters generated by the WebSphere Application Server Customization panels, which are now present in the BSBWMG3B job. Make sure that you use the administrator user name and password for the user name and password values for the WBIPostUpgrade command.
  3. Stop the older version (version 6.0.x or 6.1.x) deployment manager. See Stopping a deployment manager.
  4. Back up the WebSphere ESB database. If necessary, you can then recover the version 6.0.x or 6.1.x data later.
  5. Back up the file system on the source deployment manager.
  6. Submit the BSBWMG3D job that you edited.
  7. Examine the output in /tmp/migrate/XXXXX/BSBWMG3D.out and make sure the migration completed successfully.
  8. Upgrade the WebSphere ESB databases. If any of the WebSphere ESB databases need upgrading, SQL scripts are generated in the WebSphere servername/DeploymentManager/dbscripts directory of the version 6.2 server (where servername is the name of the new version 6.2 server). These SQL scripts are generated in database-specific directories.
    1. Check the database-specific directories for any SQL files starting with the name upgrade and containing the version number of the source server. The following example is a list of SQL files that were generated during a migration from a version 6.1.2 WebSphere ESB deployment manager that used DB2 v8:

      /WebSphere/servername/DeploymentManager/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_CommonDB.sql

      /WebSphere/servername/DeploymentManager/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_DirectDeploy.sql

      /WebSphere/servername/DeploymentManager/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_governancerepository.sql

      /WebSphere/servername/DeploymentManager/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_Recovery.sql

      /WebSphere/servername/DeploymentManager/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_relationshipService.sql

      /WebSphere/servername/DeploymentManager/dbscripts/BusinessSpace/DB2zOSV8/upgradeSchema612.sql

      /WebSphere/servername/DeploymentManager/dbscripts/BusinessSpace/DB2zOSV8/upgradeData612.sql

    2. Copy the scripts to your working directory. To do this, use the following procedure.
      1. Assign the appropriate permissions to the copies of the files. For example:
        chmod 755 upgradeSchema612.sql
      2. Edit the values in the files to suit your needs. Remember to convert them from ASCII to EBCDIC as necessary.
      3. Run the customized scripts against the database using the tool of your choice. For example, DBUtility.sh, SPUFI, or in a batch job.
  9. Update the started task JCL members in USER.PROCLIB by running the BBOMDCP job from the jcl library that was generated. The job replaces the version 6.0.x or 6.1.x started task members with the new version 6.2 members.
  10. Start the deployment manager. See Starting deployment managers.
  11. Update the default_host Virtual Host Group from the Administration Console. To prevent a known File Copy error occurring when you migrate your Managed Nodes, delete the Administration Console Ports from the default_host Virtual Host Group, as documented in the Technote 1329834.

Results

The deployment manager is migrated to version 6.2.

What to do next

Next, migrate each of the managed nodes in the cell. See Migrating a managed node.

task Task topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/doc/tmig_zos_vtv_dmgr.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).