Before you migrate a WebSphere Application Server for z/OS Version
5.x or 6.0.x node to Version 6.1.x, you must create a migration definition
that contains JCL jobs (CNTL and DATA data sets) that you will run on z/OS
during the actual migration. You can use the z/OS Migration Management Tool
to create and upload the appropriate migration definition. The z/OS Migration
Management Tool presents you with a set of configuration variables when creating
a definition for migrating a standalone application server.
Migration Definition Name and Location
This section
identifies the migration definition name and directory path to contain the
batch jobs and instructions that will be used to migrate a WebSphere Application
Server for z/OS node.
- Migration definition name
- Name of the z/OS migration definition
This name is used solely on the
workstation to identify the migration jobs and instructions that are generated.
The name chosen will have no effect on the WebSphere Application Server for
z/OS configuration.
- Migration definition directory
- Root directory to which the z/OS migration jobs and instructions are to
be written
- Response file pathname (optional)
- Full pathname of a response file that contains default values to be preloaded
in the tool
A response file is written each time a z/OS migration definition
is created. It contains all of the variable data that was used to create the
migration definition, and it can be used to preload the default values when
defining a similar migration definition. The response file for a given migration
definition is written to the migration_definition_name.responseFile file
within the root directory for the migration definition.
Normally, you
should specify a response file from a migration definition of the same type
as that which you are about to define.
Note: A copy of the response file
is included in the .DATA data set that is included in the migration definition
that you upload to a z/OS target system. This response file is not used on
the z/OS system, but it is there for reference. The member name of the data
set is ZMMTBASE.
Target Data Sets
- High-level qualifier (HLQ)
- High-level qualifier for the target z/OS data sets that will contain the
generated jobs and instructions
When a z/OS migration definition is uploaded
to the target z/OS system, the migration jobs and files are written to a pair
of partitioned data sets. While is it possible to reuse these data sets, it
is safest to create separate data sets for each z/OS system that is to be
migrated.
- HLQ.CNTL - a partitioned data set with fixed block 80-byte records
to contain migration jobs
- HLQ.DATA - a partitioned data set with variable length data to
contain other data contained in the migration definition
Note: A multilevel high-level qualifier can be specified as
the data set high-level qualifier.
Data Set Names and Product Directory
- JCL procedure library data set name
- Existing procedure library to which the WebSphere Application Server for
z/OS cataloged procedures are to be copied
- Run WebSphere Application Server from STEPLIB
- Only one version of WebSphere Application Server can exist in the link
list or LPA. All other versions must use STEPLIB. If Version 6.1.x must run
from STEPLIB, indicate that by selecting this option.
Correctly specifying
STEPLIB is essential to a successful migration. It is likely that your Version
5.x or 6.0.x modules are currently in LPA or the link list and that you will
begin with your Version 6.1.x libraries being defined in STEPLIB.
If
this option is selected, then you must enter the runtime library data set
names below.
- SBBOLPA
- Name of the data set that contains the SBBOLPA load modules
- SBBOLOAD
- Name of the data set that contains the SBBOLOAD 31-bit load modules
- SBBGLOAD
- Name of the data set that contains the SBBGLOAD 64-bit load modules
- SBBOLD2
- Name of the data set that contains the SBBOLD2 load modules
- WebSphere Application Server product directory
- Location of your WebSphere Application Server Version 6.1.x installed
product file system
Configuration File System
The configuration file
system is where the configuration for the node being migrated is physically
stored. You can choose to use an existing Version 6.1.x file system if you
already have an appropriate file system on the node being migrated. If you
choose to use an existing Version 6.1.x file system, you need to ensure that
the mount point that you specify here is present before running the migration
utilities (BBOWMG1B, BBOWMG2B, and so on) that are created using this tool.
If you choose to create a new Version 6.1.x file system on the node being
migrated, the actual creation of the new file system will not occur until
you run the optional BBOMBHFS or BBOMBZFS job during the actual migration
process. In any case, you must specify the correct value here for the mount
point.
Refer to the customized instructions generated by this tool for
specific information on setting the correct ownership and permissions on the
configuration mount point. See the generated instructions and Migrating a standalone application server for
more information on specifying these variables.
- Mount point
- Read/write file system directory mount point where application data and
environment files are written
If this mount point does not already exist,
the migration process creates it when you run the optional BBOMBHFS or BBOMBZFS
job.
- Name
- File system data set that you will create and mount at the above mount
point
- Volume, or '*' for SMS
- Specify either the DASD volume serial number to contain the above data
set or "*" to let SMS select a volume.
Using "*" requires that SMS automatic
class selection (ACS) routines be in place to select the volume. If you do
not have SMS set up to handle data set allocation automatically, list the
volume explicitly.
- Primary allocation in cylinders
- Initial size allocation in cylinders for the configuration file system
data set
In an application server, the total space needed for this data
set increases with the size and number of installed applications.
Recommendation: The minimum suggested size is 420
cylinders.
- Secondary allocation in cylinders
- Size of each secondary extent in cylinders
Recommendation: The minimum suggested size is 100 cylinders.
- File system type
- Hierarchical File System (HFS)
- Allocate and mount your configuration file system data set using HFS
- zSeries File System (ZFS)
- Allocate and mount your configuration file system data set using ZFS
Server Customization (Part 1)
- From configuration location
- Mount point
- Mount point of the configuration from which you are migrating
- Home directory
- Home directory of the configuration from which you are migrating
- To configuration location
- Mount point
- Mount point of the configuration to which you are migrating
This was
specified previously on the Configuration File System panel.
- Home directory
- Home directory of the configuration to which you are migrating
- Daemon procedure name
- Name of the JCL started procedure used to start the migrated daemon
When
migrating to Version 6.1.x, you must upgrade your JCL started procedures.
A new started procedure will be generated for you during migration. You can
specify a new name for the daemon procedure or use the old one.
- Controller procedure name
- Name of the JCL started procedure used to start the migrated controllers
When
migrating to Version 6.1.x, you must upgrade your JCL started procedures.
A new started procedure will be generated for you during migration. You can
specify a new name for the controller procedure or use the old one.
- Servant procedure name
- Name of the JCL started procedure used to start the migrated servants
When
migrating to Version 6.1.x, you must upgrade your JCL started procedures.
A new started procedure will be generated for you during migration. You can
specify a new name for the servant procedure or use the old one.
- Adjunct procedure name
- Name of the JCL started procedure used to start the migrated adjunct
When
migrating to Version 6.1.x, you must upgrade your JCL started procedures.
A new started procedure will be generated for you during migration. You can
specify a new name for the adjunct procedure or use the old one.
- Replace started procedure command names
- If you specified new names for your JCL procedures, then the corresponding
START commands in the WebSphere Application Server configuration must be updated
to match the new procedure names. Select this option to perform this configuration
update.
If you choose to use the same procedure names, then do not select
this option. If you are not using consistent procedure names for all the servers
of a given process type (all servants for example) for the node that you are
migrating, then it is recommended that you do not select this option. In this
case, you will need to keep the same START commands and manually replace the
procedures using the procedure that is generated during migration as a template.
Server Customization (Part 2)
- Migrate to support script compatibility
- Whether or not to migrate to support script compatibility
This specifies
whether or not migration should create the following Version 5.x or 6.0.x
configuration definitions:
- Transport
- ProcessDef
- Version 5.x or 6.0.x SSL
- Version 5.x or 6.0.x ORB service threadpool
instead of the following Version 6.1.x configuration definitions:
- Channels
- ProcessDefs
- Version 6.1.x SSL
- Version 6.1.x ORB service threadpool
Choose to migrate to support script compatibility if you want
to minimize impacts to existing administration scripts. If you have existing wsadmin scripts
or programs that use third-party configuration APIs to create or modify the
Version 5.x or 6.0.x configuration definitions, for example, you might want
to choose this option.
Note: This is meant to provide a temporary transition
until all of the nodes in the environment are at the Version 6.1.x level.
When they are all at the Version 6.1.x level, you should perform the following
actions:
- Modify your administration scripts to use all of the Version 6.1.x settings.
- Use the convertScriptCompatability command to
convert your configurations to match all of the Version 6.1.x settings.
See convertScriptCompatibility command.
- Application migration preference
- How you would like to migrate your installed applications
Note: WebSphere
Application Server system applications will migrate regardless of the value
set here.
- Migrate applications and use the specified application installation directory
- Install user enterprise applications in the Application Installation Directory
as part of the migration
- Application installation directory
- Location where WebSphere Application Server installs your enterprise applications
This
location is used when you specify that you want to migrate and install applications
as your application migration preference. You have the option to choose a
customized environment-specific location or use the default location.
- Migrate and generate administrative scripts to install applications later
- Prepare user enterprise applications for installation in the WebSphere
Application Server Version 6.1.x installableApps directory
without actually installing them during migration
JACL scripts that can
be used to install these applications are generated and saved in the migration
backup directory. For WebSphere Application Server for z/OS, the location
of this backup directory is relative to the temporary directory that you specify
on this same panel. The location of the backup directory is also determined
by the derived migration identifier and the type of node being migrated. If
you specify
/tmp/migrate as the temporary directory and
the derived migration identifier is 55449, for example, then the location
of the generated JACL scripts is:
/tmp/migrate/55449/nodetype_backup/
where
nodetype is
dmgr, fed, or base depending on the type of node that you are migrating.
You
can then run these files at any point and in any combination after migration
has completed. You can also reorganize and combine these JACL files for better
application installation efficiency. Here is an example of how to use the
wsadmin tool to run a generated JACL script to install an application:
wsadmin -f install_ivtApp.ear.jacl
- Migrate applications and use the previous application installation directory
- Install user enterprise applications as part of the migration, and keep
the same application installation directories as the previous version
Restrictions: If you select this option, the location
is shared by the existing WebSphere Application Server Version 5.x or 6.0.x
installation and the Version 6.1.x installation. If you keep the migrated
applications in the same locations as those of the previous version, the following
restrictions apply:
- The WebSphere Application Server Version 6.1.x mixed-node support limitations
must be followed. This means that the following support cannot be used when
evoking the wsadmin command:
- Precompile JSP
- Use Binary Configuration
- Deploy EJB
- You risk losing the migrated applications unintentionally if you later
delete applications from these locations when administering (uninstalling
for example) your Version 5.x or 6.0.x installation.
- Any application that is installed relative to a Version 5.x or 6.0.x
variable will be installed relative to the location assigned to that variable
in Version 6.1. In other words, the absolute location is not preserved—the
application is migrated to the relative location within the new Version 6.1
environment.
If the binariesURL in the
deployment.xml file
for an application being migrated has a path that is relative to WebSphere
Application Server—that is, it begins with
$(APP_INSTALL_ROOT),
$(WAS_INSTALL_ROOT),
and so on—the new WebSphere Application Server variable value is used to resolve
the path when the application is installed in the new location. This leads
to the following results when you select this option:
- Any application that is installed in a directory location relative to
a WebSphere Application Server variable is installed under that variable value
in Version 6.1.x.
- Any application that is installed in a directory location that is not
relative to a WebSphere Application Server variable is migrated and overwritten
in that same directory. If an application is installed in the /employee_records/retrieval_Apps directory,
for example, the application is migrated and overwritten in the /employee_records/retrieval_Apps directory.
- Do not migrate applications
- Do nothing with user enterprise applications
- Migration trace options
- Enable script tracing
- Enable or disable trace of the home creation, profile and migration tooling
invocation, and final processing phases of migration
- Enable profile creation tracing
- Enable or disable trace trace during profile creation
- Enable pre-upgrade tracing
- Enable or disable trace during the WASPreUpgrade process
- Enable post-upgrade tracing
- Enable or disable trace during the WASPostUpgrade process
- Temporary directory location
- Directory where the backup of your previous configuration is written as
well as the migration trace and temporary file output
- Migration definition identifier
- Identifier that is used to separate the output of individual node migrations
It
is the name of the subdirectory created under the specified temporary directory
location.
Job Statement Definition
All the migration jobs that
will be tailored for you will need a job statement.
Enter a valid job statement
for your installation. The migration creation process will update the job
name for you in all the generated jobs, so you do not need to be concerned
with that portion of the job statement. If continuation lines are needed,
replace the comment lines with continuation lines.