| Explanation | None |
| Action | No user action is required. |
| Explanation | None |
| Action | No user action is required. |
| Explanation | The command parameters are incorrectly specified. |
| Action | Verify that all of the parameters are valid and spelled correctly. |
| Explanation | The backup directory is used to store the configuration information that is migrated to the new release. |
| Action | Run the command again and specify the backup directory. |
| Explanation | You must access the currently installed Application Server directory to obtain the configuration information that is migrating to the new release. |
| Action | Run the command again and specify the currently installed Application Server directory. |
| Explanation | The specified parameter is not supported by the command. |
| Action | Check the spelling of the parameter and run the command again. |
| Explanation | Migration support is provided for WebSphere Application Server Version 7.0 and later. |
| Action | If you are migrating from a supported release, verify that the directory name is correct, and run the command again. |
| Explanation | The WASPostUpgrade command is running against an unsupported version of Application Server. The WASPostUpgrade command that was invoked might not be using the current version of the Application Server directories. |
| Action | Invoke the command in the current Application Server directory structure. |
| Explanation | Specify a directory so that files containing the configuration information for the current release can be saved. |
| Action | Run the command again and specify the name of a directory. |
| Explanation | Specify a writable directory so that files containing the configuration information for the current release can be saved. |
| Action | Run the command again and specify the name of a writeable directory. |
| Explanation | The system is unable to create a directory with the name that you specified. |
| Action | Determine why the directory cannot be created and run the command again. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV or consult the appropriate operating system documentation. |
| Explanation | The migration function cannot find a specific property in an IBM-supplied file. |
| Action | See the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV |
| Explanation | During migration processing, the function attempted to call another Application Server program; the call cannot be successfully completed. |
| Action | If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV |
| Explanation | The specified directory on the migration command does not contain a valid <samp>properties/com/ibm/websphere/product.xml</samp> file. |
| Action | Rerun the command with a valid Application Server XML file name. |
| Explanation | The function cannot read the specified configuration file. |
| Action | If the file is part of the current Application Server configuration, restore the configuration from a previous backup and rerun the command. The WASPostUpgrade command saves backup copies of all the configuration files that it attempts to modify. The backup files are in the same directory structure and have time stamps as part of their names. |
| Explanation | The specified log file is initialized. A new log file is created for each invocation of the migration commands. |
| Action | No user action is required. |
| Explanation | The specified log file cannot be initialized. No data is saved in a log file, but output is still routed to the administrative console for you to view. |
| Action | Check the user file permissions before you run the command again. |
| Explanation | The function cannot find or copy an expected directory. This missing directory might affect the migration. |
| Action | If this source file must be used to create an enterprise application, use a development environment like the Rational Application Developer to add the file to the appropriate location in the enterprise application. |
| Explanation | The function cannot copy the directory. This problem might affect the migration. |
| Action | If the directory must be used to create an enterprise application, use a development environment like the Rational Application Developer to add the files from that directory to the appropriate location in the enterprise application. |
| Explanation | The directory was created during normal processing. |
| Action | No user action is required. |
| Explanation | The function is copying a directory and its contents. |
| Action | No user action is required. |
| Explanation | An unexpected failure occurred during the creation of a directory. |
| Action | Delete or rename the directory, and rerun the function using either the WASPreUpgrade or the WASPostUpgrade command. |
| Explanation | An unexpected failure occurred during the creation of a directory. |
| Action | Verify that the user ID has sufficient file system authority to run the migration command. |
| Explanation | An unexpected failure occurred when a configuration file was copied. |
| Action | If the source file must be used to create an enterprise application, use a development environment such as the Rational Application Developer to add the file to the appropriate location in the enterprise application. |
| Explanation | An unexpected failure occurred while copying a configuration file. |
| Action | Verify that the user ID has the appropriate file system authority to run the migration program. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | An unexpected failure occurred while closing a configuration file. |
| Action | Verify that the user ID has the appropriate file system authority to run the migration program. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The specified object is being added to the configuration of the new Application Server version. |
| Action | No user action is required. |
| Explanation | An unexpected failure occurred while copying a configuration file. Migration is expected to occur normally. A backup copy of the previous configuration file is not available. |
| Action | Verify that the user ID has the appropriate file system authority to run the migration command. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | An unexpected error occurred while trying to save the migrated configuration. |
| Action | Verify that the user ID has sufficient file system authority to run the migration command. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The specified entry already exists in the configuration of the new Application Server version. The attributes of this entry are being updated. |
| Action | No user action is required. |
| Explanation | The migration function cannot locate the object of the specified type when attempting to migrate it. |
| Action | Verify that the object exists in the backup environment that results from the WASPreUpgrade command. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The configuration file was successfully read. |
| Action | No user action is required. |
| Explanation | This message follows another message in the log that shows a different program that is being called during migration. This message displays the results of that call. |
| Action | No user action is required. |
| Explanation | No Samples are migrated by the WASPostUpgrade command. |
| Action | No user action is required. |
| Explanation | The backup directory that was specified on the command line does not exist. |
| Action | Rerun the command with a valid backup directory that was created by the WASPreUpgrade command. |
| Explanation | An internal error occurred. The specified environment variable must be set for the migration command to run. |
| Action | If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The migration has completed with no warning or error messages. |
| Action | No user action is required. |
| Explanation | The migration completed with some warning messages, but no errors occurred. |
| Action | For further information; check the log file that was created by the migration command in the logs directory, and correct the problems if required. The log name includes a time stamp, so check the log file with the latest creation date. |
| Explanation | The migration command failed. |
| Action | For additional information; check the log file that was created by the migration command in the logs directory, and correct the problems if required. The log name includes a time stamp, so check the log file with the latest creation date. |
| Explanation | The business rule beans that are featured in IBM WebSphere Business Integration Server Foundation must be installed to run business rule beans applications. |
| Action | Install the feature, and rerun the command. |
| Explanation | The IBM WebSphere Business Integration Server Foundation CORBA C++ SDK must be installed to run CORBA applications. |
| Action | Install the feature, and rerun the command. |
| Explanation | An unexpected error occurred while trying to read the specified file. |
| Action | Verify that the user ID has sufficient file system authority to run the migration program. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The specified backup directory is created from an unsupported version of Application Server. |
| Action | Rerun the migration command with a valid backup directory that was created by the WASPreUpgrade command. |
| Explanation | An unexpected error occurred. |
| Action | If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The migration failed to complete because errors occurred during migration. |
| Action | For additional information; check the log file that was created by the migration command in the logs directory, and correct the problems if required. The log name includes a time stamp, so check the log file with the latest creation date. |
| Explanation | The specified configuration file, which did not exist in the new Application Server configuration, is successfully created. |
| Action | No user action is required. |
| Explanation | The specified configuration file is ready to be saved. |
| Action | No user action is required. |
| Explanation | The files that you need to restore your configuration on the new release are being copied to the backup directory. |
| Action | No user action is required. |
| Explanation | The process of backing up your previous configuration is complete. |
| Action | No user action is required. |
| Explanation | The specified profile in the previous application server environment began to migrate to the configuration of the specified profile in the new application server version. |
| Action | No user action is required. |
| Explanation | The restoration of the previous Application Server configuration is complete. |
| Action | Display the WASPostUpgrade log, and verify the results. The message that is displayed before this one indicates success, warning, or error. |
| Explanation | The specified value is incorrect. |
| Action | Consult the help text that is displayed with this message, and rerun the command with a correct value. |
| Explanation | This node is already added to the cell manager configuration. Migration does not run because the configuration is controlled by the cell manager. |
| Action | If you want to migrate the node, remove the node from the cell manager configuration, and rerun the command. However, proceed with caution because the configuration is already being managed. |
| Explanation | The attributes of the specified authentication mechanism are being updated. |
| Action | No user action is required. |
| Explanation | The attributes of the specified user registry are updated to reflect the information for the specified server ID. |
| Action | No user action is required. |
| Explanation | The migration function used the wsadmin command to deploy the specified application. |
| Action | No user action is required. |
| Explanation | The call to the wsadmin command failed, and the specified application is not deployed. |
| Action | To determine why the call to the wsadmin command failed, check the <samp>wsadmin.traceout</samp> file in the logs directory of the installation root of the new version. |
| Explanation | The specified value application installation directory has been updated to use the common WebSphere variables |
| Action | No action is required, |
| Explanation | Automated migration for the file is starting. |
| Action | No user action is required. |
| Explanation | The migration function cannot apply the version of Application Server that is designated as a backup in the specified directory. Either the version in the backup directory is not supported, or the WebSphere products are not compatible. |
| Action | Verify that the combination of WebSphere product types is in the backup directory and that the current versions are compatible. |
| Explanation | No administrative applications are migrated during the WASPostUpgrade process. |
| Action | No user action is required. |
| Explanation | Another Application Server process has a lock on the configuration directory. |
| Action | Close any running Application Server processes, and run migration again. |
| Explanation | The deployment manager might not have been running during migration. |
| Action | Verify that the deployment manager is currently running. Either manually run the syncNode command to update the configuration, or enable the node agent to perform this task automatically the next time that you run the startNode command. |
| Explanation | The function is trying to connect to the deployment manager using the specified protocol. |
| Action | No user action is required. |
| Explanation | The configuration is successfully synchronized. |
| Action | No user action is required. |
| Explanation | The function cannot create the specified configuration file. |
| Action | Verify that the WASPostUpgrade command has the necessary permissions to create files, and then try the command again. |
| Explanation | The IBM WebSphere Business Integration Server Foundation extended messaging feature must be installed to run the specified service. |
| Action | Install the feature, and run the command again. |
| Explanation | The IBM WebSphere Business Integration Server Foundation process choreographer feature must be installed to run the specified service. |
| Action | Install the feature, and run the command again. |
| Explanation | The IBM WebSphere Business Integration Server Foundation other services feature must be installed to run the specified service. |
| Action | Install the feature, and run the command again. |
| Explanation | The IBM WebSphere Business Integration Server Foundation member manager feature must be installed to run the specified service. |
| Action | Install the feature, and run the command again. |
| Explanation | The IBM WebSphere Business Integration Server Foundation process choreographer feature must be installed to use the container. |
| Action | Install the feature, and run the command again. |
| Explanation | The existing configuration is saved in the <samp>temp</samp> directory. |
| Action | No user action is required. |
| Explanation | Leftover properties that are found in the old file are not found in the new file. |
| Action | No user action is required, but you might want to review the file and determine why some properties are missing. |
| Explanation | Leftover grants that are found in the old file are not found in the new file. |
| Action | No user action is required. |
| Explanation | While migrating a federated node, the node names of the old and new configurations did not match. This configuration cannot be migrated because the old configuration exists in the deployment manager with the old node name. Using the new node name causes an unacceptable configuration in the deployment manager. |
| Action | Uninstall and reinstall Application Server using the same node name as the old configuration, or remove the old node from the deployment manager configuration and manually add this node. |
| Explanation | The migration of a deployment manager to the latest release is successful. This migration creates the same port definitions as those on the existing Application Server configuration. Stop the deployment manager of the existing configuration before starting the deployment manager in the new configuration, and do not use it. Use the deployment manager of the new configuration to manage the environment. |
| Action | If you want to roll back to use the previous Application Server Version 5.1, 6.0 or 6.1 environment instead of Version 7.0, you must re-enable that configuration. To do this, go to the /bin directory of the previous Version 5.1 6.0 or 6.1 installation and run the migrationDisablementReversal.jacl script. |
| Explanation | During a federated migration, a JMX connection must be established with the deployment manager. That connection was not established during this migration attempt. |
| Action | Check the original error message and verify that all the connection information is correct. If the information is correct, verify that the deployment manager is running, and that it is listening on the port that is specified in the error message. If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV. |
| Explanation | The series of steps needed to save the existing configuration information for the profile is starting. |
| Action | No user action is required. |
| Explanation | The profile must exist before a migration can be performed. |
| Action | Rerun the command with the correct profile name, or use the wasprofile command to create the correct profile. |
| Explanation | The profile did not exist in the previously installed WebSphere. |
| Action | Rerun the command with the correct profile name. |
| Explanation | When the -includeApps attribute is set to false, no user applications are installed on the new version. |
| Action | Install the application using the Application Server administration interfaces. |
| Explanation | The -oldProfile option is required for this command. |
| Action | Specify the source profile that you want to migrate on the -oldProfile option, and rerun the command. |
| Explanation | The IBM WebSphere Business Integration Server Foundation feature must be installed to run the specified service. |
| Action | Install the feature, and rerun the command. |
| Explanation | The IBM WebSphere Business Integration Server Foundation feature must be installed to run the specified service. |
| Action | Install the feature, and rerun the command. |
| Explanation | The IBM WebSphere Business Integration Server Foundation feature must be installed to run the specified service. |
| Action | Install the feature, and rerun the command. |
| Explanation | The migration of Embedded JMS to Service Integration Bus failed to migrate properly. |
| Action | See the information center for further action; if the answer is not found in the information center, contact IBM support. |
| Explanation | All servers must belong to a core group. This server is added to the default core group. |
| Action | No user action is required. |
| Explanation | Transports are migrating to corresponding channels in the new release. |
| Action | No user action is required. |
| Explanation | Each transport is migrated to a new channel and belongs to a new default thread pool. |
| Action | No user action is required. |
| Explanation | The migration of a deployment manager to the latest release is successful. This migration creates the same port definitions that are in the existing Application Server configuration. The node agent of the existing configuration must be stopped before starting the deployment manager in the new configuration. The deployment manager of the new configuration must be used to manage the environment. |
| Action | If you want to roll back to use the previous Application Server Version 5.1, 6.0 or 6.1 environment instead of Version 7.0, you must re-enable that configuration. To do this go to the /bin directory of the previous Version 5.1, 6.0 or 6.1 installation and run the migrationDisablementReversal.jacl script. |
| Explanation | All servers must belong to some core group. This server could not be added to the default core group due to some error. |
| Action | The server must be added to some core group before it is able to run. This can be done by using the system management interfaces. |
| Explanation | The -profileName option is required this command. |
| Action | Specify the target profile that you want to migrate to on the -profileName option, and rerun the command. |
| Explanation | While processing a deployment manager configuration the cell names of the old and new configurations did not match. This is not a supported migration path. |
| Action | Perform migration again using a profile name with the matching cell name. |
| Explanation | All nodes must belong to a node group. This node is added to the default node group. |
| Action | No user action is required. |
| Explanation | Due to limitations in a mixed-node environment, the -useMetaDataFromBinary attribute has been set to false. The local changes that were part of the enterprise archive (EAR) file are also located in the repository, so the behavior of the application does not change. |
| Action | When the application is used for Application Server Version 6.x profiles only, use the administrative console to modify this attribute. |
| Explanation | The migration completed with no warning or error messages. |
| Action | No user action is required. |
| Explanation | The migration completed with some warning messages, but no errors occurred. |
| Action | Check the log file that the migration command created in the logs directory, and correct the problems if required. The log name includes a time stamp, so check the log file with the latest creation date. |
| Explanation | Certain files in the Application Server Version 5 or 6 environment might be modified during the migration of a version 7 deployment manager that manages version 5 or 6 nodes. By running the backupConfig command against your version 5 or 6 environment, you provide yourself with an error recovery path. |
| Action | Run the backupConfig command against all the version 5 or 6 nodes that are managed by the version 7 deployment manager. |
| Explanation | The direct invocation of WASPreUpgrade and WASPostUpgrade is not supported. |
| Action | Use z/OS Migration Management Tool under WebSphere Customization Tools to create your migration definitions. |
| Explanation | This release of Application Server cannot manage nodes prior to Version 6.0.2.0 without a fix. |
| Action | Install the required fix to Version 6.0.0.x and 6.0.1.y nodes prior to migration. |
| Explanation | The deployment manager to which this node belongs is not the deployment manager currently running. |
| Action | Shut down the incorrect deployment manager, and start the deployment manager that is currently managing the node to be migrated. |
| Explanation | This error occurs if the new deployment manager configuration contains a node with the same name as a node in the prior release. This happens if the user does an "addNode" in the current release prior to migration. |
| Action | UnFederate the node in the current release, and rerun migration. |
| Explanation | This error occurs when an unsupported server type is encountered. |
| Action | Use the migration utilities for the product that this server type belongs too. |
| Explanation | This error occurs when -keepAppDirectory true and -appInstallDirectory are both specified. |
| Action | Select only one of the two parameters, or specify -keepAppDirectory false. |
| Explanation | Applications that are already installed in the new profile will not be migrated. |
| Action | No user action is required. |
| Explanation | A variable being used could not be resolved using the defined variables |
| Action | Check to see if the variable is being used for a valid reason. If not then no further action is required; if it is, then define the variable. |
| Explanation | A variable being used could not be resolved using the defined variables |
| Action | Check to see if the variable is being used for a valid reason. If not then no further action is required; if it is, then define the variable. |
| Explanation | To avoid having two deployment managers managing the same cell, you must shut down the current version of deployment manager when specifying -keepDMgrEnabled=true |
| Action | Shut down the current version of deployment manager, and perform the migration again. |
| Explanation | The file or directory might already exist. To avoid overwriting a valid file or directory, the file or directory will not be copied. |
| Action | If the file or directory is required, then manually search the WASPreUpgrade backup directory for the file or directory and copy it into the new environment. |
| Explanation | Verification of the -traceFile parameter location or the traceFile property location failed. |
| Action | Make sure that the -traceFile parameter location or the traceFile property location is not write protected and that the path entered is a valid path. |
| Explanation | During the application migration process, one or more applications failed to migrate. Refer to the log files for details. |
| Action | If possible, correct the problems that are recorded in the log files. One or more applications might need to be installed manually. |
| Explanation | During a managed node migration, any new Version 7 configuration changes that existed prior to running WASPostUpgrade might need to be reapplied after the WASPostUpgrade process completes. |
| Action | Reapply preexisting Version 7 cell level changes after the managed node migration has been completed. |
| Explanation | A JDBC provider in the previous version did not have a provider type defined. This is a required attribute. The provider type could not be resolved during migration. |
| Action | Ensure that each JDBCProvider has a providerType. For WebSphere Connect JDBC providers, consider using the WebSphereConnectJDBCDriverConversion tool. For all other providers, it is recommended that it be deleted, unless you have previously configured data sources that still use it. |
| Explanation | The Application Server migration tooling did not process some files that were saved during WASPreUpgrade. This is part of tooling to support migration from one machine to another and is an expected message when migrating to a different machine |
| Action | Review the log from migration WASPostUpgrade, and check for MIGR0451W messages in the log file. |
| Explanation | Migration copied the file because it had not already been processed during migration. |
| Action | No user action is required. |
| Explanation | Migration found a reference to a file that could not be found as part of migration. This means the file was either not backed up during WASPreUpgrade or not copied forward during WASPostUpgrade. |
| Action | Copy the missing file to the location specified and rerun migration, or update the reference after migration has completed. |
| Explanation | The DB2 for zOS Local JDBC Provider (RRS) JDBC provider is not supported in the targeted Application Server version. |
| Action | Manually create the DB2 Universal Driver provider. |
| Explanation | The identified setting is deprecated. This value is still used for this release, but it will be removed in a later release. |
| Action | See the information center for information about an alternative or replacement setting. |
| Explanation | WebSphere Connect JDBC driver support has been removed. Any WebSphere Connect type data sources need to be modified to use either the Microsoft SQL Server JDBC Driver or DataDirect Connect JDBC driver. |
| Action | See the information center for information about an alternative or replacement setting. |
| Explanation | The migration of a deployment manager to the latest release is successful. This migration creates the same port definitions as those on the existing Application Server configuration. Stop the deployment manager of the existing configuration before starting the deployment manager in the new configuration. Use the deployment manager of the new configuration to manage the environment. |
| Action | If you want to use the old environment, restart the prior version Deployment Manager. |
| Explanation | The migration of the Managed node to the latest release is successful. This migration creates the same port definitions that are in the existing Application Server configuration. The node agent of the existing configuration must be stopped before starting the deployment manager in the new configuration. The deployment manager of the new configuration must be used to manage the environment. |
| Action | If you want to use the old environment you will need to restart the prior version of the Deployment Manager and Managed node. |
| Explanation | WASPostUpgrade requires the user name and password to perform administrative functions against the prior configuration. |
| Action | Rerun WASPostUpgrade and supply the user name and password of your prior configuration. |
| Explanation | This indicates that a specific backup of Application Server files are being migrated into this configuration. |
| Action | No user action is required. |
| Explanation | This indicates that the specified backup cannot be migrated into this profile. Additional information can be found in other messages printed to the migration log files. |
| Action | Resolve the issues causing the other failing messages, and then rerun the migration. |
| Explanation | This indicates that the base Application Server files have already been migrated. They will not be migrated again. |
| Action | No user action is required. |
| Explanation | This indicates that a backup of the existing configuration is being saved for use during the WASPostUpgrade step of migration. |
| Action | No user action is required. |
| Explanation | This message indicates that all features in the backup directory that are enabled in the current configuration have already been migrated. If information that you expected is not available in the current configuration, review the installed products and ensure that the correct features are installed. |
| Action | No user action is required. |
| Explanation | This indicates that we were unsuccessful in stopping the prior release nodeagent. Migration will not continue. |
| Action | Shut down nodeagent of prior release and perform Migration again. |
| Explanation | Optional parameters must be prefixed by the escape character '-' and have at most one string argument. |
| Action | Verify that the proper optional parameter syntax is being used. Review the command line help for more information. |
| Explanation | This optional parameters require an argument. |
| Action | Verify that the proper optional parameter syntax is being used. Review the command line help for more information. |
| Explanation | Invalid port information exist for the specified entry. This information is required for migration processing. |
| Action | Correct the port information for the specified server in the serverindex that is in the configuration repository and then rerun migration. In distributed configurations, the configuration repository is in the Deployment Manager. |
| Explanation | Invalid host information exist for the specified entry. This information is required for migration processing. |
| Action | Correct the host information for the specified server in the serverindex that is in the configuration repository and then rerun migration. In distributed configurations, the configuration repository is in the Deployment Manager. |
| Explanation | WASPreUpgrade requires that the <backupDirectoryName> and <currentWebSphereDirectory> be specified. |
| Action | Run WASPreUpgrade again supplying the required parameters. |
| Explanation | A variable has been redefined at a narrower scope which will override the broader scoped value. |
| Action | Remove the offending variable from the narrower scope or replace the narrower scoped variables value with the broader scoped variables value. |
| Explanation | WASPreUpgrade command did not find any profiles or instances with the name specified. |
| Action | Run WASPreUpgrade command again specifying a profile or instance name that exists. |
| Explanation | Performance may degrade with coregroups of large size. |
| Action | Redistribute coregroup processes to smaller coregroup groupings. |
| Explanation | The identified setting is deprecated. This value is still used for this release, but it will be removed in a later release. |
| Action | See the information center for information about an alternative or replacement setting. |
| Explanation | The migration requires that compatible profile types be used when migrating. Of note, it is not possible to migrate into a target profile that is already federated into a Deployment Manager. |
| Action | Create a new profile of a compatible type; specify a different profile to migrate; or use the Migration wizard, the z/OS Migration Management Tool, or the zMMT command to create the target profile automatically. |
| Explanation | The migration has adjusted a value that was configured outside the recommended minimum or maximum for the specified performance tuning option. |
| Action | Customers should be aware that the migrated server may require more resources than previous releases. The change has been made to conform to recommended values, but if you determine that this is beyond the needs of your system you may change the value. |
| Explanation | The number of open files is limited by the operating system, and the current setting has insufficient file handles for running migration program. |
| Action | Configure more available file descriptors in the session that runs the migration program, and restart the migration. |
| Explanation | The Deployment Manager's SOAP_CONNECTOR_ADDRESS port number has been changed, in order for the managed nodes to communicate with the Deployment Manager, a manual synchronization must occur using new SOAP_CONNECTOR_ADDRESS port number. |
| Action | Run syncNode from the effected Managed nodes using new SOAP_CONNECTOR_ADDRESS port number. See the InfoCEnter for more information about executing syncNode manually with port information. |
| Explanation | This migration requires that the profile names match between the old and new releases. A mismatch has been detected and migration cannot continue until the issue is resolved. |
| Action | Create a new profile that matches the name of the source profile, and rerun migration with this matching profile as the target. |
| Explanation | As part of this migration, files must be copied from the Deployment Manager to this node. These files will be stored in the backup directory. An error occured during this process that may have resulted in corruption of the backup directory. |
| Action | Investigate the original error. Common causes include network issues in communicating with the Deployment Manager, and insufficient space or permissions on the backup directory filesystem. Resolve the issue and rerun both the WASPreUpgrade and WASPostUpgrade tools because the backup directory may not be valid. |
| Explanation | The directory specified does not pass validation to be used as a migration backup directory. This may be the result of a failure during WASPreUpgrade, or corruption by a previous run of WASPostUpgrade. |
| Action | If the wrong directory was specified, rerun the tool with a valid backup directory. If the directory specified is correct, then the backup directory has been corrupted. Rerun the WASPreupgrade tools to create a new migration backup directory. |
| Explanation | During the application migration process, one or more applications failed to migrate. Refer to the log files for details. |
| Action | If possible, correct the problems that are recorded in the log files. One or more applications might need to be installed manually. |
| Explanation | The directory specified does not pass validation to be used as a migration backup directory. |
| Action | Select an empty directory outside of any WebSphere install directories that is on a filesystem with sufficient space. |
| Explanation | There is a Derby database lock file detected. Cannot migrate Derby database while in use. |
| Action | Please shutdown Derby database and be sure all lock files have been removed. |
| Explanation | The migration function used the wsadmin command to successfully deploy the specified application. |
| Action | No user action is required. |
| Explanation | When migrating an appserver that is managed by an admin agent, the appserver is first deregistered from the old admin agent. There was a failure in this deregistration process. |
| Action | Check the logs to find out why the deregistration failed. The old admin agent may not be running. Start the old admin agent and rerun the postupgrade the command. |
| Explanation | When migrating an appserver that is managed by an admin agent, the appserver is registered to the new admin agent after migration completes successfully. There was a failure in this registration process. |
| Action | Check the logs to find out why registration process failed. The new admin agent may not be running. Start the new admin agent and manually register the migrated appserver if migration was successful. |
| Explanation | Since this is a managed application server, migration will try to deregister the application server from the old admin agent first. |
| Action | Make sure that the old admin agent is running |
| Explanation | Since this is a managed application server, migration will try to register the application server to the new admin agent after migration of the appserver completes successfully. |
| Action | Make sure that the new admin agent is running |
| Explanation | Since security is enabled on your managed application server, security credentials are needed to unregister this managed appserver from the old admin agent and register with the new admin agent |
| Action | Rerun the WASPostUpgrade command with the -oldAdminAgentUsername, -oldAdminAgentPassword, -newAdminAgentUsername, -newAdminAgentPassword parameters |
| Explanation | The admin agent profile path for the new release is invalid. |
| Action | Make sure that the admin agent information for the new release is valid. |
| Explanation | The admin agent profile path for the old release is invalid. |
| Action | Make sure that the admin agent information for the old release is correct. |
| Explanation | The WASPostUpgrade detected that the WASPreUpgrade command used the -machineChange true parameter. This usually indicates a hostname change. WASPostUpgrade detected that the new and the old host names are identical. |
| Action | After migration, you will need to validate that the each endpoint has the correct host name assigned. |
| Explanation | The WASPostUpgrade process cannot disable the source profile because it is located on a different machine. The -machineChange parameter was use by the WASPreUpgrade process to save the backup information. |
| Action | Refer to the WebSphere InfoCenter on how to manually disable the source profile. |
| Explanation | The migration received an UnknownHostException or a SecurityException while trying to determine the IP address of the source and/or target hostname. The migration assumed the hostname change is valid and continued. The migration updated the hostname for one or more endpoints. |
| Action | You must verify these settings. Or, to avoid this change, recreate the target profile using the hostname from the source profile and run the migration again. |
| Explanation | The certificate exchange related messages can be ignored. |
| Action | Ignore the certificate exchange related messages. |
| Explanation | During migration processing, the retrieveSigners command was attempted, but did not complete. |
| Action | Manually run the retrieveSigners command. After the command completes successfully, re-run the WASPostUpgrade command if it did not complete. |
| Explanation | The default value is recommended. |
| Action | If a value other than the default is needed, the value can be updated after the migration. |
| Explanation | A failure occurred while copying a configuration file. |
| Action | If changes are needed to the destination file, the file will need to be modified manually after changing the access permissions to allow the file to be written. |
| Explanation | When a security provider from the old file is inserted in the new file, the security providers in the new file are renumbered. |
| Action | No action is required, but you might want to review the file and determine if the security providers are configured as desired. |
| Explanation | A failure occurred while copying a configuration file. The existence of the destination file indicates the source file was already migrated in a previous migration. |
| Action | Since the source file was migrated during a previous migration, no action should be needed. |
| Explanation | A failure occurred while copying a configuration file. |
| Action | Verify that the user ID has the appropriate file system authority to run the migration program. |
| Explanation | The WASPostUpgrade process cannot migrate the java.security file. |
| Action | Manually modify the java.security file for the target profile as needed. |
| Explanation | The WASPostUpgrade process migrated the java.security file. The settings should be reviewed for correctness. |
| Action | Verify and manually modify the java.security file for the target profile as needed. |
| Explanation | The file cannot be read |
| Action | Make sure the file exists in the backup directory and can be read. Run the WASPostUpgradeBLAHelper script after fixing the problem. |
| Explanation | None |
| Action | No action is required. |
| Explanation | The command cannot be run |
| Action | Make sure the command is correct. Run the WASPostUpgradeBLAHelper script after fixing the problem. |
| Explanation | The jython file cannot be run |
| Action | Make sure the jython file and its contents are correct. Run the WASPostUpgradeBLAHelper script after fixing the problem. |
| Explanation | The wsadmin commands have been saved |
| Action | No further action needed to install BLAs |
| Explanation | The commands could not be saved |
| Action | Check the logs to see why the commands could not be saved. Run the WASPostUpgradeBLAHelper script after fixing the problem. |
| Explanation | The remote version of the WASPreUpgrade command must include the "-machineChange true" parameter. |
| Action | Run the WASPreUpgrade command again while specifying the "-machineChange true" parameter. |
| Explanation | Profiles for Job Manager, Administrative Agents and Base Application Servers registered to an Administrative Agent are not allowed to migrate to a new machine. |
| Action | Remove the "-machineChange true" parameter and run the WASPreUpgrade command again. |
| Explanation | The migration command was not able to find the profileRegistry.xml file, which contains the profile registry definitions. Either profiles were not created in the source product release, or the profileRegistry.xml file was corrupted or deleted. |
| Action | If profiles do exist for the source product release, you must reconstruct the profileRegistry.xml file. See the problem determination information on the WebSphere Application Server Support web page: https://ibm.biz/BdztgV. |
| Explanation | The path or variables contained in the path definition could not be properly adjusted to reflect its post-migration location. However, an equivalent path definition was inserted in its place. |
| Action | None needed. However, the user can manually adjust the variables in the new post-migrated environment and then readjust the path to use those variables. |
| Explanation | An additional installation of java was found. This java installation might require the java.security file to be configured. |
| Action | Check if the java installation found in the specified directory is being used. If not, then no further action is required. If it is, then verify the java.security file is set up correctly. |
| Explanation | A machine change migration has been detected. There are resources registered with the job manager function associated with the previous deployment manager. Update the job manager URL for the registered resources after WASPostUpgrade. |
| Action | Update the job manager URL at the registered resources. |
| Explanation | A machine change migration has been detected. The previous deployment manager could not be contacted to determine whether there are resources registered with the associated job manager function. If there are registered resources, update the job manager URL for the registered resources after WASPostUpgrade. |
| Action | If there are registered resources, update the job manager URL at these resources. |
| Explanation | The function cannot copy the file or directory because the destination is a read-only location. This problem might cause the migration to fail. |
| Action | Ensure that you have permission to write to the directory and copy files manually. |
| Explanation | The function cannot compress the directory because it is empty. |
| Action | If the directory is not needed, delete the directory. |
| Explanation | The specified WebSphere Application Server installation configuration file might contain settings which are incompatible with the new installation. |
| Action | Verify and manually modify the settings in the specified file as needed. |
| Explanation | During the migration process a call was made to another WebSphere Application Server program, which failed to complete successfully. |
| Action | If the problem persists, see the problem determination information on the Application Server Support Web page: https://ibm.biz/BdztgV |
| Explanation | During the migration process, a call was made to another program. The output of this program could not be read. |
| Action | If the problem persists, see the problem determination information on the WebSphere Application Server Support web page: https://ibm.biz/BdztgV |
| Explanation | The assets, business-level assets, and composition units from the previous version of the application server are being installed on the new version of the application server. |
| Action | No action is required. |
| Explanation | One or more application server assets, business-level assets, or composition units did not install successfully. |
| Action | See the log file for more information about the problem. After you resolve the problem, run the command again. |
| Explanation | Before the application server migration command modifies the target profile, it saves the profile configuration so that it can be restored if necessary. The profile configuration was not saved successfully. |
| Action | See the log file for more information about the problem. After you resolve the problem, run the migration command again. |
| Explanation | The deployment manager is being started as part of the migration process. |
| Action | No action is required. |
| Explanation | The deployment manager is being stopped so that the migration process can proceed. |
| Action | To start the deployment manager again, specify the -keepDmgrEnabled parameter when you run the migration command. |
| Explanation | The deployment manager was not started. The deployment manager must be running to administer nodes. |
| Action | See the log file for more information about the problem. After you resolve the problem, run the command again. |
| Explanation | The deployment manager was not stopped, so the migration process cannot proceed. |
| Action | See the log file for more information about the problem. After you resolve the problem, run the migration command again. You can run the command stated in the message to verify that the deployment manager is stopped. |
| Explanation | The application server migration process is generating a new web server plug-in configuration file to reflect the migrated profile in the new environment. |
| Action | No action is required. |
| Explanation | The migration process ran the GenPluginCfg command to generate the web server plug-in configuration file. The command did not complete successfully, so the web server plug-in configuration file was not updated. |
| Action | See the log file for more information about the problem. After you resolve the problem, run the command again. |
| Explanation | The ownership of the file was not changed. Incorrect file ownership and permissions might cause problems after migration. |
| Action | Resolve the problem, and run the command again after the migration command completes to update the file ownership. |
| Explanation | The migration process was unable to update the was.env server environment file. |
| Action | Resolve the problem, and run the command again after the migration command completes. |
| Explanation | The port definitions for the profile were not migrated because the -replacePorts false parameter was specified. |
| Action | Review whether the port values in the endpoint addresses for the service maps and local mapping service are correct. If the service maps need to be updated, use the administrative console to edit the service map enterprise applications that were created when the service maps were installed. If the local mapping service needs to be updated, use the administrative console or the updateLMService command in wsadmin. |
| Explanation | The properties file must contain a property that specifies the root directory where the application server is installed. The installation root directory could not be determined because the properties file does not exist, could not be read, or does not contain the property. |
| Action | Ensure that the file exists and has the proper file permissions. |
| Explanation | When you specify the -oldProfile parameter, the currentWebSphereDirectory parameter value must be the old installation root directory. |
| Action | Change the currentWebSphereDirectory parameter value to the old installation root directory. |
| Explanation | The profile name could not be determined. The currentWebSphereDirectory parameter value is either not correct or the profile it references is not valid. |
| Action | Ensure that the currentWebSphereDirectory value is correct. |
| Explanation | The currentWebSphereDirectory parameter must reference the installation or profile root directory. |
| Action | Ensure that this parameter specifies a valid installation or profile root directory. |
| Explanation | The application server installation or profile root directory is missing a subdirectory that is required for migration to continue. |
| Action | Verify that the WebSphere Application Server installation or profile is valid. If the problem persists, see the problem determination information on the WebSphere Application Server Support Web page: https://ibm.biz/BdztgV |
| Explanation | The property is specified in the properties file, but it must only be specified from the command line. By default, the properties file is the migration.properties file in the installation root directory. If you created your own properties file, then the properties file is the file you specified in the -properties parameter on the command line. |
| Action | Remove the specified property from the properties file. To specify the restricted property, add it as a parameter to the command line and run the command again. |
| Explanation | One or more properties are specified in the properties file that must only be specified from the command line. By default, the properties file is the migration.properties file in the installation root directory. If you created your own properties file, then the properties file is the file you specified in the -properties parameter on the command line. |
| Action | Remove all restricted properties from the properties file. To specify a restricted property, add it as a parameter to the command line and run the command again. |
| Explanation | A property for a parameter that is not supported is specified in the properties file. By default, the properties file is the migration.properties file in the installation root directory. If you created your own properties file, then the properties file is the file you specified in the -properties parameter on the command line. |
| Action | Remove all unsupported parameters from the properties file, and run the same command again. |
| Explanation | An unsupported property that corresponds to the given command-line parameter is specified in the properties file. By default, the properties file is the migration.properties file in the installation root directory. If you created your own properties file, then the properties file is the file you specified in the -properties parameter on the command line. |
| Action | Remove the property in the properties file that corresponds to the specified command-line parameter, and run the same command again. |
| Explanation | Automatic repository checkpoints must be disabled during migration. |
| Action | To re-enable automatic repository checkpoints after migration, in the administrative console go to System Administration > Extended Repository Service and select Enable automatic repository checkpoints. |
| Explanation | The profile registry does not contain any registered profiles for the migration command to process. Either profiles have not been created in the source product release or the profileRegistry.xml file was corrupted. |
| Action | If profiles do exist for the source product release, you must reconstruct the profileRegistry.xml file. See the problem determination information on the WebSphere Application Server Support web page: https://ibm.biz/BdztgV. |
| Explanation | The configuration path contains a variable that cannot be resolved at the current scope. |
| Action | Define the variable at a scope that can resolve the variable, or remove the variable from the configuration path. You can edit the variable definition and configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | Configuration paths that refer to a system root directory are not automatically migrated. |
| Action | If the file or directory is at the defined configuration path, you must manually migrate the file or directory to its new location and update the configuration path. Otherwise, remove the configuration path. You can edit the configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | The configuration path definition does not refer to a valid file or directory. |
| Action | If the configuration path is not correctly defined, remove the configuration path or update it to a valid file or directory. Otherwise, you can leave the configuration path definition as-is. You can edit the configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | The file or directory was not copied to the new location because of insufficient disk space, file handles, system memory, or permissions, or other system causes. |
| Action | You must manually migrate the file or directory to its new location and update the configuration path. You can edit the configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | Migrating the directory that is defined in the configuration path will corrupt the new installation or profile. |
| Action | You must manually migrate the directory to its new location and update the configuration path to refer to a file or set of files instead of a directory. You can edit the configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | The current user ID cannot write to the target directory. |
| Action | Verify that the current user ID has permission to write to the specified directory. You must manually migrate the file or directory to its new location and update the configuration path. You can edit the configuration path in the administrative console or by using wsadmin scripting. For more information, see the documentation about editing variables or specifying paths for this piece of the configuration. |
| Explanation | Prior to WebSphere Application Server Version 8.5.5, the default value of the web server plug-in PostBufferSize property was 64. During migration, the value of this property was automatically set to the new default value of 0 to prevent the plug-in from retrying HTTP POST requests that fail with transient errors. |
| Action | If you want the web server plug-in to retry HTTP POST transient errors, set the PostBufferSize property back to 64. For more information, see the Knowledge Center documentation for the PostBufferSize property. |
| Explanation | Prior to WebSphere Application Server Version 8.5.5, the default value of the web server plug-in PostBufferSize property was 64. It is recommended to set this property to 0 to prevent the plug-in from retrying HTTP POST requests that fail with transient errors. |
| Action | If you do not want the web server plug-in to retry HTTP POST requests, change this setting to 0. For more information, see the Knowledge Center documentation for the PostBufferSize property. |
| Explanation | Cluster address endpoints are not controlled by the WebSphere Application Server product. They must be validated and tested after you migrate the product. |
| Action | After the migration completes, verify that the endpoint is valid and functional. |
| Explanation | The com.ibm.ws.migration.postupgrade.keepNodeEnabled property keeps the old federated node enabled after it is migrated. The enabled old node can be inadvertantly started and managed by the new deployment manager, resulting in unexpected data changes to the old node. |
| Action | To avoid data corruption, use the com.ibm.ws.migration.postupgrade.keepNodeEnabled property only when the -machineChange parameter is set to true or the -setPorts parameter is not set to useOld. |
| Explanation | The specified command line argument is no longer valid and was replaced with another argument. |
| Action | Specify the new argument in place of the old argument on the command, and run the command again. |
| Explanation | The -setPorts < starting_port_number > argument automatically resolves port conflicts by incrementing from the starting port number. Therefore, the -resolvePortConflicts argument will be ignored. |
| Action | No user action is required. |
| Explanation | The argument requires a value within a specific range, but the specified value was outside of that range. |
| Action | Specify a valid value for the argument, and run the command again. |
| Explanation | The BLALog.txt file must be readable so that the migration process can verify whether business-level applications (BLA) were already created. |
| Action | Check the file permissions for the user that is executing this process. |
| Explanation | Not all applications installed in the new profile successfully. Analyze the application installation logs to resolve any issues. |
| Action | Resolve any application installation issues, and run the WASMigrationAppInstaller script as indicated in the message. You can run this script as many times as needed to successfully install all applications because the WASMigrationAppInstaller script skips applications that are already installed. Do not run the WASPostUpgrade tool again to install the remaining applications. |
| Explanation | An application with the same name is already installed in the profile. Therefore, the command to install the application was not run. |
| Action | No user action is required. |
| Explanation | Prior to WebSphere Application Server Version 9.0, the default value for the ESIEnable property was "true". Starting in Version 9.0, the default value is "false". |
| Action | To use the new default behavior, manually set the ESIEnable property to "false". For more information, see the information about default value and behavior changes in the product documentation. |
| Explanation | This endpoint was added because it was not found in the source configuration, but it is specified in the server template of the target configuration. The port number is specified in the serverindex.xml configuration file. |
| Action | If you want to change the port setting of the endpoint, manually change the endpoint in the serverindex.xml file. |
| Explanation | This version of the product no longer supports Communications Enabled Applications (CEA). |
| Action | Applications that use CEA must be rewritten. |
| Explanation | The version indicator in the web.xml file is incompatible with the source release. The version was reset to make it compatible in a mixed-cell environment. |
| Action | No user action is required. |
| Explanation | The migration tools accept only valid registered profiles. |
| Action | Before you continue with the migration, correct the settings for the invalid profile by using the manageprofiles -validateAndUpdateRegistry option. If the problem persists, see the problem determination information on the Application Server Support web page: https://ibm.biz/BdztgV |
| Explanation | This compatibility option was set so that applications migrating from the old release can continue to run with the old OpenJPA behavior. |
| Action | If you do not want this compatibility option, remove it from the server JVM settings and regenerate the canonical metamodel classes. For more information, see Apache OpenJPA documentation. |
| Explanation | The file handle limit for your system is less than the minimum recommended level for running the product. A low limit can cause various problems during migration, including an unexpected termination of the process. |
| Action | Increase the system file handle limit to at least the minimum level recommended by the product. |
| Explanation | The default WebSphere CoreGroup wiring protocol changed in Version 9.0. This compatibility property enables all nodes in the mixed-cell environment to run using the new protocol, thus ensuring proper communications. |
| Action | No user action is required. |
| Explanation | The way the core group member selects the default protocol in Version 9.0. This compatibility property enables all nodes in the mixed cell environment to run using the new protocol, thus ensuring proper communications. |
| Action | No user action is required. |
| Explanation | The migration process was unable to migrate the job logs for the Compute Grid job scheduler. |
| Action | To keep the old job logs, you can manually copy them to the target release. To determine the location of the old job logs, use the administrative console. |
| Explanation | None |
| Action | No user action is required. |
| Explanation | The migration tool used the wsadmin command to successfully deploy the specified application by adding java options to be compatible with specified Java EE level. |
| Action | No user action is required. |
| Explanation | The version indicator in the application.xml file is incompatible with the source release. The version was reset to make it compatible in a mixed-cell environment. |
| Action | No user action is required. |
| Explanation | Because the -clone true parameter was specified and the -machineChange parameter was not set to false, the default value of -setPorts useOld is not valid. |
| Action | Run the migration again using either the -setPorts generateNew or the -setPorts <startingPort> parameter. |
| Explanation | The property setting of com.ibm.ws.migration.WASPostUpgrade.parameter.clone=true is not supported on the z/OS operating system. |
| Action | Rerun the migration with the com.ibm.ws.migration.WASPostUpgrade.parameter.clone property set to false. |
| Explanation | The -clone true option is not supported for job managers or for managed application servers. |
| Action | Rerun the migration with the -clone option not specified or set to false. |
| Explanation | If the deployment manager was migrated with the -clone true option, then all federated nodes in the cell must also use the -clone true option. |
| Action | When you migrate any federated nodes in the cell, you must set the -clone true option and provide the deployment manager host name and either the SOAP or RMI port. |
| Explanation | The -newDmgrHostname <hostName> parameter is required but was not specified. |
| Action | Run the migration command again for the federated node and specify the -newDmgrHostname <hostName> parameter and either the -newDmgrSoapPort <port> or -newDmgrRmiPort <port> parameter. |
| Explanation | Either the -newDmgrSoapPort <port> or the -newDmgrRmiPort <port> parameter is required, but neither was specified. |
| Action | Run the migration command again for the federated node and provide either the -newDmgrSoapPort <port> or the -newDmgrRmiPort <port> parameter. |
| Explanation | Administrative agent profiles are always migrated so that the old profile is functional. Therefore, the default -setPorts useOld value is not valid. |
| Action | Run the migration again using either the -setPorts generateNew or the -setPorts <startingPort> parameter. |
| Explanation | At least one incompatible option was found that cannot be used with the -clone true option. |
| Action | Correct any settings that are not compatible with the -clone true option, or set the -clone parameter to false and rerun the migration. |
| Explanation | Federated nodes can only be migrated with the -clone true option if their deployment manager was migrated with the -clone true option. |
| Action | Either migrate the federated node migration without setting the -clone parameter, or remigrate the deployment manager with the -clone true option. |
| Explanation | To prevent web server traffic from being routed to the new WebSphere environment prematurely, the automatic generation and propagation of the plug-in configuration was disabled. |
| Action | If you want automatic generation and propagation of the plug-in configuration in the new WebSphere environment, enable this behavior in the new WebSphere environment and disable it in the old. |
| Explanation | No available combination of the provided prefix followed by a three digit number was found. |
| Action | Verify that the provided prefix isn't already in use. If the prefix is already being used by other short name values in the environment, provide a unique one and rerun the migration process. |
| Explanation | The value provided for the specified argument is not valid, but the message text provides a list of valid values. The message that follows this one contains the syntax for the command. |
| Action | Verify that the proper syntax is being used for this argument and that the argument is set to a proper value. Review the command line help for more information. |
| Explanation | Migrating to the same major version of the product is only allowed when cloning the product. |
| Action | Configure the migration to be a clone migration. Either set the -clone option to true for the WASPostUpgrade command line tool, or select the clone option from the migration wizard. |
| Explanation | A source profile cannot be migrated to a target profile that shares the same product installation root. |
| Action | Install the product to a new location and create the target profile as part of this new product installation. |
| Explanation | Beginning with version 8.0, the default value for the webAuthReq security property is "persisting". If you use the administrative console, the value must be "persisting". The webAuthReq security property had a value of "lazy" in your environment. The value was changed to "persisting". |
| Action | No action is required. To use the old behavior, manually set the webAuthReq security property to "lazy". |
| Explanation | The -clone true option automatically sets the -keepDmgrEnabled option to true. |
| Action | If you want to disable the old deployment manager node, you must do so manually. |
| Explanation | Federated nodes must be migrated with the -clone true option if their deployment manager was migrated with the -clone true option. |
| Action | Either migrate the federated node using the -clone true option, or migrate the deployment manager again with the -clone false option before migrating this federated node. |
| Explanation | Due to a failure, the WASPostUpgrade process is attempting to roll back the migration. The error that caused WASPostUpgrade to fail was previously logged. Errors occurring after this message are related to the rollback. |
| Action | Look for previous errors in the log to determine the reason for the WASPostUpgrade process failure. |
| Explanation | WebSphere Application Server Version 9.0 supports multiple versions of the JEE technology. The version of the JEE technology was modified to an older version so that application compatibility is maintained. |
| Action | No action is required. This message is to inform you of a default change that migration made to the cluster running WebSphere Application Server Version 9.0. |
| Explanation | WebSphere Application Server Version 9.0 supports multiple versions of the JEE technology. The version of the JEE technology was modified to an older version so that application compatibility is maintained. |
| Action | No action is required. This message is to inform you of a default change that migration made to the server running WebSphere Application Server Version 9.0. |
| Explanation | JAX-RS Version 1.1 is incompatible with the default Context Dependency Injection (CDI) technology version shipped with WebSphere Application Server Version 9.0. Applications may not work correctly if they use JAX-RS which uses CDI. |
| Action | Upgrade the application to use JAX-RS Version 2.0, which is compatible with the Context Dependency Injection (CDI) technology version shipped with WebSphere Application Server Version 9.0. In addition, reconfigure the cluster or server hosting the application to use JAX-RS Version 2.0. |
| Explanation | The default sslProtocol setting was changed to SSL_TLSv2 in WebSphere Application Server Version 9.0. SSL_TLSv2 supports all protocols supported by SSL_TLS, and several additional protocols. |
| Action | No action is required, but you can review the new supported protocols in the product documentation. |
| Explanation | Migration cannot synchronize the backup directory for the profile with the deployment manager because the source profile has previously been migrated into the target cell using the clone option. |
| Action | Either restore the target node from the deployment manager, or reset and redo the entire cell migration, including the deployment manager and all nodes. |
| Explanation | The migration is local. The value of at least one variable in the file or directory path cannot be determined. If files need to be moved, the migration does not examine variables at the cluster scope or automatically update the variable values. |
| Action | No action is required if the variables are defined only at a cluster scope, and the path indicates a file or directory outside the source environment installation or profile directories. In the target environment, verify that the path resolves to the correct file or directory and make any required updates. |
| Explanation | The source profile that is being collected contains an application server that has a name other than the default name, which is server1. If the destination profile does not contain an application server with a name that matches the source profile server name, problems might occur. |
| Action | Ensure that the destination profile for this migration contains an application server with the matching customized name before you run the WASPostUpgrade command. |
| Explanation | If the source and target profiles for this migration don't contain a server with the same name, problems might occur after migration. |
| Action | Ensure that the destination profile for this migration contains an application server with a customized name that matches the customized server name in the source profile. If the server name doesn't match and problems occur, delete the destination profile and create a profile that specifies a server name that matches the server name in the source profile. Then, run the WASPostUpgrade command again. |
| Explanation | This problem is usually caused by parameters that are misspelled or missing. |
| Action | Verify that all of the parameters are valid and spelled correctly. Type the command without parameters or arguments to get the correct syntax of the command. |
| Explanation | No argument is provided for the specified attribute. For example, the parameter '-traceFile' was used, but '-traceFile /some/path/to/log/file.txt' was required. |
| Action | Supply an argument for the specified parameter. |
| Explanation | The enterprise archive (EAR) file name is either not an EAR file, or the contents and structure of the EAR file do not conform to a supported Java Platform Enterprise Edition, Java EE, specification. |
| Action | Verify that the path is spelled correctly and that a valid EAR file is in that location. |
| Explanation | A specified parameter is not recognized as a valid parameter. |
| Action | Verify spelling and run the command alone, without any parameters or arguments, to get the correct syntax of the command. |
| Explanation | No enterprise archive (EAR) file is specified. This file name is the first argument that you pass in after the command. For example: clientUpgrade /ear/file/location/earfile.ear |
| Action | Rerun the command with an EAR file as the first argument. |
| Explanation | Cannot find the specified EAR file in the given location. |
| Action | Verify that the path is spelled correctly and that an EAR file exists in that location. |
| Explanation | The specified enterprise archive (EAR) file is a directory. |
| Action | Verify that the specified EAR file is an EAR file and not a directory. |
| Explanation | The enterprise archive (EAR) file does not contain any client Java archive (JAR) files by the specified name. |
| Action | Verify that the EAR file contains the client JAR file that is specified. |
| Explanation | The enterprise archive (EAR) file does not contain any client JAR files. |
| Action | If the specified EAR file is expected to contain client Java archive (JAR) files, correct the EAR file, and try the command again. |