[z/OS]

Configuration variables for migrating a stand-alone application server using the z/OS Migration Management Tool

Before you migrate a WebSphere® Application Server for z/OS® Version 6.1 or later node to Version 8.5, 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 stand-alone application server.

Supported configurations Supported configurations:

This article is about configuration migration, such as migrating deployment managers and federated nodes in a network deployment environment. The Application Migration Toolkit for WebSphere Application Server provides support for migrating applications from previous versions of WebSphere Application Server to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.

sptcfg

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 ZMMTBASE.

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 8.5 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 8.5 file system if you already have an appropriate file system on the node being migrated. If you choose to use an existing Version 8.5 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 8.5 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. 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 already exist, the migration process creates it when you run the optional BBOMBHFS or BBOMBZFS 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 dataset using HFS
zSeries® File System (ZFS)
Allocate and mount your configuration file system dataset 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 8.5, 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 8.5, 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 8.5, 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 8.5, 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.

Notes:
  • Your Version 8.5 configuration must use different JCL procedures from those used by your Version 6.1 or later configuration. The migration process creates new Version 8.5 JCL procedures using the procedure names specified here.
  • If you use the same names as you used in your Version 6.1 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 6.1 or later procedures before running the migration jobs in case you need to roll back later.

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 6.1 or later configuration definitions:
  • Transport
  • ProcessDef
  • Version 6.x SSL
  • Version 6.x ORB service threadpool
instead of the following Version 8.5 configuration definitions:
  • Channels
  • ProcessDefs
  • Version 8.5 SSL
  • Version 8.5 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 6.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 8.5 level. When they are all at the Version 8.5 level, you should perform the following actions:
  1. Modify your administration scripts to use all of the Version 8.5 settings.
  2. Use the convertScriptCompatability command to convert your configurations to match all of the Version 8.5 settings.

    Read convertScriptCompatibility command for more information.

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 8.5 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 6.1 or later installation and the Version 8.5 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 8.5 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 6.1 or later installation.
  • Any application that is installed relative to a Version 6.1 or later variable will be installed relative to the location assigned to that variable in Version 8.5. In other words, the absolute location is not preserved—the application is migrated to the relative location within the new Version 8.5 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 8.5.
    • 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 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
Temporary directory location
The directory where the backup of your previous configuration and the migration trace are 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 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.

Concept topic    

Terms and conditions for information centers | Feedback

Last updated: April 20, 2014 11:58 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-zos&topic=cmig_zmmt_sappservar
File name: cmig_zmmt_sappservar.html