After the deployment manager is migrated and restarted, you can
perform the actual migration of the federated application server node by running
the JCL jobs that you generated using the Customization Dialog.
About this task
Note: At this point, ensure that the application servers and the
node agent are stopped.
The BBOWMG1F, BBOWMG2F, and BBOWMG3F jobs
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.
- Ensure that the newly migrated deployment manager is up and running.
In order for the application server node to be properly migrated,
the deployment manager must be running. In order for this migration to work,
the deployment manager must be up and listening on its SOAP port.
Check Off |
Item |
|
Access the administrative console of the Version 6.0.x
deployment manager. This validates that the deployment manager is running. |
Check Off |
Item |
|
Ensure that the Version 6.0.x copy of the code is running.
Under "About your WebSphere Application Server," the build number should begin
with W601. |
- 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 BBOWMMMT 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.
BBOWMMMT
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 BBOWMMMT, 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 BBOMMCP 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 BBOMMCP,
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 controller JCL procedure name is AZACR,
and you specified AZ6ACR 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 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, 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.
- Submit BBOWMG1F.
Note: If you are not using XA connectors,
submitting BBOWMG1F and BBOWMG2F is optional. However, you should submit both
jobs to ensure that your transaction logs are clear.
Unlike in previous
WebSphere Application Server for z/OS migrations, you no longer have to customize
the migration utilities. This makes the migration process much more simple.
BBOWMG1F, for example, is to be submitted as is.
BBOWMG1F enables all
servers on the federated 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. To enable PRR processing
mode, follow these steps:
- Stop the federated application server.
- Submit the job BBOWMG1F as is, verify return code of 0.
- Restart the federated application server, wait for it to perform PRR processing
and terminate automatically.
- Submit BBOWMG2F.
BBOWMG2F disables PRR mode and returns
all servers to normal operating state. Submit this job and verify a return
code of 0. You do not need to start the servers again after this job completes.
- Stop the Version 5.x managed node.
You must stop
the Version 5.x managed node 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 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 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)
/*
If you are migrating nodes in a sysplex, follow this procedure for
each federated node that you migrate.
- Submit BBOWMG3F.
BBOWMG3F is the job that performs
the physical migration of the Version 5.x node to Version 6.0.x, based on
the information you supplied in the Customization Dialog. Submit BBOWMG3F.
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 Federated
Node Customization panel in the Customization Dialog.
- 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 this
managed node is started. At this point, ensure that all nodes on the deployment
manager's LPAR have been shut down.
- Start the managed application server node.
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 Federated Node Customization Dialog (2 of 2) for Controller Procedure
name. This command starts the Version 6.0.x federated 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.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 there are any Version 5.1 nodes on the same LPAR and in the
same cell as this migrated managed node, you must update the Version 5.1 daemon
STARTED procedure to STEPLIB to the Version 6 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
//*