- create
- Required keyword to indicate the creation of a new migration definition
- profileName
- Name of the profile created during migration
This is always
"default" on the z/OS platform.
- profilePath
- Fully qualified path where the generated migration definition
output should be written
- templatePath
- Template path
One of the following values:
- zConfigHfsName
- Name of the MVS™ dataset that will contain the configuration
file system
This name is used as input to the migration job that
creates the configuration file system.
- zConfigHfsPrimaryCylinders
- Number of primary cylinders that will be allocated to the configuration
file system
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.
- zConfigHfsSecondaryCylinders
- Number of secondary cylinders that will be allocated to the configuration
file system
Recommendation: The minimum
suggested size is 100 cylinders.
- zConfigHfsVolume
- 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.
- zConfigMountPoint
- File system directory mount point where application data and environment
files are written
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 jobs 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 BBOMDHFS or BBOMDZFS job during
the actual migration process. In any case, you must specify the correct
value here for the mount point.
- zFilesystemType
- Type of file system
One of the following values:
- zJobStatement1 . . . n
- Customizable JOB statements that will be used for the generated
migration jobs
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.
- zTargetHLQ
- High-level qualifier for the target z/OS datasets
that will contain the generated jobs and instructions
Note: A multilevel
high-level qualifier can be specified as the dataset high-level qualifier.
- zmbAdminUserid
- User ID of an administrator that is used to manage the node that
is being migrated
This is required to perform required administrative
actions during the migration process.
- zmbAdminPassword
- Password for the user ID of the administrator that is used to
manage the node that is being migrated
This is required to perform
required administrative actions during the migration process.
- zmbAppMigrationPreference
- How you would like to migrate your installed applications
One of the following values:
- D
Install user enterprise applications in the default application
installation directory as part of the migration
- Y
Install user enterprise applications in a directory specified
in the following variables as part of the migration
- zmbAppInstallDirLine1
- zmbAppInstallDirLine2
- 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.
If the location path length
exceeds 60 characters, then it must be specified on two lines as shown;
but it cannot exceed a total length of 120 characters.
Leave
these two fields blank unless you specify Y for zmbAppMigrationPreference.
- S
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 for the zmbTempDirectory variable. 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.
- P
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 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 installation.
- Any application that is installed relative to a Version 6.1 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.
- N
Do nothing with user enterprise applications
Note: WebSphere Application Server system
applications will migrate regardless of the value set here.
- zmbControllerProcName
- 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.
- zmbServantProcName
- 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.
- zmbDaemonProcName
- 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.
- zmbReplaceStartedProcedureNames
- Whether to update the START commands in the configuration with
the new names specified (true) or to preserve the same names (false).
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. Specify true for
this variable to perform this configuration update.
If you
choose to use the same procedure names, then specify false for this
variable. 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 specify
false for this variable. 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 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 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 procedures before running the migration jobs in case you need
to roll back later.
- zmbDisableDmgr
- Whether (true) or not (false) to disable the previous deployment
manager during migration
If the Version 6.1 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
6.1 deployment managers normally are stopped and disabled is to prevent
multiple deployment managers from managing the same nodes. You must
stop the Version 6.1 deployment manager before you start using the Version 8.5 deployment manager.
Deselecting this option means that any configuration changes made
in the old configuration during migration might not be migrated.
- zmbEnablePostUpgradeTrace
- Enable (true) or disable (false) trace during the WASPostUpgrade
process
- zmbEnablePreUpgradeTrace
- Enable (true) or disable (false) trace during the WASPreUpgrade
process
- zmbEnableProfileTrace
- Enable (true) or disable (false) trace during profile creation
- zmbEnableScriptingTrace
- Enable (true) or disable (false) trace of the home creation, profile
and migration tooling invocation, and final processing phases of migration
- zmbEnableScriptCompatibility
- Whether (true) or not (false) to migrate to support script compatibility
This specifies whether or not migration should
create the following Version 6.1 configuration definitions:
- Transport
- ProcessDef
- Version 6.1 SSL
- Version 6.1 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.1 configuration definitions, for example, you might want to specify
true for this variable.
If you want to use a cell that contains Version
6.1 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 8.5 level. When they
are all at the
Version 8.5 level,
you should perform the following actions:
- Modify your administration scripts to use all of the Version 8.5 settings.
- Use the convertScriptCompatability command
to convert your configurations to match all of the Version 8.5 settings.
Read convertScriptCompatibility command for more information.
- zmbFromConfigRoot
- Mount point of the configuration from which you are migrating
- zmbFromWASHomeDir
- Home directory of the configuration from which you are migrating
- zmbProclibName
- Existing procedure library to which the WebSphere Application Server for z/OS cataloged
procedures are to be copied
- zmbSMPEHome
- Location of your WebSphere Application Server Version 8.5 SMPE installed product
file system
- zmbTempDirectory
- 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.
- zmbTimestamp
- Identifier that will be used to create a directory under the temporary
directory that will contain the temporary migration datasets and backup
configuration data
- zmbToConfigRoot
- Mount point of the configuration to which you are migrating
This
is the same value that is specified for the zConfigMountPoint variable.
- zmbToWASHomeDir
- Home directory of the configuration to which you are migrating
- zmbWorkspaceRootPreference
- Whether to migrate the administrative console customized "My tasks"
settings saved in the default workspace user root location (D) or
to migrate the settings saved in a user-defined workspace root location
(U)
- zmbUserWorkspaceRoot
- User-defined workspace root location
- intermediateSymlinkPreference
- Whether to set up an intermediate symbolic link
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.
- IntermediateSymlink
- Path name of intermediate symbolic link
This link will be created
by the customization jobs, pointing to the product file system directory.