Why and when to perform this task
WebSphere Application Server Version 6 is generally interoperable with WebSphere Application Server Versions 4.0.x and 5.x. However, there are specific requirements to address for each version. In general, IBM recommends that you apply the latest fix level to support interoperability. If this is not possible, then the following interim fixes can be used to support your environment.
Steps for this task
Interim fix | Version 4.0.1 | Version 4.0.2 | Version 4.0.3 | Version 4.0.5 | Version 4.0.6 | Version 4.0.7 |
---|---|---|---|---|---|---|
PQ60074 | Apply | Apply | ||||
PQ60336 | Apply | Apply | ||||
PQ63548 | Apply | Apply | Apply | |||
PQ88648 (which requires PQ88653) | Apply | Apply | Apply | |||
PQ88973 | Apply | Apply | Apply |
Interim fix | Version 5.0.0 | Version 5.0.1 | Version 5.0.2 |
---|---|---|---|
PQ88973 | Apply | Apply | Apply |
PQ89426 (which requires PQ88653) | Apply (or move to 5.0.2.8) |
Interim fix | Version 5.1.0 | Version 5.1.1 |
---|---|---|
PQ84384 | Apply (or move to 5.1.0.4 or higher) |
All fixes are available on the Support site for WebSphere Application Server products. There is a link to the Support site for WebSphere Application Server products at the bottom of each information center topic. Scroll all the way to the bottom of each page to see the link.
The best solution is to upgrade all your installations to the latest release and PTF levels, such as Version 4.0.4, which do not require this fix. If this solution is not possible, apply the fix to your version.
Symptoms include org.omg.CORBA.MARSHAL exceptions when passing embedded valueTypes across the versions. Sometimes, other symptoms might mask org.omg.CORBA.MARSHAL exceptions, which makes them difficult to identify.
If symptoms reoccur in spite of the fix, re-export existing IORs.
java.rmi.MarshalException: CORBA MARSHAL 0x4942f89a No; nested exception is: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Invalid start_value valuetag: c minor code: 4942F89A completed: No
A number of core classes evolved between Software Development Kit (SDK) 1.3.x and SDK 1.4.x. You can experience problems interoperating with WebSphere Application Server, Version 6, which uses SDK 1.4.x.
Guideline | Version 5.x | Version 4.0.x |
---|---|---|
1 | Apply (V5.0.2 only) | Apply |
2 | Apply | |
3 | Apply | |
4 | Apply | |
5 | Apply | |
6 | Apply | Apply |
com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false
com.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true
Always apply this guideline to V4.0.x. For V5.0.2, apply this guideline in addition to applying interim fixes (or moving to V5.0.2.8).
After federating an application server node into a deployment manager cell, you cannot use the migration tools. To use these tools again, remove the node from the cell, use the tools, and add the node to the cell again.
You cannot use the administrative interfaces for Version 6 to administer a Version 4.0.x administrative server. Likewise, you cannot use a Version 4.0.x administrative console to administer a Version 6 environment. If you use the administrative console on a remote machine to administer Version 4.0.x WebSphere Application Server domains, migrating any of the nodes or domains to Version 6 renders the remote administration console ineffective for administering any Version 6 environment.
Some clients cannot call WLM-enabled enterprise beans on remote clusters when there is a local WLM-enabled enterprise bean of the same name. If there is a cluster local to the client with the same enterprise bean as the remote cluster that the client is trying to call, the client ends up talking to the local cluster.
What to do next
This information is dynamic and might be augmented by information in technical articles that are available on the IBM DeveloperWorks WebSphere site. Check the site for the latest information.
Related tasks
Configuring and viewing name space bindings
Related reference
Container interoperability
EJB binding settings
JNDI interoperability considerations