Migrate administrative scripts from 5.x to 6.0

 

+

Search Tips   |   Advanced Search

 

Overview

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

 

Procedure

1. Prepare for evolutionary changes without script compatibility support. 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.

   The location of the transaction logs directory attribute has changed from the ApplicationServer::TransactionService to the ServerEntry::recoveryLogs. As long as the new location is not used, the value from the old location will continue to be used. Scripts that modify the old location can still be used; that value will take effect until a value in the new location is set. The change to scripts to use the new location is as follows:

   Old location:

   • Using Jacl

     set transService [$AdminConfig list TransactionService $server1]
         $AdminConfig showAttribute $transService transactionLogDirectory
     

   New Location:

   • Jacl

     $AdminConfig list ServerEntry $node
     set serverEntry <select one of the ServerEntry from output of above command>
     set recoveryLog [$AdminConfig showAttribute $serverEntry recoveryLog]
     $AdminConfig showAttribute $recoveryLog transactionLogDirectory
     
     

2. Prepare for evolutionary changes with script compatibility support. 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.

   HTTP transports: the new architecture for V6 uses the new channel framework. HTTP definitions are mapped on top of this support. When compatibility mode is chosen, the old HTTPTransport objects are migrated and mapped onto the channel architecture. Existing scripts can modify these objects and will run unchanged. See Example: Migrating - Modifying the embedded transports in an application server for examples.

   Process definition: The name of this object is changed from processDef to processDefs. We can mitigate this change by using the compatibility mode mapping provided by the migration tools. The change to scripts to use the new location is as follows:

   Old example:

   • Using Jacl

     set processDef [$AdminConfig list JavaProcessDef $server1]
     set processDef [$AdminConfig showAttribute $server1 processDefinition]
     

     Jython

     processDef = AdminConfig.list('JavaProcessDef', server1)
     print processDef
     

   New example. Identify the process definition belonging to this server and assign it to the processDefs variable:

   • Using Jacl

     set processDefs [$AdminConfig list JavaProcessDef $server1]
     set processDefs [$AdminConfig showAttribute $server1 processDefinitions]
     

     Jython

     processDefs = AdminConfig.list('JavaProcessDef', server1)
     print processDefs
     

3. Prepare for required changes.

   1. Be aware of the implications of migrating JMS applications from the embedded messaging in WebSphere Application Server V5 to the default messaging provider in WAS V6. See Migrating from v5 embedded messaging for more information.

   2. A new version of Jacl (1.3.1) is shipped with WebSphere Application Server V6. 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.1, 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.

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

 

See also

Example: Migrate - Allowing configuration overwrite when saving a configuration

 

Related Tasks

Manage WebSphere version 5 JMS use of WebSphere v6 JMS resources
Migrate from version 5 embedded messaging to v6

 

See Also

Wsadmin tool

 

Related Information

Migration and coexistence overview

 

---