After you generate JCL jobs for migrating a standalone application
server node 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 BBOMBINS members of the CNTL data set
that was used to generate your jobs. Follow these customized instructions
to complete the process of migrating your standalone application server 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 file system
to be present for your new configuration. You can run BBOMBHFS or BBOMBZFS
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 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.
BBOMBHFS or BBOMBZFS 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 data sets either manually or using BBOMBHFS or BBOMBZFS 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 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 BBOMBCP, 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 5.x or 6.0.x controller
JCL procedure name is AZACR and you specified AZ6ACR for Version 6.1, for
example, 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 V6.0.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 BBOWMG1B and BBOWMG2B.
Note: If you are not using
XA connectors, submitting BBOWMG1B and BBOWMG2B is optional. However, you
should submit both jobs to ensure that your transaction logs are clear.
BBOWMG1B
enables all servers on the application server node being migrated to start
in PRR processing mode. PRR processing mode resolves any outstanding transactions,
clears the transaction logs, and terminates the server. BBOWMG2B disables
PRR mode and returns all servers to normal operating state.
Follow
these steps to clear the XA transaction logs:
- Submit the job BBOWMG1B, and verify a return code of 0.
- Restart the application server, and wait for it to perform PRR processing
and terminate automatically.
- Submit the job BBOWMG2B, and verify a return code of 0.
- Stop the Version 5.x or 6.0.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 6.1.x level when
the server is started.
You must stop the Version 5.x or 6.0.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 5.x or 6.0.x server to use a log stream.
- Make sure that the node is shut down.
- Delete and redefine the log stream.
You can use the BBOLOGSD and BBOLOGSA
jobs that were created during Version 5.x or 6.0.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)
/*
- Submit BBOWMG3B.
BBOWMG3B is the job that performs
the physical migration of the Version 5.x or 6.0.x node to Version 6.1.x based
on the information that you supplied when you generated your migration jobs.
Submit BBOWMG3B, 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.
- Start the new application server node.
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
for the controller procedure name when you generated your migration jobs.
This command starts the Version 6.1.x 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 6.1.x is complete.