After you generate Job Control Language (JCL) jobs for
migrating a stand-alone application server node to WebSphere® Application
Server for z/OS® Version 8.0, 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 BBOMBINS members of the CNTL dataset that
was used to generate your jobs. Follow these customized instructions
to complete the process of migrating your stand-alone application
server to Version 8.0.
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
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
file system to be present for your new configuration. You can run
the BBOMBHFS or BBOMBZFS job to create and mount a new configuration
file system, or you can mount one manually. Either way, you must have
a 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 7.x configuration file system is
the source.
The BBOMBHFS or BBOMBZFS job 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 your migration jobs.
Ensure that you allocated,
created, and mounted your configuration file system datasets either
manually or using the BBOMBHFS or BBOMBZFS job 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 BBOMBCP copies the generated JCL procedures used 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 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 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 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 7.x procedures before running this utility in case
you need to roll back later.
Submit the BBOMBCP job, 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. If
your Version 6.x or 7.x controller JCL procedure name is AZACR and
you specified AZ6ACR for Version 7, for example, 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 AZ6ACR.* STDATA(USER(AZACRU) 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, 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 the BBOWMG1B and BBOWMG2B jobs.
Note: If
you are not using XA connectors, submitting the BBOWMG1B and BBOWMG2B
jobs is optional. However, you should submit both jobs to ensure
that your transaction logs are clear.
The BBOWMG1B job enables
all servers on the application server node being migrated to start
in Peer Restart and Recovery (PRR) processing mode. PRR processing
mode resolves any outstanding transactions, clears the transaction
logs, and stops the server. The BBOWMG2B job disables PRR mode and
returns all servers to normal operating state.
Follow these
steps to clear the XA transaction logs:
- Submit the BBOWMG1B job, and verify a return code of 0.
- Restart the application server, and wait for it to perform PRR
processing and stop automatically.
- Submit the BBOWMG2B job, and verify a return code of 0.
- Stop the Version 6.x or 7.x daemon and application server.
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
8.0 level when the server is started.
You must stop the Version
6.x or 7.x application server before proceeding.
- Delete and redefine the log stream.
Perform
this step only if you previously configured the transaction XA partner
log or compensation log on the Version 6.x or 7.x server to use a
log stream.
- Make sure that the node is stopped.
- Delete and redefine the log stream.
You can use the BBOLOGSD
and BBOLOGSA jobs that were created during Version 6.x or 7.x customization
if you configured the server initially to use the log stream.
The
following sample shows an example of such a job:
//RLSP1A JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
// CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
//STEP1 EXEC PGM=IXCMIAPU
//STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DATA TYPE(LOGR) REPORT(YES) /* Default to show output of job */
DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
LOWOFFLOAD(20)
HIGHOFFLOAD(79)
STG_DUPLEX(YES)
DUPLEXMODE(UNCOND)
STG_DATACLAS(OPERLOG)
STG_SIZE(5000)
HLQ(Q10RRS)
LS_SIZE(5000)
LS_DATACLAS(OPERLOG)
STRUCTNAME(WAS_LOGRLS)
/*
- Perform one of the following actions:
- Submit the BBOWMG3B job.
The BBOWMG3B
job performs the physical migration of the Version 6.x or 7.x node
to Version 8.0 based on the information that you supplied when you
generated your migration jobs. Submit the BBOWMG3B job, verify that
you are getting return codes of 0, and review the log files in the
migration temporary directory on the 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 BBOWBPRO job.
BBOWBPRO creates the Websphere Application
Server home and default profile.
- Submit the BBOWBPRE job.
BBOWBPRE runs the migration pre-upgrade
process.
- Submit the BBOWBPOS job.
BBOWBPOS runs the migration post-upgrade
and finish-up (change file permission) processes.
- Start the new application server node.
Use
the existing commands that you would use to start a Version 6.x or
7.x application server, but replace the RACF STARTED
procedure name with the value that you entered for the controller
procedure name when you generated your migration jobs. This command
starts the Version 8.0 application server. 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 8.0 is complete.