Migrate an older version deployment manager to a newer
version.
Before you begin
Do the following before you start migrating
a deployment manager:
- If you are migrating from version 6.0.2.x,
read Techdoc WP100771: Migrating to WebSphere® Application
Server for z/OS® Version 6.1.
- Install and configure a version 6.2 WebSphere ESB network deployment
configuration of the same type on z/OS.
The newer version (version 6.2) configuration
must have been augmented to use the same database as the older version
(version 6.0.x or 6.1.x)
configuration uses.
Procedure
- On the version 6.0.x or 6.1.x system,
generate the migration jobs from the WebSphere Application Server Customization ISPF
panels:
- 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.
- 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.
- Customize the generated migration jobs to pick up the user
supplied parameters. For a deployment manager, only the job BSBWMG3B needs to be customized.
- 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.
- 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.
- Stop the older version (version 6.0.x or 6.1.x) deployment
manager. See Stopping
a deployment manager.
- Back up the WebSphere ESB database. If necessary, you can then recover the version 6.0.x or 6.1.x data
later.
- Back up the file system on the source
deployment manager.
- Submit the BSBWMG3D job that you edited.
- Examine the output in /tmp/migrate/XXXXX/BSBWMG3D.out and
make sure the migration completed successfully.
- 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.
- 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
- Copy the scripts to your working directory. To
do this, use the following procedure.
- Assign the appropriate permissions to the copies of the files.
For example:
chmod 755 upgradeSchema612.sql
- Edit the values in the files to suit your needs. Remember to convert
them from ASCII to EBCDIC as necessary.
- Run the customized scripts against the database
using the tool of your choice. For example, DBUtility.sh, SPUFI,
or in a batch job.
- 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.
- Start the deployment manager. See Starting deployment managers.
- 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.