Before you migrate WebSphere® Application Server for z/OS®, you must create Job Control Language (JCL) jobs (CNTL and DATA datasets) that you will run during the actual migration. You can use the zmmt command with a response file to create the appropriate migration jobs. The migration response file contains a set of configuration variables that you use to create jobs for migrating a standalone application server.
This is always "default" on the z/OS platform.
Migrate a deployment manager
Migrate a federated node
Migrate a standalone application server
This name is used as input to the migration job that creates the configuration file system.
In an application server, the total space needed for this dataset increases with the size and number of installed applications.
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.
The configuration file system is where the configuration for the node being migrated is physically stored. You can choose to use an existing Version 7.0 file system if you already have an appropriate file system on the node being migrated. If you choose to use an existing Version 7.0 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 7.0 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.
Allocate and mount your configuration file system dataset using the Hierarchical File System
Allocate and mount your configuration file system dataset using the zSeries® File System
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.
Install user enterprise applications in the default application installation directory as part of the migration
Install user enterprise applications in a directory specified in the following variables as part of the migration
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.
Prepare user enterprise applications for installation in the WebSphere Application Server Version 7.0 installableApps directory without actually installing them during migration
/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.
Install user enterprise applications as part of the migration, and keep the same application installation directories as the previous version
Do nothing with user enterprise applications
When migrating to Version 7.0, 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.
When migrating to Version 7.0, 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.
When migrating to Version 7.0, 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.
When migrating to Version 7.0, 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.
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.
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 5.1.x or Version 6.x configuration definitions, for example, you might want to specify true for this variable.
Read convertScriptCompatibility command for more information.
During migration, a backup copy of the Version 5.1.x or Version 6.x configuration is required. The default location of this backup is already specified, though you can override if needed. You might need to specify a location other than the default if the /tmp file system does not have adequate space to store the backup configuration. 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.
This is the same value that is specified for the zConfigMountPoint variable.
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.
This link will be created by the customization jobs, pointing to the product file system directory.
create
profileName=default
profilePath=/zmmt/workspace/.metadata/.plugins/com.ibm.ws390.mmt.config/profiles/ZMigSASrv01
templatePath=zos-migStandalone
zConfigHfsName=OMVS.WAS70.CONFIG.HFS
zConfigHfsPrimaryCylinders=420
zConfigHfsSecondaryCylinders=100
zConfigHfsVolume=*
zConfigMountPoint=/wasv7config
zFilesystemType=HFS
zJobStatement1=(ACCTNO,ROOM),'USERID',CLASS=A,REGION=0M
zJobStatement2=//*
zJobStatement3=//*
zJobStatement4=//*
zTargetHLQ=SAS
zmbAdjunctProcName=BBO7CRA
zmbAppInstallDirLine1=/wasv7config/AppServer/profiles/default/installedApps
zmbAppInstallDirLine2=
zmbAppMigrationPreference=D
zmbControllerProcName=BBO7ACR
zmbDaemonProcName=BBO7DMN
zmbEnablePostUpgradeTrace=true
zmbEnablePreUpgradeTrace=true
zmbEnableProfileTrace=true
zmbEnableScriptCompatibility=true
zmbEnableScriptingTrace=true
zmbFromConfigRoot=/WebSphere/V5R1M0
zmbFromWASHomeDir=AppServer
zmbInstallDefaultApp=true
zmbInstallSamples=true
zmbProclibName=SYS1.PROCLIB
zmbReplaceStartedProcedureNames=true
zmbSMPEHome=/usr/lpp/zWebSphere/V7R0
zmbServantProcName=BBO7ASR
zmbTempDirectory=/tmp/migrate
zmbTimestamp=30080203
zmbToConfigRoot=/wasv7config
zmbToWASHomeDir=AppServer
zmbWorkspaceRootPreference=D
intermediateSymlinkPreference=Y
IntermediateSymlink=/V70SMPE/symblink