Migrate administrative scripts from V5.x

 

There are some changes you should be aware of when migrating from WAS V5.x.

 

Overview

There are a few changes to be aware of that are required for your existing scripts when moving to WAS V6.x. In general, the administration model has changed very little. However, there are some changes required with V6.x. See the following for the changes:

 

Procedure

• Be aware of the implications of migrating JMS applications from the embedded messaging in WAS V5 to the default messaging provider in WAS V6.x. See Migrating from version 5 embedded messaging for more information.

• A new version of Jacl (1.3.2) is shipped with WAS V6.x. With this Jacl version, regexp command supports only tcl 8.0 regexp command syntax. If your existing V5.x Jacl script uses regexp command syntax that is supported in Jacl 1.2.6 but not anymore in Jacl 1.3.2, you may not get a match anymore, or you may 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 more information on Jacl, see Jacl.

• For WSADMIN $AdminConfig: The PME CacheInstanceService type is no longer used in V6.x. If your scripts contain code to set the enable attribute on the CacheInstanceService type, remove the code. It is not needed in V6.x.

• There are a few changes to be aware of that are required for your existing scripts when moving to WAS V6.x. 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. See the Example: Migrating - Changing transaction log directory using scripting article for more information.

• There are a few changes to be aware of that are required for your existing scripts when moving to WebSphere Application Server V6.x. 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.

---

Example: Migrating - Allowing configuration overwrite when saving a configuration

Example: Migrating - Changing transaction log directory using scripting

Example: Migrating - Changing process definitions using scripting

Example: Migrating - Modifying Web container port numbers

 

Related tasks

Manage WebSphere version 5 JMS use of WebSphere version 6 JMS resources
Migrating from version 5 embedded messaging to version 6

 

Related Reference

Wsadmin tool

 

Related information

Overview of migration, coexistence, and interoperability