Before you migrate a WebSphere® Application Server for z/OS®
Version 7.0 or later node to Version 9.0, you must create Job Control Language (JCL) jobs (CNTL
and DATA datasets) that you run on z/OS during the 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 you create a definition to migrate a stand-alone
application server.
Supported configurations:
This topic is about profile configuration migration. To migrate your applications
to the latest version, use the WebSphere Application
Server Migration Toolkit.
Migration Node Type Selection
- Migration node type
- Type of WebSphere Application Server node to migrate
- Clone migration
- Select this option to do a clone migration of an existing profile. Clone migration allows the
existing and new environment to run concurrently. If the stand-alone application server is
registered to an administrative agent, it cannot be cloned.
This section identifies the migration definition name and directory path to contain the
batch jobs and instructions that you can use 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 that is chosen has 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 preinstalled 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 is used to create the migration definition, and it can be used to preinstall the
default values when you define 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 must 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 ZMMTBASE.
Target Datasets
- High-level qualifier (HLQ)
- High-level qualifier for the target z/OS datasets that contains 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 that are
contained in the migration definition
Note: A multilevel high-level qualifier can be specified as the dataset high-level
qualifier.
Configuration File System
The configuration file system is where the configuration for the node that is being migrated is
physically stored. You can choose to use an existing Version 9.0 file system if you already have an appropriate file system on the node that is being migrated. If
you choose to use an existing Version 9.0 file system, you need
to ensure that the mount point that you specify here is present before you run the migration
utilities (BBOWMG1B, BBOWMG2B, and so on) that are created by using this tool. If you choose to
create a new Version 9.0 file system on the node that is being
migrated, the actual creation of the new file system does 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. Read the generated
instructions and Migrating a stand-alone application server on the z/OS operating system 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 exist, the migration process creates it when you run the
optional BBOMBHFS or BBOMBZFS job.
- Name
- File system dataset that you create and mount at the mount point.
- Volume, or '*' for SMS
- Specify either the DASD volume serial number to contain the dataset or "*" to allow SMS to
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 that is 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 dataset by using HFS
- zSeries
File System (ZFS)
- Allocate and mount your configuration file system dataset by using ZFS.
- Storage class name (optional)
- The name of the SMS storage class for the configuration file system. If you do not assign a
name, the value is determined by the automatic class selection routines established by your storage
administrator.
- Managment class name (optional)
- The name of the SMS management class for the configuration file system. If you do not assign a
name, the value is determined by the automatic class selection routines established by your storage
administrator.
- Data class name (optional)
- The name of the data class for the configuration file system. If you do not assign a name, the
value is determined by the automatic class selection routines established by your storage
administrator.
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 9.0 installed product file system.
- Intermediate symbolic link
- Select this option 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.
Select this option to specify the path name of an
intermediate symbolic link. This link is created by the customization jobs, pointing to the product
file system directory.
- Path name of intermediate symbolic link
- Path name of intermediate symbolic link.
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 that is used to start the migrated daemon.
When you migrate
to Version 9.0, you must upgrade your JCL started procedures. A
new started procedure is 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 that is used to start the migrated controllers.
When you
migrate to Version 9.0, you must upgrade your JCL started
procedures. A new started procedure is 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 that is used to start the migrated servants.
When you
migrate to Version 9.0, you must upgrade your JCL started
procedures. A new started procedure is 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 that is used to start the migrated adjunct.
When you migrate
to Version 9.0, you must upgrade your JCL started procedures. A
new started procedure is 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 need to
keep the same START commands and manually replace the procedures by using the procedure that is
generated during migration as a template.
Notes:
- Your Version 9.0 configuration must use different JCL
procedures from those used by your Version 7.0 or later configuration.
The migration process creates new Version 9.0 JCL procedures by
using the procedure names specified here.
- If you use the same names as you used in your Version 7.0 or later
configuration, the migration process overlays the existing procedures. If you are using the same
names, make sure that you back up the existing Version 7.0 or later
procedures before you run the migration jobs in case you need to roll back later.
- If you selected the option to do a clone migration, this option is not available.
- Optional application deployment
-
- Deploy the default application
- Specify whether to deploy the default application.
- Deploy the sample applications
- Specify whether to deploy the sample applications.
Note: These applications are not supported in
a WebSphere Application Server Network Deployment cell.
Install the sample
applications to use the application server and evaluate the latest technological advancements. The
sample applications are not recommended for deployment to production application server
environments.
Server Customization (Part 2)
- Application migration preference
- How you would like to migrate your installed applications.
Note: WebSphere Application Server system applications 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 can 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 9.0
installableApps directory without 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
that is 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
completes. You can also reorganize and combine these files for better application installation
efficiency. Read the "Wsadmin tool" article in the documentation 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 7.0 or later installation and the
Version 9.0 installation. If you keep the migrated applications in
the same locations as the previous version, the following restrictions apply:
- The WebSphere Application Server
Version 9.0 mixed-node support limitations must be followed.
This means that the following support cannot be used when you evoke 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 7.0 or later installation.
- Any application that is installed relative to a Version 7.0 or later
variable is installed relative to the location assigned to that variable in Version 9.0. In other words, the absolute location is not
preserved. The application is migrated to the relative location within the new Version 9.0 environment.
If the binariesURL in the
deployment.xml file for an application that is 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 9.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.
- Migrate administrative console customized "My tasks" settings
- "My tasks" is only supported in WebSphere Application Server
Version 7.0 or 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
Server Customization (Part 3)
Note: This panel appears only if you select the option to do a clone migration.
- Short names
-
- Cell short name
- Provide a new short name for the Version 9.0 cell.
- Node short name
- Provide a new short name for the Version 9.0 node.
- Server short name
- Provide a new short name for the Version 9.0 server.
- Cluster short name prefix
- Provide a short name prefix up to 3 characters in length. It is used to generate unique cluster
short names for the version 9.0 cell.
- Daemon job name
- Provide a new job name for the new location services daemon. The name must be different from the
daemon in the old environment.
Migration Process Options
- Migration trace options
-
If you choose to enable tracing, it remains 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 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.
- JVM options for migration processes
-
- Initial heap size (MB)
- The initial memory that is allocated for the JVM heap.
- Maximum heap size (MB)
- The maximum heap size that can be allocated for the JVM heap.
- Temporary directory location
- The directory where the backup of your previous configuration and the migration trace is
written.
During migration, a backup copy of the previous version's configuration is required. The
default location of this backup is /tmp/migrate. If the
/tmp file system does not have adequate space to store the backup
configuration, you can specify another location. If you choose to override the default location of
the backup copy, the best practice is to keep the same naming convention and replace the
/tmp portion with another path, /myTemp/migrate for
example.
- Migration definition identifier
- Identifier that is used to create a directory under the temporary directory that contains the
temporary migration datasets and backup configuration data.
- Java™ temporary directory
- You can specify a Java temporary directory that is used by
the Java virtual machine to create and story temporary files
during migration.
-
- Set the Java temporary directory
- Java temporary directory location
Port values
Define which port values to use in the new profile and how to handle port conflicts. If you reuse
port values from the old profile, the new profile cannot run at the same time as the old profile
because of port conflicts. If you intend to run both profiles concurrently, make sure that each
profile uses different ports.
- Use the same ports that the old profile used
- Reuse the port values that are defined in the source profile.
Note: This option does not appear
if you select the option for a clone migration.
- Select ports manually
- Set custom values for each port in the target profile on the following panel.
- Generate new ports, incrementing from a common starting port value
- Generate new ports from the specified port value. Conflicting ports are automatically resolved.
- Port conflict resolution
- Choose how to resolve port conflicts.
- Increment from the conflicted port value
- If a port conflict is detected, the port value is incremented from the conflicting port to the
next available port value.
- Increment from a common starting port value
- If a port conflict is detected, the port value is incremented from the specified value to the
next available port value.
Administrative Agent Registration
Note: This option does not appear if you select the option for a clone migration.
If the
source profile is registered with an administrative agent, migrate the administrative agent before
you migrate any of the registered profiles. Provide the following information to unregister the
source profile from the source administrative agent. After you migrate all the registered profiles,
stop the source administrative agent. Lastly, manually register each of the migrated profiles to the
target administrative agent, which must be at the same or later version level as the migrated
profiles.
- Registered to an administrative agent
- Indicates whether the source profile is registered to an administrative agent.
- Source administrative agent
- Settings from the administrative agent.
-
- Profile path
- The file system path of the source administrative agent.
- SOAP port
- The port that the source administrative agent that is used for SOAP connections.
- User name
- If security is enabled, the user name for the source administrative agent.
- Password
- If security is enabled, the administrative security password for the source administrative
agent.
Job Statement Definition
All the migration jobs that are tailored for you
need a job statement. Enter a valid job statement for your installation. The migration creation
process updates 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.