Before you migrate a WebSphere® Application
Server for z/OS®, you must create Job Control Language (JCL)
jobs (CNTL and DATA datasets) that you will run on z/OS during
the actual migration. You can use the z/OS Migration
Management Tool to create a migration definition and upload the appropriate
migration jobs. The z/OS Migration Management Tool
presents you with a set of configuration variables when creating a
definition for migrating a deployment manager.
Migration Node Type Selection
- Migration node type
- Type of Websphere Application Server node to migrate
Migration Definition Name
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.
- Response file path name (optional)
- Full path name 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 dataset 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 dataset is ZMMTDMGR.
Target Datasets
- High-level qualifier (HLQ)
- High-level qualifier for the target z/OS datasets
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
datasets. While is it possible to reuse these datasets, it is safest
to create separate datasets for each z/OS system
that is to be migrated.
- HLQ.CNTL - a partitioned dataset with fixed block 80-byte
records to contain migration jobs
- HLQ.DATA - a partitioned dataset with variable length data
to contain other data contained in the migration definition
Note: A multilevel high-level qualifier can be specified
as the dataset high-level qualifier.
Dataset Names and Product Directory
- JCL procedure library dataset name
- Existing procedure library to which the WebSphere Application
Server for z/OS cataloged procedures are to be copied
- WebSphere Application Server product directory
- Location of your WebSphere Application
Server Version 7.0 installed product file system
- Intermediate symbolic link
- Select this option to allow to set up an intermediate symbolic
link, and specify the path name of that link if you select it.
If
you specify an intermediate symbolic link, symbolic links are created
from the configuration file system to the intermediate symbolic link;
otherwise, they are created directly to the product file system.
Selecting
this option will allow you to specify the path name of an intermediate
symbolic link. This link will be created by the customization jobs,
pointing to the product file system directory.
- Path name of intermediate symbolic link
- Path name of intermediate symbolic link
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 7.0 file system if you already have an appropriate file system
on the node being migrated. If you choose to use an existing Versions
7.0 file system, you need to ensure that the mount point that you
specify here is present before running the migration utilities (BBOMDHFS
or BBOMDZFS, BBOMDCP, and so on) that are created using this tool.
If you choose to create a new Version 7.0 file system on the node
being migrated, the actual creation of the new file system will not
occur until you run the optional BBOMDHFS or BBOMDZFS 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. Read the
generated instructions and Migrating a z/OS deployment manager 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 BBOMDHFS or BBOMDZFS job.
- Name
- File system dataset 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
dataset 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 dataset allocation
automatically, list the volume explicitly.
- Primary allocation in cylinders
- Initial size allocation in cylinders for the configuration file
system dataset
In an application server, the total space needed
for this dataset 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 using HFS
- zSeries® File System (ZFS)
- Allocate and mount your configuration file system 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 7.0, 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 7.0, 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 7.0, 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.
- 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.
Notes:
- Your Version 7.0 configuration must use different JCL procedures
from those used by your Version 5.1.x or Version 6.x configuration.
The migration process creates new Version 7.0 JCL procedures using
the procedure names specified here.
- If you use the same names as you used in your Version 5.1.x or
Version 6.x configuration, the migration process overlays the existing
procedures. If you are using the same names, make sure that you back
up the existing Version 5.1.x or Version 6.x procedures before running
the migration jobs in case you need to roll back later.
- WebSphere administrator's user ID
- The migration process requires the use of an administrative client.
Specify a valid WebSphere administrator's user ID that
the administrative client can use to authenticate.
If you want,
you can defer entering a user ID at this point and manually edit the
BBOWMG3D, BBOWDPRO, BBOWDPRE, or BBOWDPOS jobs later. To do this,
update the TO_AdminUserid variable with the proper
user ID before submitting the job.
- WebSphere administrator's password
- The migration process requires the use of an administrative client.
Specify a valid WebSphere administrator's password that
the administrative client can use to authenticate.
If you want,
you can defer entering a password at this point and manually edit
the BBOWMG3D, BBOWDPRO, BBOWDPRE, or BBOWDPOS jobs later. To do this,
update the TO_AdminPassword variable with the proper
password before submitting the job.
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.1.x or Version 6.x configuration definitions:
- Transport
- ProcessDef
- Version 5.1.x or Version 6.x SSL
- Version 5.1.x or Version 6.x ORB service
threadpool
instead of the following Version
7.0 configuration definitions:
- Channels
- ProcessDefs
- Version 7.0 SSL
- Version 7.0 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.1.x or Version 6.x configuration definitions, for example,
you might want to choose this option.
If
you want to use a cell that contains Version 5.1.x or Version 6.x
nodes, you must specify true for this variable.
Note: This is meant to provide a temporary transition
until all of the nodes in the environment are at the Version 7.0 level.
When they are all at the Version 7.0 level, you should perform the
following actions:
- Modify your administration scripts to use all of the Version 7.0
settings.
- Use the convertScriptCompatability command
to convert your configurations to match all of the Version 7.0 settings.
Read convertScriptCompatibility command for more information.
- Disable previous deployment manager
- Whether or not to disable the previous deployment manager during
migration
If the Version 5.1.x or Version
6.x deployment manager is not disabled, you can continue to use it
while the migration is completed.
Caution: Use
this option with care. The reason that WebSphere Application
Server Version 5.1.x or Version 6.x deployment managers normally are
stopped and disabled is to prevent multiple deployment managers from
managing the same nodes. You must stop the Version 5.1.x or Version
6.x deployment manager before you start using the Version 7.0 deployment
manager. Deselecting this option means that any configuration changes
made in the old configuration during migration might not be migrated.
- 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 default application installation
directory
- Install user enterprise applications in the default application
installation directory as part of the migration
- Migrate applications and use the specified application installation
directory
- Install user enterprise applications in a specified 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 7.0 installableApps directory without
actually installing them during migration
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 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
files for better application installation efficiency. Read the "Wsadmin
tool" article in the information center for additional information.
- 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.1.x
or Version 6.x installation and the Version 7.0 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 7.0
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.1.x or Version 6.x installation.
- Any application that is installed relative to a Version 5.1.x
or Version 6.x variable will be installed relative to the location
assigned to that variable in Version 7.0. In other words, the absolute
location is not preserved—the application is migrated to the relative
location within the new Version 7.0 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 7.0.
- 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
If you choose to enable tracing, it will remain enabled throughout
the entire migration process.
- 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
- Migrate administrative console customized "My tasks" settings
- "My tasks" is only supported in WebSphere Application
Server Version 6.1 and later.
- Migrate the settings for "My tasks" saved in the default workspace
user root location (wstemp)
- Migrate the settings for "My tasks" saved in a user defined workspace
root location
- User defined workspace root location
- Temporary directory location
- Directory where the backup of your previous configuration is written
as well as the migration trace and temporary file output
During migration, a backup copy of the Version
5.1.x or Version 6.x configuration is required. The default location
of this backup is already specified, though you can override if needed.
You might need to specify a location other than the default if the /tmp file
system does not have adequate space to store the backup configuration.
If you choose to override the default location of the backup copy,
the best practice is to keep the same naming convention and just replace
the /tmp portion with another path, /myTemp/migrate for
example.
- Migration definition identifier
- Identifier that will be used to create a directory under the temporary
directory that will contain the temporary migration datasets and backup
configuration data
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.