Migrate an older version stand-alone server to a newer
version.
Before you begin
Before you start:
- If you are migrating from version 6.0.2.x,
read Techdoc WP100771: Migrating to WebSphere® Application
Server for z/OS® Version 6.1.
- Make sure the source server (server you are
migrating from) is a z/OS stand-alone
server with WebSphere ESB version 6.0.x or 6.1.x installed.
- Make sure the target server (server you are
migrating to) is a z/OS stand-alone
server with WebSphere ESB version 6.2 installed
and configured.
- Make sure that the target server has been augmented
to use the same database as the source server.
Procedure
- Stop the version 6.0.x or 6.1.x server. See Stopping stand-alone servers.
- Back up the WebSphere ESB database. If necessary, you can then recover the version 6.0.x or 6.1.x data
later.
- Generate
the migration jobs from the WebSphere Application Server Customization ISPF
(Interactive System Productivity Facility) panels:
- 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.
- 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.
- Customize the generated jobs. For a stand-alone
server, only the following three jobs are required:
- BBOWMG1B
- BBOWMG2B
- BBOWMG3B
- 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.
- 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.
- 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.
- 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.
- Run the jobs that were generated
in the PDSs in Step 3.
- If XA connectors were installed on the version 6.0.x or 6.1.x server,
run the BSBWMG1B and BSBWMG2B jobs.
- Run the BSBWMG3B job.
- 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
- 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.
- 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
- 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 upgradeSchema602.sql
- Edit the values in the file 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.
- 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.
- 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.
- Start the server.
- 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.