After you use the Customization Dialog to generate JCL jobs for
migrating a deployment manager to WebSphere Application Server for z/OS Version
6.0.x, you can perform the actual migration by running those jobs.
About this task
The deployment manager node is always migrated first. Review the
applicable coexistence requirements
for your system. If you are migrating from Version 5.0.2 or lower, you need
to migrate other nodes in the same cell and on the same MVS image as the deployment
manager sequentially, one immediately after the other.
The BBOWMG3D
job referenced below 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 5.x to Version 6.0.x: Migrating a deployment manager from Version 5.x to Version
6.0.x redeploys all application binaries when the deployment manager is restarted.
This action results in the deployment manager recycling all the applications
across the sysplex and causes an outage in a sysplex that is set up for high
availability.
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.
- Create and mount a new Version 6.0.x HFS.
Before
you perform the migration, Version 6.0.x requires an HFS to be present for
your new configuration. You can run BBOWMDMT to create and mount a new HFS,
or you can mount one manually. Either way, you must have an HFS for your Version
6.0.x configuration created and mounted before you proceed. This HFS is the
target of the migration; your Version 5.x configuration HFS is the source.
BBOWMDMT
creates a mount point directory, allocates the configuration's HFS, and mounts
the HFS at whatever value you specified on the field called "Mount Point"
in the "System Environment Customization" panel in the Customization Dialog.
Before
you proceed, ensure that you have, either manually or using BBOWMDMT, allocated,
created, and mounted your HFS data sets. The mount point should be owned by
the WebSphere Admin ID, and have permissions of at least 755. The new HFS
structures in 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 6.0.x configuration must make
use of different JCL start procedure names; this utility will update the new
Version 6.0.x configuration, substituting your new JCL names in place of the
names that existed in your original Version 5.x configuration. Submit BBOMDCP,
and verify a return code of 0.
- Update your RACF STARTED profiles.
The STARTED profile
used by controller regions is based on the procedure name and JOBNAME. Because
Version 6.0.x requires new start procedures, 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 5.x deployment manager controller JCL procedure
name is AZDCR, and you specified AZ1DCR for Version 6.0.x, then you would
need to create a STARTED profile for that new procedure name:
new controller same identity used in
JCL name V5.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 if you change the user ID other changes would also be required.
- If your original STARTED profile was generic, for example, STARTED AZ*.*
... , 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.
- Stop the Version 5.x deployment manager.
You must
stop the Version 5.x deployment manager before submitting BBOWMG3D.
- Submit BBOWMG3D.
A deployment manager migration does
not require bringing the node into and out of PRR mode as standalone application
server and federated node migrations do. Hence, there are two less jobs to
submit for a deployment manager migration, and, at this point, you are ready
to perform the physical migration.
BBOWMG3D is the job that performs
the physical migration of the Version 5.x deployment manager to Version 6.0.x,
based on the information you supplied in the Customization Dialog. Submit
BBOWMG3D. Verify that you are getting return codes of 0, and review the log
files in the migration temp directory on the HFS (this directory is /tmp/migrate/directory,
where directory is the numeric value specified in the Deployment
Manager Customization panel in the Customization Dialog.
- Update the deployment manager's servant keyring.
If
you use separate user IDs to run your deployment manager's controller and
servant regions, you must add a WASKeyring to the deployment manager's servant
user ID then connect the WebSphere CA certificate to the WASKeyring:
RACDCERT ADDRING(WASKeyring) ID(dmgr_servant_user_ID)
RACDCERT ID(dmgr_servant_user_ID) CONNECT(RING(WASKeyring) LABEL('WebSphereCA') CERTAUTH)
- Shut down the application servers and daemon.
The
daemon must be at the highest version level of any of the servers that it
manages on the same LPAR. It will be at the Version 6.0.x level when the deployment
manager is started. At this point, ensure that all nodes on the deployment
manager's LPAR have been shut down.
- Start the deployment manager.
Use the existing commands
that you would use to start a Version 5.x Application Server, but replace
the RACF STARTED procedure name with the value you entered in the Deployment
Manager Customization Dialog (2 of 2) for Controller Procedure name. This
command starts the Version 6.0.x 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 BBOS001:
BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
At this point, your migration to Version 6.0.x is complete.
- Perform the post-migration tasks.
After you have
verified a successful migration to Version 6.0.x, and are successfully running
a migrated configuration, you should delete:
- Everything in the source configuration's HFS
- Everything in the target configuration's /tmp/migrate/nnnnn/ directory
- The bbomigrt2.sh file
WebSphere Application Server for z/OS Version 6.0.x requires that
the daemon process be at the highest level of code of any of the servers that
it manages. If your Version 6.0.x deployment manager manages any Version 5.1
nodes on the same LPAR, you must update the Version 5.1 daemon STARTED procedure
to STEPLIB to the Version 6.0.x libraries.
For example, add the following
to your Version 5.1 daemon procedure's "Z=BBO5DMNZ" member, using your library
names:
//*STEPLIB Setup
//*
//STEPLIB DD DSN=hlq.SBBOLD2,DISP=SHR
// DD DSN=hlq.SBBOLOAD,DISP=SHR
// DD DSN=hlq.SBBOLPA,DISP=SHR
//*