Configuration variables for migrating a federated node by using the z/OS Migration Management Tool
Before you migrate a WebSphere® Application Server for z/OS® 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 for migrating a federated node.

This article is about profile configuration migration. To migrate your applications to the latest version, use the WebSphere Application Server Migration Toolkit. For more information, see the Migration Toolkit on WASdev.
sptcfgMigration Node Type Selection
- Type of WebSphere Application Server node to migrate
![[9.0.0.3 or later]](../images/ng9003.gif)
- 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 that manages this node was cloned, this node must be cloned; if the deployment manager was not cloned, this node cannot be cloned.
![[9.0.0.3 or later]](../images/ng9003.gif)
Clone Migration
This panel is available only if you have selected the option for a clone migration.
- Provide the hostname of the new deployment manager to which the cloned profile is federated to. The new deployment manager must be up and running at this hostname while the node is migrated.
- Select this option to provide the SOAP port of the new deployment manager to migration. You must provide at least one of the SOAP or RMI ports of the new deployment manager. If you provide both, the SOAP port is attempted first, and the RMI port is attempted if a connection by using the SOAP port fails.
- Select this option to provide the RMI port of the new deployment manager to migration. You must provide at least one of the SOAP or RMI ports of the new deployment manager. If you provide both, the SOAP port is attempted first, and the RMI port is attempted if a connection by using the SOAP port fails.
Migration Definition Name
Identifies the migration definition name and directory path to contain the batch jobs and instructions that are used to migrate a WebSphere Application Server for z/OS node.- 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.
- 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 were 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 ZMMTFED.
Target Datasets
- High-level qualifier for the target z/OS datasets that 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.Note: A multilevel high-level qualifier can be specified as the dataset high-level qualifier.
Dataset Names and Product Directory
- Existing procedure library to which the WebSphere Application Server for z/OS cataloged procedures are to be copied
- Location of your WebSphere Application Server Version 9.0 installed product file system
- 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.
Selecting this option allows you 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
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 (BBOWMG1F, BBOWMG2F, 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 BBOMMHFS or BBOMMZFS 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 federated node for more information on specifying these variables.
- 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 BBOMMHFS or BBOMMZFS job.
- File system dataset that you create and mount at the mount point
- 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.
- 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. - Size of each secondary extent in cylindersRecommendation: The minimum suggested size is 100 cylinders.
- Allocate and mount your configuration file system by using HFS
- Allocate and mount your configuration file system by using ZFS
Server Customization (Part 1)
- Mount point of the configuration from which you are migrating
- Home directory of the configuration from which you are migrating
- Mount point of the configuration to which you are migrating
This was specified previously on the Configuration File System panel.
- Home directory of the configuration to which you are migrating
- Mount point of the configuration to which you are migrating
- 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.
- 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.
- 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.
- 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.
- 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: - 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 and manually edit the BBOWMG3F, BBOWMPRO, BBOWMPRE, or BBOWMPOS jobs later. To defer, update the TO_AdminUserid variable with the proper user ID before you submit the job.
- 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 and manually edit the BBOWMG3F, BBOWMPRO, BBOWMPRE, or BBOWMPOS jobs later. To defer, update the TO_AdminPassword variable with the proper password before you submit the job.
Server Customization (Part 2)
- "My tasks" is only supported in WebSphere Application Server Version 7.0 or later.
- User defined workspace root location
![[9.0.0.3 or later]](../images/ng9003.gif)
Server Customization (Part 3)
This panel is available only if you have selected the option for a clone migration.
- Provide a new short name for the Version 9.0 node.
- 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.
Migration Process Options
If you choose to enable tracing, it remains enabled throughout the entire migration process.
- Enable or disable trace of the home creation, profile and migration tooling invocation, and final processing phases of migration
- Enable or disable trace trace during profile creation
- Enable or disable trace during the WASPreUpgrade process
- Enable or disable trace during the WASPostUpgrade process
- The initial memory that is allocated for the JVM heap.
- The maximum heap size that can be allocated for the JVM heap.
- 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.
- Identifier that is used to create a directory under the temporary directory that contains the temporary migration datasets and backup configuration data
- 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.
If you selected the option for a clone migration, the only compatible port
setting is to generate new ports, incrementing from a starting port value.
- Reuse the port values that are defined in the source profile.
This panel is not available if you have selected the option for a clone migration.
- Generate new ports from the specified port value. Conflicting ports are automatically resolved.
- Choose how to resolve port conflicts.
This panel is not available if you have selected the option for a clone migration.
- 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
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.