WAS v8.0 > Migration and coexistence > Distributed operating systems > Migrate administrative scripts
Migrate administrative scripts from a previously Version 5.1.x application server
There are some changes you should be aware of when migrating from a version of WAS that was previously v5.1.x.
Supported configurations:
This topic is about configuration migration, such as migrating dmgrs and federated nodes in a network deployment environment. The Application Migration Toolkit for WAS provides support for migrating applications from previous versions of WAS to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.
There are a few changes to be aware of that are required for your existing scripts when moving to WAS v8.0. In general, the administration model has changed very little. However, there are some changes required when moving from a previously v5.1.x to v8.0.
Procedure
- Be aware of the implications of migrating JMS applications from the embedded messaging in WAS v5.1.x to the default messaging provider in WAS v8.0.
- A new version of Jacl (1.3.2) was shipped beginning with WAS v6.x. With this Jacl version, regexp command supports only Tcl 8.0 regexp command syntax. If your existing Version 5.1.x Jacl script uses the regexp command syntax that is supported in Jacl 1.2.6 but not anymore in Jacl 1.3.2, you might not get a match anymore or you might get a compile error for your regexp command similar to the following:
com.ibm.bsf.BSFException: error while eval'ing Jacl expression: couldn't compile regular expression pattern: ?+* follows nothing while executing "regexp {(?x) ..." ("if" test expression) invoked from within "if {[regexp {(?x) ..." (file testregexp.jacl line 2) (file line 2) invoked from within "source testregexp.jacl"There is no workaround for this regression problem. Jacl has indicated that this is by design and there is no simple patch to fix this design decision.
- For WSADMIN $AdminConfig: The PME CacheInstanceService type is no longer used. If your scripts contain code to set the enable attribute on the CacheInstanceService type, remove the code. It is not needed in v8.0.
- There are a few changes to be aware of that are required for your existing v5.1.x scripts when moving to WAS v8.0. These types of changes can be evolved directly without the assistance of script compatibility support. The data can be accessed from multiple locations, including the old and new locations. As long as the new location is not updated, the data is accessed from the old location. Once the new location is updated, it becomes the current data and is used for further accesses and updates. Warning messages are logged when the old location is still being used.
Read Example: Migrating - Changing transaction log directory using wsadmin.sh for more information.
- There are a few changes to be aware of that are required for your existing scripts when moving from Version 5.1.x to WAS v8.0. These changes are assisted by the compatibility mode provided by WASPostUpgrade command. During migration, the default is to migrate using compatibility mode. If this option is taken, then the old object types are migrated into the new configuration; all existing scripts will run unchanged.
See the Example: Migrating - Changing process definitions using scripting article for more information.
- Be aware of removed features that might have an impact on administration scripts.
These might include the following:
- Support for the Secure Authentication Service (SAS) IIOP security protocol
- Support for the Common Connector Framework (CCF)
- Support for the IBM Cloudscape Version 5.1.x database
- Support for the following JDBC drivers:
- WebSphere Connect JDBC driver
- Microsoft SQL Server 2000 Driver for JDBC
- WebSphere SequeLink JDBC driver for Microsoft SQL Server
Read Migrate from the WebSphere Connect JDBC driver for information on using the WebSphereConnectJDBCDriverConversion command to convert data sources from the WebSphere Connect JDBC driver to the DataDirect Connect JDBC driver or the Microsoft SQL Server JDBC driver.
See the "Deprecated and removed features" article in the information center.
Related
Example: Migrating - Allowing configuration overwrite when saving configurations
Example: Migrating - Changing transaction log directory using wsadmin.sh
Example: Migrating - Changing process definitions using scripting
Example: Migrating - Modifying web container port numbers
Overview of migration, coexistence, and interoperability