You might encounter problems while migrating from an older version of WebSphere Application Server.
CWSIC1002E: An internal error occurred. An object of class JsMessage cannot be created because of exception MessageDecodeFailedException
com.ibm.ws.sib.mfp.MessageDecodeFailedException: com.ibm.ws.sib.mfp.jmf.JMFSchemaViolationException: messageType not compatible with null... CWSIC1003E: An internal error occurred. An object of class JsMessage cannot be created because of exception MessageDecodeFailedException" with a stack trace that contains the com.ibm.ws.sib.mfp.MessageDecodeFailedException exception
This problem can occur if you are trying to run the WASPostUpgrade tool or the WASPreUpgrade tool from a directory other than app_server_root\bin. Verify that the WASPostUpgrade or WASPreUpgrade scripts reside in the app_server_root\bin directory, and launch either file from that location.
The administrative console no longer displays deprecated JDBC provider names. The new JDBC provider names used in the administrative console are more descriptive and less confusing. The new providers will differ only by name from the deprecated ones.
The deprecated names will continue to exist in the jdbc-resource-provider-templates.xml file for migration reasons (for example, for existing JACL scripts); however, you are encouraged to use the new JDBC provider names in your JACL scripts.
The WASPreUpgrade tool saves selected files from WebSphere Application Server Version 4.x and Version 5.x bin directories. It also exports the existing application server configuration from the repository.
If you are migrating from WebSphere Application Server Version 4.0.x Advanced Edition, the WASPreUpgrade command calls the XMLConfig command to export the existing application server configuration from the repository. If errors occur during this part of the WASPreUpgrade command, you might have to apply fixes to the installation to successfully complete the export step. Contact IBM Support for the latest applicable fixes.
This problem can occur if you are trying to run the WASPostUpgrade tool or the WASPreUpgrade tool from a directory other than app_server_root\bin. Verify that the WASPostUpgrade or WASPreUpgrade scripts reside in the app_server_root\bin directory, and launch either file from that location.
The most likely cause of this error is that Version 4.0.x or 5.x of the WebSphere Application Server is installed, and the WASPostUpgrade tool was not run from the bin directory of the WebSphere Application Server Version 6.0.x installation root.
MIGR0002I: java com.ibm.websphere.migration.postupgrade.WASPostUpgrade backup_directory_name -adminNodeName primary_node_name [-nameServiceHost host_name [ -nameServicePort port_number]] [-substitute "key1=value1[;key2=value2;[...]]"] In input xml file, the key(s) should appear as $key$ for substitution.") [-import xml data file] [-traceString trace specification [-traceFile filename]]}"
To correct this problem, run the WASPostUpgrade command from the bin directory of the WebSphere Application Server Version 6.0.x installation root.
During the course of a deployment manager or a managed node migration, WASPostUpgrade disables the old environment. If after running WASPostUpgrade you want to run WASPreUpgrade again against the old installation, you must run the migrationDisablementReversal.jacl script located in the old app_server_root/bin directory. After running this JACL script, your Version 5.x environment will be in a valid state again, allowing you to run WASPreUpgrade to produce valid results. For more information on scripting, see Getting started with scripting .
During the course of a federated migration, the migration process makes a call up to the DeploymentManager to perform a portion of the migration. If, after seeing the message MIGR0388I, you see a SOAP/RMI connection timeout exception, rerun WASPostUpgrade specifying the "-connectionTimeout" to some value greater than the default (the default is 10 minutes). A good rule of thumb is to double the value and run WASPostUpgrade again.
/websphere60/appserver/profiles/dm_profile/temp/nodeX_migration_temp
The logs and everything else involved in the migration for this node on the deployment manager node are located in this folder. This folder will also be required for IBM support related to this scenario.
During a federated migration, if any of the Version 6.0.x applications fail to install, they will be lost during the syncing of the configurations. The reason this happens is that one of the final steps of WASPostUpgrade is to run a syncNode command. This has the result of downloading the configuration on the deployment manager node and overwriting the configuration on the federated node. If the applications fail to install, they will not be in the configuration located on the deployment manager node. To resolve this issue, manually install the applications after migration. If they are standard Version 6.0.x applications, they will be located in the app_server_root/installableApps directory.
Manually install the applications using wsadmin after WASPostUpgrade has completed.
MIGR0327E: A failure occurred with stopNode. MIGR0272E: The migration function cannot complete the command.
WebSphere Application Server Version 6.0.2 uses a Java virtual machine (JVM) in 32-bit mode. The Migration wizard for WebSphere Application Server Version 6.1.x calls the WASPostUpgrade.sh script, which attempts to run the JVM for Version 6.0.2 in the 64-bit mode when the server stops the Version 6.0.2 node.
cd /opt/IBM/WebSphere/AppServer/bin
. "$binDir" /setupCmdLine.sh
JVM_EXTRA_CMD_ARGS=""
app_server_root/bin/manageprofiles.sh -delete -profileName profile_name
If you update Version 6.0 or 6.0.1 to Version 6.0.2 before migrating the Version 5.x deployment manager, you can use the Version 6.0.2 administrative console to add a Version 5.x member to a Version 5.x cluster.
See Commands for the AdminTask object for information on running this command.
If you did not find your problem listed, contact IBM support.