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


Migrating stand-alone servers

Migrate an older version stand-alone server to a newer version.

Before you begin

Before you start:
Procedure
  1. Stop the version 6.0.x or 6.1.x server. See Stopping stand-alone servers.
  2. Back up the WebSphere ESB database. If necessary, you can then recover the version 6.0.x or 6.1.x data later.
  3. Generate the migration jobs from the WebSphere Application Server Customization ISPF (Interactive System Productivity Facility) panels:
    1. In a TSO (Time Sharing Option) 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 1 Migrate a stand-alone application server node. The WebSphere Application Server migration jobs are generated in two PDSs (partitioned data sets) that are created when you work through the WebSphere Application Server Customization ISPF panels. For example:
      ZWESB.WAS.V61017.V6T2Z1.MIG.CNTL
      ZWESB.WAS.V61017.V6T2Z1.MIG.DATA
      Where V6T2Z1 is the name of the version 6.0.x or 6.1.x WebSphere ESB server to be migrated.

      Detailed descriptions of each job generated inZWESB.WAS.V61017.V6TxZ1.MIG.CNTL are in the member BBOMBINS.

  4. Customize the generated jobs. For a stand-alone server, only the following three jobs are required:
    • BBOWMG1B
    • BBOWMG2B
    • BBOWMG3B
    1. In the installed WebSphere ESB JCL PDS(ZWESB.*.*.SBPZJCL), locate the three sample WebSphere ESB migration jobs that correspond to the following three jobs:
      • BSBWMG1B
      • BSBWMG2B
      • BSBWMG3B
      These jobs invoke 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 the jobs so that they make use of the parameters generated by the WebSphere Application Server Customization panels, and are now present in the BBOWMGxB job. For example, make sure the parameters generated in the job BBOWMG3B are reflected in the job BSBWMG3B
    Note: BSBWMG1B and BSBWMG2B only need to be run if you had XA Connectors installed in the version 6.0.x or 6.1.x server. BSBWMG3B does the actual migration.
  5. Back up the files on the source WebSphere ESB server. The migration process does not automatically back up the files on the source server, so it is a good practice to back up the files on the source server before running the migration.
  6. Migrate the server. The migration process populates a temporary backup directory using the information it finds in the file system of the source server, and then uses this temporary backup directory to update the file system of the target server. Use the following procedure to migrate the server.
    1. Run the jobs that were generated in the PDSs in Step 3.
    2. If XA connectors were installed on the version 6.0.x or 6.1.x server, run the BSBWMG1B and BSBWMG2B jobs.
    3. Run the BSBWMG3B job.
  7. Verify the migration. The migration process produces numerous diagnostic log files that need to be checked, including the following files:
    • All of the log files in the /tmp/migration/nnnnnn directory that you specified in the migration job.
    • In the event of failure, the log files in the migrated server's logs directory may be helpful. For example: /WebSphere/V61T2Z1/AppServer/profiles/default/logs.
    Important: Most of these files are generated as ASCII files, so you must convert them to EBCDIC if you want to view them from TSO. If the tools that you use to view, edit, and run the scripts require the scripts to be in EBCDIC format, use the iconv command to convert the file to EBCDIC. For example:
    iconv –t IBM-1047 –f ISO8859-1 WASPreUpgradeSummary.log > 
      WASPreUpgradeSummary_EBCDIC.log  
  8. Upgrade the WebSphere ESB databases. When 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. To upgrade a WebSphere ESB database, use the following procedure.
    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 stand-alone server that used DB2 v8:
      /WebSphere/V61T2Z1/AppServer/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_CommonDB.sql
      /WebSphere/V61T2Z1/AppServer/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_DirectDeploy.sql
      /WebSphere/V61T2Z1/AppServer/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_governancerepository.sql
      /WebSphere/V61T2Z1/AppServer/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_Recovery.sql
      /WebSphere/V61T2Z1/AppServer/dbscripts/CommonDB/DB2zOSV8/upgradeSchema612_relationshipService.sql
      /WebSphere/V61T2Z1/AppServer/dbscripts/BusinessSpace/DB2zOSV8/upgradeSchema612.sql
      /WebSphere/V61T2Z1/AppServer/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 upgradeSchema602.sql
      2. Edit the values in the file 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. Copy over any resource adapters that have not been migrated.

    Some resource adapter archives (RARs) references by J2C resources are not copied over during the migration process.

    If your resource adapters have not been migrated, you must manually copy them to the file system of the WebSphere ESB version 6.2 target server.

    For example, to copy the CICS resource adapter into the file system of the target server from the WebSphere/V6T2Z1/AppServer/profiles/default/installedConnectors directory on the source server, you would issue the following commend: cp -r cicseci6021.rar /WebSphere/V61T2Z1/AppServer/profiles/default/installedConnectors/cicseci6021.rar.
  10. Ensure that the started task JCL members for the new version 6.2 server are in USER.PROCLIB. For example, to copy the started task members into USER.PROCLIB, run the job BBOMBCP from ZWPS.WAS.V61017.V6T2Z1.MIG.CNTL.
  11. Start the server.
  12. Check for any startup errors in the SYSLOG output files in the server's address spaces.

Results

The stand-alone server is migrated to version 6.2.

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_sa.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).