Before you begin
Supported configurations: This
topic is about configuration migration, such as migrating deployment
managers and federated nodes in a network deployment environment.
The Application Migration Toolkit for WebSphere Application Server
provides support for migrating applications from previous versions
of WebSphere Application Server to the latest product version. For
information about migrating applications, read more about the Application
Migration Toolkit.
sptcfg
- Read Overview of migration, coexistence, and interoperability and Premigration considerations.
- You will not be able to proceed if you did not generate the Job
Control Language (JCL) migration jobs.
- Always migrate the deployment manager node first.
- Review the applicable coexistence requirements
for your system.
- The BBOWMG3D job referenced in these instructions must be submitted
by a WebSphere Administrator User ID.
All
other jobs must be submitted by a user ID that has control over the
file system.
- Note on maintaining high availability during migration from Version
6.x or 7.x to Version 8.0:
Migrating a deployment manager from Version
6.x or 7.x to Version 8.0 redeploys all application binaries when
the deployment manager is restarted. This action results in the deployment
manager recycling all the applications across the sysplex. This can
cause an outage in a sysplex that is set up for high availability
if the synchronization settings are not disabled.
To maintain
high availability during the migration, turn off all synchronization
options for all of the node agents in the sysplex before restarting
the deployment manager.
- Open the administrative console.
- Go to System administration > Node agents.
- For each node agent in the sysplex, go to node_agent_server_name >
File synchronization service and disable all synchronization processing.
- Tip: Before migrating a WebSphere Application
Server Version 6.x or 7.x deployment manager, use the backupConfig command
or your own preferred backup utility to back up your existing configuration
if you want to be able to restore it to its previous state after migration.
Read the "backupConfig command" article in the information center
for more information. Make sure that you note the exact name and location
of this backed-up configuration.
For help, read Troubleshooting migration.
- Create and mount a new Version 8.0 configuration file system.
Before you perform the migration, Version 8.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 8.0 configuration created
and mounted before you proceed. This configuration file system is
the target of the migration; your Version 6.x or Version 7.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.
- 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 8.0 configuration
must use different JCL procedures from those used by your Version
6.x or Version 7.x configuration. This utility will update the new
Version 8.0 configuration, substituting your new JCL names in place
of the names that existed in your original Version 6.x or Version
7.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 6.x or Version
7.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 6.x or Version 7.x
procedures before running this utility in case you need to roll back
later.
Submit BBOMDCP, and verify a return code of 0.
- 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 6.x or Version 7.x deployment manager controller
JCL procedure name is AZDCR, and you specified AZ1DCR for Version
8.0, then you would need to create a STARTED profile for that new
procedure name:
new controller same identity used in
JCL name V6.x or V7.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.
- Perform one of the following actions:
- 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 stand-alone 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 6.x or Version
7.x deployment manager to Version 8.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.
- Submit the following three jobs:
- Submit the BBOWDPRO job.
BBOWDPRO creates the Websphere Application
Server home and default profile.
- Submit the BBOWDPRE job.
BBOWDPRE runs the migration pre-upgrade
process.
- Submit the BBOWDPOS job.
BBOWDPOS runs the migration post-upgrade
and finish-up (change file permission) processes.
- 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.
- Update daemon JCL procedure if necessary.
WebSphere Application Server for z/OS Version
8.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 8.0 level when the deployment manager is started.
After
you migrate all nodes to Version 8.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 6.x or 7.x to Version 8.0, the
daemon needs to have a STEPLIB that includes the Version 7.x SBBOLD2
and SBBOLPA datasets.
- If a Version 8.0 cell has a Version 8.0 server that is communicating
with a Version 6.0.1.x or 7.x server in a Version 6.0.1.x or 7.x cell
that is on the same system as the Version 8.0 cell, you also need
to add the version 6.0.1.x SBBOLD2 and SBBOLPA datasets to the STEPLIB
of the Version 8.0 daemon.
- Start the new deployment manager.
Use the
existing commands that you would use to start a Version 6.x or Version
7.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 8.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