WebSphere Enterprise Service Bus for z/OS, Version 6.2.0 Operating Systems: z/OS


Configuration mapping during product-configuration migration

Various configurations are mapped during product-configuration migration.

Many migration scenarios are possible. The migration tools map objects and attributes existing in the version from which you are migrating to the corresponding objects and attributes in the newer version's environment.

Command-line parameters

The migration tools convert appropriate command-line parameters to Java™ virtual machine (JVM) settings in the server process definition. Most settings are mapped directly. Some settings are not migrated because their roles in the WebSphere® ESB version 6.2 configuration do not exist, have different meanings, or have different scopes.

For information on how to change the process-definition settings, see Process definition settings in the WebSphere Application Server information center. For information on how to change the Java virtual machine settings, see Java virtual machine settings in the WebSphere Application Server information center.

Policy file
WebSphere ESB version 6.2 migrates all the policy files that are installed with version 6.0.x or 6.1.x policy files with the following characteristics:
  • Any comments located in the version 6.2 policy file will be preserved. Any comments contained in theversion 6.0.x or 6.1.x policy file will not be included in the version 6.2.
  • Migration will not attempt to merge permissions or grants; it is strictly an add-type migration. If the permission or grant is not located in the version 6.2 file, the migration will bring it over.
  • Security is a critical component; thus, the migration makes any additions at the end of the original .policy file right after the comment MIGR0372I: Migrated grant permissions follow. This is done to help administrators verify any policy file changes that the migration has made.
Properties and lib/app directories

Migration copies files from prior version directories into the WebSphere ESB version 6.2 configuration.

Property files

WebSphere migrates all the property files that are installed with version 6.0.x or 6.1.x by merging settings into the version 6.2 property files.

Migration does not overlay property files.

Resource adapter archives (RARs) referenced by J2C resources

RARs and JARs that are referenced by J2C resources are migrated as follows:

Migrating cluster-level resources

Cluster-level resources are configured in resourcexxx.xml files under the cluster directories. For example:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

If you have a cluster-level resource, this resource must be in the same location on each cluster member (node). Using the above example, therefore, each cluster member must have the RAR file installed at location ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} is resolved on each cluster member to get the exact location.

In the migration of a deployment manager, the tools migrate the cluster files on the deployment manager, including the resourcexxx.xml files.

In the migration of a managed node, the tools process each J2C adapter. Files such as RAR files are migrated as follows from version 6.0.x or 6.1.x to version 6.2:
  • Migration from version 6.0.2.x to version 6.2: The migration copies files such as RAR or JAR files from WAS_INSTALL_ROOT to WAS_INSTALL_ROOT and from USER_INSTALL_ROOT to USER_INSTALL_ROOT
  • Migration from version 6.1.x to version 6.2: The migration copies configuration files as follows:
    • If you install RAR or JAR as part of WebSphere ESB installation, then the configuration files are migrated to the migration target profile and updated to point to the new version of the RAR and JAR files.
    • If you install RAR or JAR files after the installation of WebSphere ESB, then the following will occur
      • If you install the RAR or JAR files under the previous WebSphere ESB installation, only the configuration files are migrated, and you need to either copy or install those RAR or JAR files on the migration target profile and make sure the configuration is correct before starting the server.
      • If you install the RAR or JAR files outside of the previous WebSphere ESB installation (which is recommended), then the configuration files are migrated and you do not need to take any action after migration.

If you hardcoded a path to a RAR file (archivePath="C:/WAS/installedConnectors/x2.rar" for example) in version 6.0.x or 6.1.x, however, the version 6.2 migration tools cannot change the archivePath attribute to reflect this because that would break all of the other cluster members that have not been migrated.

Samples

During migration of a stand-alone profile, no WebSphere ESB samples are migrated. Equivalent version 6.2 samples are available for all version 6.2 samples

Security
Note: The following security information applies only if you are migrating from version 6.0.2.x

Java 2 security is enabled by default when you enable security in WebSphere ESB version 6.2. Java 2 security requires you to grant security permissions explicitly.

There are several techniques that you can use to define different levels of Java 2 security in version 6.2. One is to create a was.policy file as part of the application to enable all security permissions. The migration tools call the wsadmin command to add an existing was.policy file in the version 6.2 properties directory to enterprise applications as they are being migrated.

When migrating from WebSphere ESB version 6.0.2.x to version 6.2, your choice of whether or not to migrate to support script compatibility results in one of two different outcomes.
  • If you choose to migrate to support script compatibility, your security configuration is brought over to version 6.2 without any changes.

    This is the default.

  • If you choose not to migrate to support script compatibility, the security configuration is converted to the default configuration for WebSphere ESBversion 6.2. The default version 6.2 security configuration acts almost the same as in the previous versions, but there are some changes.

    For example, existing keyfiles and trustfiles are moved out of the SSLConfig repertoire and new keystore and truststore objects are created.

    All SSL configuration repertoires of the System Secure Sockets Layer (SSSL) type, except those that belong to the daemon, are converted to the Java Secure Socket Extension (JSSE) type.

In order to retain the same security settings, you need to migrate the WebSphere Application Server security settings that might have been set for version 6.0.2.x. For more information on migrating your security configurations to version 6.2, see Migrating, coexisting, and interoperating - Security considerations in the WebSphere Application Server information center.

Stdin, stdout, stderr, passivation, and working directories

In WebSphere ESB for z/OS®, outputs for stdin, stdout, and stderr are directed to SYSOUT by default. If they are redirected to the configuration directory of a previous version, you might need to change this in the Version 6.1 JCL.

The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate version 6.2 defaults are used.

For more information on passivation directories, see EJB container settings. For more information on working directories, see Process definition settings.

If WebSphere ESB for z/OS user IDs have home directories in the configuration directory of a previous version, you should update them before migration to reside in another location.

In a coexistence scenario, using common directories between versions can create problems.

Transport ports

The migration tools migrate all ports. The tools log a port-conflict warning if a port is already defined in the configuration. You must resolve any port conflicts before you can run servers at the same time.

If the -portBlock parameter is specified in the WBIPostUpgrade part of the process, a new value is assigned to each transport that is migrated.

You must manually add virtual host alias entries for each port. For more information, see Configuring virtual hosts.

Web modules

The specification level of the Java 2 Platform, Enterprise Edition (J2EE) implemented in WebSphere ESB version 6.0.x or 6.1.x required behavior changes in the Web container for setting the content type. If a default servlet writer does not set the content type, not only does the Web container no longer default to it but the Web container returns the call as "null." This situation might cause some browsers to display resulting Web container tags incorrectly. To prevent this problem from occurring, migration sets the autoResponseEncoding IBM® extension to "true" for Web modules as it migrates enterprise applications.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/doc/cmig_vtv_configmap.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).