Migrating administrative scripts from 5.x to 6.0

 

Migrating administrative scripts from 5.x to 6.0

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

  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:

    • Using 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. You 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]
      Using 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]
      Using 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 Version 5 to the default
      messaging provider in WebSphere Application Server Version 6. See Migrating from version 5 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 Version 6. If your scripts contain code to set the enable attribute on the CacheInstanceService type, remove the code. It is not needed in Version 6.



Sub-topics
Example: Migrating - Allowing configuration overwrite when saving a configuration

Related tasks
Migrating from version 5 embedded messaging to version 6

Related reference
Wsadmin tool

Related information
Migration