WebSphere Application Server V6.
x
Script Compatibility
Authors:
Dana Duffield
Michael Cheng
Leigh Williamson
Table of Contents
Introduction ...................................................................................................................................... 3
Changes introduced in v6.0............................................................................................................. 4
Parsing output of the ObjectName class .................................................................................... 4
regexp Jacl command.................................................................................................................. 4
Http Transports to Channels ........................................................................................................ 4
Transaction log directory.............................................................................................................. 5
ProcessDefinition rename............................................................................................................ 5
JMS Server removed ................................................................................................................... 6
New exceptions are thrown for some conditions ......................................................................... 6
taskInfo command keywords ....................................................................................................... 6
Changes introduced in v6.1............................................................................................................. 6
Foreign cell bindings bootStrapAddress ...................................................................................... 7
CCF and SAS features removed ................................................................................................. 7
DB2 for zOS Local JDBC Provider (RRS) is removed................................................................. 7
System SSL supported for Daemon only..................................................................................... 8
SIB Bus creation .......................................................................................................................... 8
SSL configuration......................................................................................................................... 8
History:............................................................................................................................................. 8
2 1/30/2007
Introduction
This document describes one particular aspect of compatibility for WebSphere Application Server,
namely changes that are required for maintaining wsadmin scripts. Note that this document is
based on a section of another document “WebSphere Application Server Version 6 System
Management Features” and shares some common source with that document. Much of the
Version 6 section of this document is the same as that document. Information was added for
some new version 6 impacts as well as all version 6.1 information.
The table below provides a summary and indicated impacts based on WebSphere Application
Version supported platform and version. The remaining sections briefly describe the change,
resolution and provide references when applicable. An entry of “Yes” indicates that that column is
affected, an entry of “No’ indicates no impact.
The column “Mitigation via Migration tools” indicates whether or not using the WebSphere
Migration tools with the default of scriptCompatibility will provide some mitigation. For those
affected changes the tools will create the new configuration using the “old” model of the
configuration so existing wsadmin scripts will still work. See the following for more information
[Link]
/rmig_convertscript.html
Change Mitigation V6.0 V6.0 zOS V6.1 V6.1 zOS
via Distributed Distributed
Migration and i5OS and i5OS
tools
Parsing output of the No Yes Yes Yes Yes
ObjectName class
regexp Jacl command No Yes Yes Yes Yes
Http Transports to Yes Yes No Yes Yes
Channels
Transaction log directory Yes Yes Yes Yes Yes
ProcessDefinition rename Yes Yes No Yes No
JMS Server removed No Yes Yes Yes Yes
New exceptions are No No Yes No Yes
thrown for some
conditions
taskInfo command No No Yes No Yes
keywords
Foreign cell bindings Yes No No Yes Yes
bootStrapAddress
CCF and SAS features No No No Yes Yes
removed
DB2 for zOS Local JDBC No No No No Yes
Provider (RRS) is
removed
System SSL supported for No No No No Yes
Daemon only
SIB Bus creation No No No Yes Yes
SSL configuration Yes No No Yes Yes
3 1/30/2007
Changes introduced in v6.0
A good general reference is
[Link]
/txml_migrate.html
Parsing output of the ObjectName class
Due to changes in the JMX specification for allowed format of the ObjectName class, the configID
used in Version 6 contains a vertical bar character ('|") instead of a colon character (':') as a
delimiter. This change in configID format should not present a problem for most wsadmin scripts
because configIDs are not guaranteed to be consistent between wsadmin executions and should
not be stored persistently for reuse. ConfigIDs should always be retrieved from a query of the
configuration executed right before their usage in a script. Support is also provided for
interoperability between v5.x and v6.x nodes. Automatic transformation is performed between
v5.x and v6.x JMX when an ObjectName is transferred between the two runtimes through JMX
calls.
regexp Jacl command
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 Version
5 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:
[Link]: error while eval'ing Jacl expression:
couldn't compile regular expression pattern: ?+* follows nothing
The regular expression syntax that produces these exceptions will have to be adjusted so as to
work as specified by the tcl 8.0 rules.
Further reference:
[Link]
/txml_migrate5to6.html
Http Transports to Channels
The new architecture for Version 6 uses the new channel framework for communication and
associated endpoint configuration. HTTP definitions for the Web Container are mapped on top of
this channel framework support. When compatibility mode is chosen for Version 5 migration, the
old HTTPTransport objects are left in the configuration so that existing scripts can modify these
objects and will run unchanged. The channel framework runtime code will recognize the presence
of old HTTPTransport configuration and issue a warning message in the logs to indicate that the
configuration should be upgraded.
If new Version 6 application servers are defined, or if the migration compatibility mode for
scripting is not used, the migration logic will map the old HTTPTransport objects into new channel
framework configuration and older wsadmin scripts will fail to have any effect on the system. This
is because the older scripts will update the HTTPTransport configuration objects but the runtime
will see the new channel framework configuration and honor that instead of the older setting.
Old example (using Jacl wsadmin syntax):
4 1/30/2007
$AdminConfig modify $web_container {{transports:HTTPTransport {{
{address {{host *} {port 9080}} } }}}}
New example (using Jacl wsadmin syntax):
$AdminConfig list ServerEntry $node
set se <select one of the ServerEntry from output of above command>
set eprs [lindex [$AdminConfig showAttribute $se specialEndPoints] 0]
foreach ep $eprs {
set epName [$AdminConfig showAttribute $ep endPointName]
if {$epName == " WC_defaulthost"} {
$AdminConfig modify $ep {{ {endpoint {{host *} {port 9080}} }}
}
}
Further reference:
[Link]
/txml_migrate5to6.html
Transaction log directory
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 wsadmin syntax):
set transService [$AdminConfig list TransactionService $server1]
$AdminConfig showAttribute $transService transactionLogDirectory
New Location (using Jacl wsadmin syntax):
$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
Further reference:
[Link]
/txml_migrate5to6.html
ProcessDefinition rename
The name of the Server Process Definition configuration object has changed from processDef to
processDefs for Distributed and i5OS. This is unchanged for zOS. The change to scripts to use
the new syntax is as follows:
Old example (using Jacl wsadmin syntax, assume $server1 is configID of the default server):
set processDef [$AdminConfig showAttribute $server1 processDefinition]
New example (using Jacl wsadmin syntax, assume $server1 is configID of the default server):
set processDefs [$AdminConfig showAttribute $server1 processDefinitions]
Further reference:
5 1/30/2007
[Link]
/txml_migrate5to6.html
JMS Server removed
The JMS support was re-engineered in version 6.0. A side effect of this is that the JMS Server as
a separate server instance no longer exists in the version 6.0 configuration. It is unlikely that your
scripts are directly referencing the JMS Server Object( more than likely you will be interacting with
JMS resources ), but if you are then your scripts will need to be modified.
Further reference:
[Link]
n0040_.html
New exceptions are thrown for some conditions
The Systems management code was unified across the WebSphere platforms in version 6.0.
When this happened some of the behaviors changed on the zOS platform. One of these changes
was to throw exceptions for more cases than previously were detected. This can cause some
scripts to change behavior, One example of this is throwing an exception on a stopServer
command when that server has already been stopped.
The solution is to include more try/catch blocks around wsadmin commands using syntax as
follows:
if { [catch {“yourCommandHere”}] }
{ puts "it failed" }
else
{ puts "it was ok" }
taskInfo command keywords
The Systems management code was unified across the WebSphere platforms in version 6.0.
When this happened some of the behaviors changed on the zOS platform. One of these changes
as in the casing of AdminApp taskInfo command keywords. Many task names have changed
between V5.x and V6.x for similar or the exact same operation. You may need to update existing
scripts if you are migrating from V5.x to V6.x
For example, some of the old task commands were: "module", "EJB", "uri", while the new task
commands are: "Module", "EJB", "URI",
Further reference:
[Link]
series/ae/rxml_adminapp.html
Changes introduced in v6.1
A good general reference is
[Link]
/txml_migrate.html
6 1/30/2007
Foreign cell bindings bootStrapAddress
The ability to configure foreign cell name bindings enables your applications to access other
applications in other cells. A foreign cell is a cell other than the one in which an application
resides. A foreign cell name binding is a context binding that resolves to the Cell Root context of
a foreign cell. The format of this has changed in the v6.1 default configuration.
Edit your version 5.x or 6.0.x foreign cell binding scripts, replacing bootstrapAddress with
bootstrapAddresses, the list property introduced in version 6.1.
The bootstrap address properties are in the context of the ForeignCell class. The fully qualified
name for the version 5.x or 6.0.x property now deprecated is the following:
[Link]:Cell/foreignCells/bootstrapAddress
The fully qualified name for the bootstrap address list property introduced in version 6.1 is the
following:
[Link]:Cell/foreignCells/bootstrapAddresses
Version 6.1 and later foreign cell binding scripts should use the bootstrap address list property,
bootstrapAddresses.
Further reference:
[Link]
/tnam_migrat_bootstrap.html
CCF and SAS features removed
Both CCF and SAS have been removed from version 6.1 after proper deprecation. Any resources
that were configured to use these features will need to be changed to use the new functions. For
CCF this is J2C, for SAS it is JAAS. The exception is the Daemon process of zOS. This will still
use System SSL.
Further reference:
[Link]
/rmig_deprecationlist.html
[Link]
/tdat_impjcaapi.html
[Link]
/tsec_migratecorba.html
DB2 for zOS Local JDBC Provider (RRS) is removed
WebSphere® Application Server for z/OS version 6.1 will not support integration with the legacy
DB2 JDBC Driver. This was accomplished in prior versions of WebSphere Application Server for
z/OS using the DB2 for zOS Local JDBC Provider (RRS). You will need to use the DB2 Universal
driver instead. There is migration tooling available to assist in this conversion as noted below.
Further reference:
[Link]
series/ae/cmig_pre.html
JDBC migration utility for Legacy to Universal DB2 drivers
7 1/30/2007
[Link]
System SSL supported for Daemon only
In version 6.1 support for zOS System SSL has been removed for all servers except the Daemon.
Use JSSE instead of System SSL.
Further reference:
[Link]
series/ae/rmig_deprecationlist.html
SIB Bus creation
A new parameter is on the createSIBus command related to Security. This change is a side-effect
of the other changes to the Security model in v6.1. The –secure parameter has been deprecated
and is ignored. It controlled whether or not global security controlled the SIBus Security. The
busSecurity parameter has been added.
Set this option to TRUE to enforce the authorization policy for the bus, which also requires
administrative security to be enabled. Set this option to FALSE if you always want to disable bus
security. If administrative security is disabled the bus is insecure.
Further reference:
[Link]
c/ref/rjj_cli_bus_create.html
SSL configuration
A new way of configuring SSL was introduced in version 6.1. When migrating to version 6.1, you
can update the format for SSL configuration or you can continue to use the version 6.0 format. If
you encounter errors with your existing administration scripts for SSL configurations, you can
manually convert your SSL configuration to the V6.1 format. If you create a new profile without
doing Migration you will be using the new SSL model and you must modify your scripts.
Further reference:
[Link]
o/iseriesnd/ae/txml_migratesecurity.html
History:
Version Date Changes
1.0 January 16 2007 Initial Version
1.1 January 30 2007 Added JMS Server and foreign cell references
8 1/30/2007
9 1/30/2007