After you generate JCL jobs for migrating a deployment manager
to WebSphere Application Server for z/OS Version 6.1, you can perform the
actual migration by running those jobs. When you generated your custom migration
jobs, you also created customized instructions for preparing and running the
migration jobs in the BBOMDINS members of the CNTL data set that was used
to generate your jobs. Follow these customized instructions to complete the
process of migrating your deployment manager to Version 6.1.
- Create and mount a new Version 6.1.x configuration file system.
Before you perform the migration, Version 6.1.x 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 6.1.x configuration created and mounted before you proceed.
This configuration file system is the target of the migration; your Version
5.x or 6.0.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 6.1.x configuration must use
different JCL procedures from those used by your Version 5.x or 6.0.x configuration.
This utility will update the new Version 6.1.x configuration, substituting
your new JCL names in place of the names that existed in your original Version
5.x or 6.0.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 5.x or 6.0.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 5.x or 6.0.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 5.x or
6.0.x deployment manager controller JCL procedure name is AZDCR, and you specified
AZ1DCR for Version 6.1, then you would need to create a STARTED profile for
that new procedure name:
new controller same identity used in
JCL name V5.x or 6.0.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.
- 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. 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 5.x or 6.0.x deployment manager to Version 6.1.x
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.
- 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 6.1.x 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 6.1.x level when the deployment manager
is started. If the deployment manager manages nodes on the same LPAR in a
mixed-cell environment, the daemon started JCL procedure for both the deployment
manager and the down-level nodes must have both the Version 6.1.x libraries
and those of the highest level of the down-level nodes in STEPLIB.
If
you are migrating from Version 5.1 and you have an application server node
on the same LPAR as the deployment manager, for example, add the following
to both your Version 6.1.x and Version 5.1 daemon JCL procedure's "Z" member
("Z=BBO5DMNZ" ) using your library names:
//*STEPLIB Setup
//*
//STEPLIB DD DSN=hlq61.SBBOLD2,DISP=SHR
// DD DSN=hlq61.SBBOLOAD,DISP=SHR
// DD DSN=hlq61.SBBOLPA,DISP=SHR
// DD DSN=hlq51.SBBOLD2,DISP=SHR
// DD DSN=hlq51.SBBOLPA,DISP=SHR
//*
Note: The hlq51.SBBOLOAD
library is intentionally left out of this example. It will not do any harm
if it is there, but it is not needed.
After you migrate all nodes
to Version 6.1.x and before you remove the previous version's libraries from
the system, you must update the daemon JCL procedure and remove the previous
version's libraries from the STEPLIB concatenation. Failure to do so will
result in a failure of the daemon to start.
- Start the new deployment manager.
Use the existing
commands that you would use to start a Version 5.x or 6.0.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 6.1.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 BBODMGR:
BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
At this point, your migration to Version 6.1.x is complete.