Configuration variables for migrating a deployment manager by using the z/OS Migration Management Tool

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 deployment manager is cloned, all the federated nodes that it manages must be cloned. However, if the deployment manager is not cloned, no federated nodes can be cloned.

Migration Definition Name

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 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 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 is 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 (BBOMDHFS or BBOMDZFS, BBOMDCP, 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 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 exist, the migration process creates it when you run the optional BBOMDHFS or BBOMDZFS 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 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 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 by using HFS.

zSeries File System (ZFS)

Allocate and mount your configuration file system 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 that is established by your storage administrator.

Management 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 that is 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 that is 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.

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 configuration. The migration process creates new Version 9.0 JCL procedures by using the procedure names specified here.
• If you use the same names that you used in your Version 7.0 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 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.

WebSphere administrator's user ID

The migration process requires the use of an administrative client. If administrative security is enabled in the source profile, select the Administrative security is enabled option and specify a valid WebSphere administrator's user ID that the administrative client can use to authenticate. Otherwise, deselect the Administrative security is enabled option.

You can defer entering a user ID and manually edit the BBOWMG3D, BBOWDPRO, BBOWDPRE, or BBOWDPOS jobs later. To do this, deselect the Administrative security is enabled option and update the TO_AdminUserid variable with the proper user ID before you submit the job.

WebSphere administrator's password

The migration process requires the use of an administrative client. If administrative security is enabled in the source profile, select the Administrative security is enabled option and specify a valid WebSphere administrator's password that the administrative client can use to authenticate. Otherwise, deselect the Administrative security is enabled option.

You can defer entering a password and manually edit the BBOWMG3D, BBOWDPRO, BBOWDPRE, or BBOWDPOS jobs later. To do this, Otherwise, deselect the Administrative security is enabled option. and update the TO_AdminPassword variable with the proper password before you submit the job.

Server Customization (Part 2)

Disable previous deployment manager

Whether to disable the previous deployment manager during migration. If you selected the option to do a clone migration, this option is not available.

If the source 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 deployment managers normally are stopped and disabled is to prevent multiple deployment managers from managing the same nodes. You must stop the source deployment manager before you start by using the Version 9.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 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 is complete. 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 installation and the Version 9.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 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 older installation.
• Any application that is installed relative to a variable in the source release 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)

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.

Server short name prefix

Provide a short name prefix up to 3 characters in length. It is used to generate unique server short names for the version 9.0 cell.

Daemon job name

Provide a job name for the location service daemon in the new environment. 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 maxiumum 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.

Job Statement Definition

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.