IBM WebSphere Application Server, Version 5.0.2 Release Notes

WebSphere Application Server Network Deployment, Version 5.0.2

This document contains the Release Notes for IBM WebSphere Application Server, Version 5.0.2. For the very latest updates, view the English online version of the Release Notes located at http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp .

Tips: If you use Internet Explorer on Windows 2003 platforms, you need to change the security settings of Internet Explorer. The default security settings are restrictive to the information center.

Documentation for Version 5.0.2

You can find the Getting started information, which includes an overview and installation instructions for IBM WebSphere Application Server, Version 5, on the product CD-ROM as a PDF file. This PDF file is provided in English only. For the latest information on installing and using the product, see the online information center located at: http://www-3.ibm.com/software/webservers/appserv/infocenter.html .

To find installation information for Fix Pack 2, Version 5, see http://www-3.ibm.com/software/webservers/appserv/support/ .

WebSphere Application Server Enterprise customers should not install Fix Pack 2 for the WebSphere Application Server or WebSphere Application Server Network Deployment products

WebSphere Application Server Enterprise, Version 5 customers must wait for the Enterprise Fix Pack 2 before applying Fix Pack 2 to the WebSphere Application Server product or to the WebSphere Application Server Network Deployment product. The WebSphere Application Server Enterprise product must be at the same fix level as the base product or the Network Deployment product that it extends.

Applying Fix Pack 2 to the WebSphere Application Server product without applying it to the WebSphere Application Server Enterprise product causes the Enterprise environment to fail.

Support for Linux platforms on iSeries and pSeries servers is now available

WebSphere Application Server support for Linux platforms on iSeries and pSeries servers is now available. Please refer to http://www-3.ibm.com/software/webservers/appserv/was/requirements/ and http://www-3.ibm.com/software/webservers/appserv/doc/latest/prereq.html for hardware and software requirements.

WebSphere Application Server Support page

To review, download, and install any recommended or mandatory interim fixes, visit the WebSphere Application Server Support page at the following Web site:

http://www.ibm.com/software/webservers/appserv/was/support/ .

From the main page, click All Updates (Fixes, patches, etc.) in the Download section. This action takes you to the page to search for a specific download package.

Supplemental documentation. The following documentation supplements the IBM WebSphere Application Server, Version 5.0.2 documentation, located at http://www.ibm.com/software/webservers/appserv/infocenter.html .

Table of contents

Installation and uninstallation release notes

All platforms

AIX

Applicability of the following list:

Solaris

Linux

HPUX

UNIX

Windows 2000

Windows

Tips: For other installation and uninstallation problems associated with WebSphere embedded messaging, see Messaging and Extended messaging release notes.

Uninstall fixes for IBM HTTP Server and MQ Series (Embedded Messaging) before installing fix pack updates to these features

If you have installed fixes for IBM HTTP Server or MQ Series Embedded Messaging, you need to uninstall these fixes prior to updating these features using the Update Installer. If you do not uninstall these fixes, the updates to IBM HTTP Server or Embedded Messaging made during the fix pack installation might fail or the installation might be faulty. You can choose to skip the updates IBM HTTP Server or Embedded Messaging if they are not required during fix pack installation. See the Update Installer documentation for more information.

The updateWizard interface does not recognize the existing WebSphere Application Server product

Symptom On some platforms, the updateWizard interface to the update installer program does not recognize the existing WebSphere Application Server product.
Problem The problem is due to a limitation in the InstallShield for MultiPlatforms (ISMP) program that the update installer program uses. The ISMP program does not recognize previous installations of WebSphere Application Server on some operating platforms.
Recommended response To work around the problem, click Specify product information and type the fully qualified installation root directory for the existing product in the Installation directory field of the updateWizard panel.

Stop all running Java processes before you install or remove fix packs or interim fixes to avoid a corrupted system

Symptom The fix pack installer does not warn you to stop all running Java processes before you install or remove fix packs or interim fixes. Your system gets corrupted if you do not manually stop all running processes.
Problem unidentified
Recommended response It is recommended to stop all applications (IBM and non-IBM) that might be using the Java processes before installing or removing interim fixes or fix packs. For example, in a co-existence scenario, if you have WebSphere Application Server, Version 4 installed, stop its server too. Another example: if you have Tomcat installed, it is recommended to stop this too.

You must manually stop all running Java processes before installing or removing fix packs or interim fixes. See the Readme files for Fix Pack 1, Fix Pack 2, or the update installer; or see the following information center topics for more information:

  • Installing interim fixes and fix packs
  • Removing interim fixes and fix packs
  • UpdateSilent command
  • UpdateWizard command

Installing Fix Pack 2 for the security.wssecurity component takes a long time

Symptom Installing Fix Pack 2 for the security.wssecurity component takes a long time.
Problem During the installation of Fix Pack 2 for the base WebSphere Application Server product, the update installer can take approximately 80 minutes to install service to the security.wssecurity component. Do not cancel the installation during that time.
Recommended response Do not cancel the installation while the update installer is applying service to the security.wssecurity component.
Note This problem does not happen frequently.

WebSphere Application Server, Version 5.0.2 only updates IBM HTTP Server 1.3.26.x

The update installer only updated IBM HTTP Server 1.3.26.x not IBM HTTP Server 2.0. The update installer does not do any IBM HTTP Server version checking so it is important to ensure that you are applying WebSphere Application Server, Version 5.0.2 to the IBM HTTP Server 1.3.26.x.

Uninstall the Web services technology preview before installing Fix Pack 2

Symptom The uninstaller for the Web services technology preview does not cancel the registration of the administrative console panels when run.
Problem When the installer is created for the Web services technology preview in the WebSphere Application Server, Version 5 stream, the installation process is verified, but the uninstallation process is not. It is now a prerequisite for the Web services technology preview to be uninstalled prior to the application of Fix Pack 2.
Recommended response Perform the following steps to work around this problem:
  1. Open a command prompt.
  2. Change the directory to install_root\bin .
  3. Execute the setupCmdLine.bat file (on RedHat Linux, this file is setupCmdLine.sh)
  4. Execute the PluginProcessor.bat file (on RedHat Linux, this file is PluginProcessor.sh) with the following syntax:
    PluginProcessor.[bat,sh] -uninstall -pluginId "com.ibm.ws.webservices.console"

The WebSphere MQ installation directory might be incorrect in the installation summary panel

Symptom If you perform a WebSphere Application Server Enterprise full installation and specify a custom installation location for WebSphere MQ, the custom installation location cannot be displayed correctly on the installation summary panel (the last panel displayed prior to installation). The summary panel incorrectly displays the default installation location.
Problem There is no actual problem; the summary panel display is simply incorrect. The custom installation location is correctly used during the installation. WebSphere MQ is installed in the correct location.
Recommended response Ignore the WebSphere MQ location specified in the installation summary panel.

Recommended approach to installing WebSphere Application Server on top of WebSphere MQ

When planning to install a WebSphere Application Server, Version 5 release on a machine that already has a copy of WebSphere MQ V5.3 installed on it, you are recommended to complete the following steps:

  1. Ensure that all the WebSphere MQ features required by the WebSphere Application Server embedded messaging are installed:
     - on UNIX:
       - for WebSphere Application Server Network Deployment or Client: Java Messaging
      - for WebSphere Application Server (base): Runtime, Base (or SDK), Server, Client, 
    Java Messaging and All Message Catalogs 
      - on Windows:
      - for WebSphere Application Server ND or Client: Java Messaging 
      - for WebSphere Application Server (base): Server and Java Messaging
  2. Ensure that WebSphere MQ v5.3 is upgraded to the appropriate prerequisite CSD level:
    - CSD1 for WebSphere Application Server v5.0
    - CSD3 for WebSphere Application Server v5.0.1
    - CSD4 for WebSphere Application Server v5.0.2 and v5.1.0
  3. Install the WebSphere Application Server V5 GM release.
  4. Install any appropriate WebSphere Application Server fix packs.

After the initial installation of WebSphere MQ and WebSphere Application Server, you should service WebSphere MQ independently of the WebSphere Application Server fix packs (for example, you should download and apply the WebSphere MQ V5.3 CSD4 before upgrading your WebSphere Application Server to V5.0.2). This approach helps to avoid failures in uninstalling WebSphere Application Server fix packs.

An error occurs when you use the wsadmin tool with the Remote Method Invocation connector and Security enabled, if you only install the administrative scripting client as your WebSphere Application Server base installation

Symptom The following error occurs when you try to use the wsadmin tool with the Remote Method Invocation (RMI) connector and Security enabled, if your WebSphere Application Server base installation consisted only of installing the administrative scripting client.
C:\WebSphere\AppServer\bin>wsadmin  -host smhardh1   -conntype  RMI -port  9809
WASX7023E: Error creating "RMI" connection to host "smhardh1"; exception information: 
com.ibm.websphere.management.exception.ConnectorNotAvailableException
WASX7213I: This scripting client is not connected to a server process; 
please refer to the log file
C:\WebSphere\AppServer\logs\wsadmin.traceout for additional information.
WASX7029I: For help, enter: "$Help help"  
wsadmin>exit
Problem When you install the administrative scripting feature from the WebSphere Application Server base installation, the certpath.jar file is missing in thejava/jre/lib/ext directory. When you use the RMI connector, you need this JAR file.
Recommended response To solve this problem, perform a WebSphere Application Server full installation and get the certpath.jar file from the ${install_root}/java/jre/lib/ext directory and copy it to the administrative scripting ${install_root}/java/jre/lib/ext directory.

An alternative is to install the full WebSphere Application Server base installation which includes the certpath.jar file.

Log in appropriately to pick up secondary user groups for root

Problem When you install WebSphere Application Server on all platforms except Windows platforms, the following entries are displayed in the SystemOut.log file:
[date time CDT] 60cf2faf JMSRegistrati A MSGS0601I: WebSphere Embedded Messaging 
has not been installed
[date time CDT] 60cf2faf JMSEmbeddedPr A MSGS0050I: Starting the Queue Manager
[date time CDT] 60cf2faf JMSEmbeddedPr E MSGS0058E: Unable to start the JMS Server 
as WebSphere Embedded Messaging has not been installed
[date time CDT] 60cf2faf JMSService    E MSGS0001E: Starting the JMS Server failed 
with exception: java.lang.Exception: MSGS0058E: Unable to start the JMS Server as 
WebSphere Embedded Messaging has not been installed

Also, the following associated messages are added to the mq_install.log file:

wmsetup: date time Checking if user "root" is in group "mqm"
wmsetup: date time
wmsetup: date time ERROR: Group "mqm" exists, id "root" is defined to the group but does not
wmsetup: date time have the group in its current set of effective groups.
wmsetup: date time Current group membership is :
wmsetup: date time uid=0(root) gid=0(system) groups=2(bin)
wmsetup: date time You may need to login.
wmsetup: date time
wmsetup: date time ... RC 4 from Check_root
wmsetup: date time ERROR: User "root" not in group "mqm" 
wmsetup: date time Check_root mqbrkrs
wmsetup: date time Checking for group "mqbrkrs" ...
wmsetup: date time lsgroup returned "mqbrkrs id=203 admin=false users=root adms=root registry=files " RC=0
wmsetup: date time Checking if user "root" is in group "mqbrkrs"
wmsetup: date time
wmsetup: date time ERROR: Group "mqbrkrs" exists, id "root" is defined to the group but does not
wmsetup: date time have the group in its current set of effective groups.
wmsetup: date time Current group membership is :
wmsetup: date time uid=0(root) gid=0(system) groups=2(bin)
wmsetup: date time You may need to login.
wmsetup: date time
wmsetup: date time ... RC 4 from Check_root
wmsetup: date time ERROR: User "root" not in group "mqbrkrs"

Recommended response To prevent this problem, use ssh instead of telnet to log in.

As a workaround, after logging in and experiencing this problem, run the following command:

su -

Verifying that no files exist in the install_root/classes directory during installation

Problem The install_root/classes directory is reserved for testing and debugging fixes when customers call IBM Support. Having files in the directory during installation can cause various problems depending on the fix left in the directory.
Recommended response Verify that no files exist in the install_root/classes directory.

When IBM Support queues work for you and provides you test or debug fixes, you put the fixes in the install_root/classes directory. By default, the install_root/classes directory is picked up first in the WebSphere Application Server class path to let it override other classes.

This directory lets you verify or debug a fix. After accepting the test fix or finishing with the debugging of the debug fix, delete the fix from the install_root/classes directory to return the system to a working state. If you do not remove such fixes from the install_root/classes directory, you can experience errors.

Remove testing and debugging fixes before installing

Problem The install_root/classes directory is reserved for testing and debugging fixes when customers call IBM Support. Having files in the directory during installation can cause various problems depending on the fix left in the directory.
Recommended response Verify that no files exist in the install_root/classes directory.

When IBM Support queues work for you and provides you test or debug fixes, you put the fixes in the install_root/classes directory. By default, the install_root/classes directory is picked up first in the WebSphere Application Server class path to let it override other classes.

This directory lets you verify or debug a fix. After accepting the test fix or finishing with the debugging of the debug fix, delete the fix from the install_root/classes directory to return the system to a working state. If you do not remove such fixes from the install_root/classes directory, you can experience errors.

WebSphere Application Server products at level 5.0.0 might not support your operating system

AIX Solaris


To support some operating system platforms, you must install WebSphere Application Server Version 5 from the CD-ROM and then apply a fix pack. You must install Fix Pack 1 or 2 to support AIX 5.2. Fix Pack 2, which is product level 5.0.2 supports the Solaris Operating Environment 9. To install on either an AIX 5.2 or a Solaris 9 platform, follow the procedure in the information center topic, "Installing the product" to download and use an updated prereqChecker.xml file to install the V5 installation image. Using the current prereqChecker.xml file verifies that you have all required operating system patches. After installing the product at the V5 level , you can install the appropriate fix pack for your operating system.

Uninstalling a WebSphere Application Server fix pack fails because the external.mq component cannot be uninstalled

Solaris

Symptom On Solaris Operating Environment, consider the scenario where you:
  1. Install WebSphere Application Server V5 (base or Network Deployment).
  2. Install the WebSphere Application Server V5.0.1 fix pack release.
  3. Install the WebSphere Application Server V5.0.2 fix pack release.
  4. Uninstall the WebSphere Application Server V5.0.2 fix pack release (to return to the WebSphere Application Server V5.0.1 release).

The last step fails and the following messages are displayed in the /opt/WebSphere/AppServer/logs/update/date_time_was50_fp2_solaris_uninstall.log directory:

Results:
=========================================================
Time Stamp (End)      : dateTtime
PTF Component Result  : failed
PTF Component Result Message:
=========================================================
WUPD0246E: Fix pack update failure: An exception occurred while preprocessing 
the content of fix pack was50_fp2_solaris, component external.mq
=========================================================

Also, the following messages are displayed in the date_time_was50_fp2_solaris_external.mq_uninstall.log directory :

wmservice: date time ==================================================================================================
wmservice: date time Date: Tue Jul 1 16:18:10 BST 2003
wmservice: date time ==================================================================================================
wmservice: date time Hostname: slipstream
wmservice: date time Operating System: SunOS
wmservice: date time User: uid=0(root) gid=1(other)
wmservice: date time Command line is: /opt/WebSphere/AppServer/properties
/version/backup/external.mq/ptfs/was50_fp2_solaris/components/external.mq/CSD/wmservice 
uninstall /opt/WebSphere/AppServer/logs/update/date_time_was50_fp2_solaris_external.mq_uninsta
ll.log
wmservice: date time Function is uninstall
wmservice: date time Get_ver_rel mqm.java
wmservice: date time Checking for installed product "mqm", class "java"
wmservice: date time Check for csd levels
expr: syntax error
wmservice: date time ... mqm.java 5.3.0.
wmservice: date time uninstall of CSD not possible, current level is 5.3.0.
wmservice: date time Exiting - return code 23

Problem The last step of the WebSphere Application Server fix pack uninstall fails because the external.mq component cannot be uninstalled.
Recommended response To fix this problem, complete the following steps:
  1. Delete the mqVer.properties file in the /opt/WebSphere/AppServer/properties/version/backup/external.mq/ptfs/was50_fp2_solaris/components/external.mq/ directory.
  2. Remove the upgrade that was applied to the external.mq component by running the following command as root:
    pkgrm mqm-upd04 
    
    Reply y[es] to all prompts.

    Note: Do not remove mqm-upd04 if you have installed IBM WebSphere MQ as a separate product.

  3. Retry the uninstallationl of Fix Pack 2.

Uninstalling WebSphere Application Server, without first removing any fix packs, does not remove the embedded messaging components

HPUX UNIX Solaris


Problem After apparently uninstalling WebSphere Application Server successfully, some embedded messaging packages still exist.
Recommended response To fix this problem, manually uninstall the embedded messaging components by following the instructions in the WebSphere Application Server information center, under the topic, "Uninstalling WebSphere Application Server."

Uninstalling fix pack fails when External MQ already installed

Solaris

Problem Consider the scenario on Solaris Operating Systems, where you have installed WebSphere MQ with the CSDs needed for WebSphere Application Server, then install WebSphere Application Server, and one WebSphere Application Server fix pack (for example, WAS 5.0.1 or WAS 5.0.2). If you try to uninstall the fix pack release to return to the GA level of WebSphere Application Server, the uninstall process fails and the following messages are displayed in the /opt/WebSphere/AppServer/logs/update/..._was50_fpn_solaris_uninstall.log:
PTF Results: ========================================================= Time Stamp (End)      
: dateTtime PTF Result            : failed PTF Result Message: 
========================================================= WUPD0243E: Fix pack uninstall 
failure: 
The update for component was50_fpn_solaris for fix pack external.mq could not be 
uninstalled. 
========================================================= 

In addition, the following message are displayed in the date_time_was50_fpn_solaris_external.mq_uninstall.log:

wmservice: date time =============================================================================================
wmservice: date time Date: Tue Jul 1 16:18:10 BST 2003 wmservice: date time 
================================================================================================== 
wmservice: date time Hostname: slipstream wmservice: date time Operating System: 
SunOS wmservice: date time User: uid=0
(root) gid=1(other) wmservice: date time Command line is: /opt/WebSphere/AppServer/
properties/version/backup/external.mq/pt
fs/was50_fpn_solaris/components/external.mq/CSD/wmservice uninstall /opt/WebSphere/
AppServer/logs/update/date_time_was50_fp
2_solaris_external.mq_uninstall.log wmservice: date time Function is uninstall 
wmservice: date time Get_ver_rel mqm.java wm
service: date time Checking for installed product "mqm", class "java" wmservice: 
date time Check for csd levels expr: syntax
 error wmservice: date time ... mqm.java 5.3.0.2.4 wmservice: date time 
Uninstall_service .... pkgrm: ERROR: no package ass
ociated with <mqm_upd02> wmservice: date time return code 1 from pkgrm wmservice: 
date time ... Uninstall_servi
ce returns 1 wmservice: date time Return code 1 from Uninstall_wsm wmservice: date time 
Exiting - return code 1 wmservice: 
date time ============================================================

The last step of the WebSphere Application Server fix pack uninstallation fails because the external.mq component cannot be uninstalled.

Recommended response To fix this problem, delete the mqVer.properties file in the /opt/WebSphere/AppServer/properties/version/backup/external.mq/ptfs/was50_fpn_solaris/components/external.mq/directory, where was50_fpn_solaris indicates the fix pack release (for example, was50_fp2_solaris for Fix Pack 2). Then retry the uninstall of the fix pack release (for example, Fix Pack 1 or Fix Pack 1).

WebSphere Application Server for Linux on iSeries must be installed from Linux partition

Linux

On an iSeries V5R1 system, it is necessary to install the CD-ROM for IBM WebSphere Application Server for Linux on iSeries and pSeries, V5.0.2, directly from a Linux partition or from a downloaded image on the Linux partition. Because OS/400 V5R1 does not support the RockRidge extension, copying the files from the CD-ROM to the IFS file system on OS/400 and then installing from the copied files will not finish successfully. The copy operation will fail with CPFA0BB and CPFA1C5 error messages, and installation from the copied files will result in an error that a suitable Java Virtual Machine (JVM) cannot be found.

Unable to launch the installation of the base WebSphere Application Server product, the Network Deployment product, or the Enterprise product from the LaunchPad on Linux390 systems with a 64-bit architecture

Linux

Problem If you install the the base WebSphere Application Server product, the Network Deployment product, or the Enterprise product on Linux390 systems with 64-bit architecture, you cannot launch the installation of the product from the LaunchPad.

The LaunchPad is launched from the CD by running the following command:

./launchPad.sh

From the LaunchPad, if you select Install Product, you can get the following error:

No matching JVM was found.

The installation of the product cannot continue.

Recommended response

To determine if you have a 64-bit architecture that might cause this problem, type the following command at the command line:

uname -m

If s390x is returned, you have a 64-bit architecture and can experience this problem. Do not attempt to install the product from the LaunchPad. Instead, from a command line, change the directory to the CD installation root directory, and run the following command.

./install.sh
The product installation should continue successfully.

If s390x is returned, you have a 32-bit architecture, and you can perform the product installation from the LaunchPad.

If s390 is returned, you have a 32-bit architecture, and you can perform the product installation from the LaunchPad.

Unable to launch installation of the base WebSphere Application Server product, the Network Deployment product, or the Enterprise product from the LaunchPad on Linux386 SuSE SLES 8 systems

Linux

Symptom If you install the base WebSphere Application Server product, the Network Deployment product, or the Enterprise product on Linux386 SuSE SLES 8 systems, you cannot launch the installation of the product from the LaunchPad.
Problem The LaunchPad is launched from the CD by running the following command:
./launchPad.sh

However, you can receive the following error:

dirname: error while loading shared libraries: libc.so.6: cannot open shared object 
file: No such file or directory
./LaunchPad.sh: line 10: ./jre/bin/java: No such file or directory

The installation of the product cannot continue.

Recommended response Do not attempt to start the LaunchPad with the LaunchPad.sh script. Instead, from a command line, change the directory to the CD installation root directory, and run the following command.
./jre/bin/java -jar launchpad.jar

The product installation should continue successfully.

Ensure that the required utilities and compatibility libraries are installed before installing WebSphere Application Server on RedHat V8 platforms running on Intel-based machines

Linux

Problem On RedHat V8 platforms running on Intel-based machines, during the Application Server startup process, the following entries are displayed in the SystemOut.log file:
[date time EST] 1cda953b JMSEmbeddedPr A MSGS0052I: Starting the Broker
[date time EST] 1cda953b BrokerManager E MSGS0255E: Broker Manager unable 
to attach to Queue Manager - unknown Queue
[date time EST] 1cda953b JMSService    E MSGS0001E: Starting the JMS Server 
failed with exception: com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2085

The following associated messages are added to the mq_install.log file:

which: no uudecode in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
  The program uudecode was not found on this system.  This will not prevent
  the installation, however you should run the command "amqiclen -x"
  after the installation has completed, before queue managers are started.

Also, the createMQ log shows the following:

 Issuing: env wempsdeletebroker WAS_redhat801_jmsserver -w
  wempsdeletebroker: error while loading shared libraries: 
libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
  rc=127
  Issuing: env wempscreatebroker WAS_redhat801_jmsserver -i dummy -a dummy -q 
WAS_redhat801_jmsserver -n "" -u "" -p "" -b -j
  wempscreatebroker: error while loading shared libraries: libstdc++-libc6.2-2.so.3: 
cannot open shared object file: No such file or directory
  rc=127
  Issuing: env wempsservice WAS_redhat801_jmsserver -r BrokerUUID=FFFFFFFF-
0000-0000-0000-000000000000
  wempsservice: error while loading shared libraries: libstdc++-libc6.2-2.so.3: 
cannot open shared object file: No such file or directory
  rc=127

Recommended response To prevent this problem, ensure that the required utility package (which includes uuencode and uudecode) and the libstdc++ compatability libraries are installed; for example, RH8.0/RPMS/shareutils. (The RPMS are on the Linux distribution CDs.) The exact name and version number of the package depends on the Linux distribution:

Dependancy RedHat package name SuSE package name
uudecode sharutils sharutils
libstdc++ compatability libraries compat-libstdc++ compat (needs to be version 2002.12.6.0 or later)


On Linux/Intel (RedHat V8) platforms, installation of WebSphere Application Server hangs during the embedded messaging installation stage

Linux

Symptom On Linux (RedHat v8), the installation of WebSphere Application Server hangs during the embedded messaging installation stage. The last line of the mq_install.log is:
wmsetup: date time Installing MQSeriesClient-5.3.0-1.i386.rpm 
MQSeriesMsg_Zh_CN-5.3.0-1.i386.rpm 
         MQSeriesMsg_Zh_TW-5.3.0-1.i386.rpm MQSeriesMsg_de-5.3.0-1.i386.rpm 
MQSeriesMsg_es-5.3.0-1.i386.rpm 
         MQSeriesMsg_fr-5.3.0-1.i386.rpm MQSeriesMsg_it-5.3.0-1.i386.rpm 
MQSeriesMsg_ja-5.3.0-1.i386.rpm 
         MQSeriesMsg_ko-5.3.0-1.i386.rpm MQSeriesMsg_pt-5.3.0-1.i386.rpm 
MQSeriesRuntime-5.3.0-1.i386.rpm 
         MQSeriesSDK-5.3.0-1.i386.rpm MQSeriesJava-5.3.0-1.i386.rpm 
MQSeriesServer-5.3.0-1.i386.rpm:

The last line of the master install log (/tmp/log.txt) is:

(date time), Setup.product.install, com.ibm.wizard.platform.linux.LinuxProductServiceImpl, 
msg1,installing Exec Action From Directory (mqUnixInstallAction

Problem RPM lock files exist that prevent the product installation from continuing.
Recommended response For information about solving this problem, see the bugzilla report at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74726

Installing WebSphere Application Server, Version 5.0.2 Network Deployment on top of WebSphere Application Server, Version 5.0.1 Network Deployment fails on Linux/Intel

Linux

Problem The installation of WebSphere Application Server Network Deployment, Version 5.0.2 on top of WebSphere Application Server Network Deployment, Version 5.0.1 fails on the Linux/Intel platform. The following message displays in the /opt/WebSphere/DeploymentManager/logs/update/20030703_152306_was50_nd_fp2_linux_selective-install.log file.
PTF Results:
=========================================================
Time Stamp (End)      : 2003-07-03T15:23:09Z
PTF Result            : failed
PTF Result Message:
=========================================================
WUPD0218E: Fix pack installation failure: The component external.mq failed to install.

The associated errors in the /opt/WebSphere/DeploymentManager/logs/update/20030703_152306_was50_nd_fp2_linux_external.mq_install.log file are:

wmservice: 03Jul03 15:23:08 Installing MQSeriesServer-U486878-5.3.0-4.i386.rpm 
MQSeriesJava-U486878-5.3.0-4.i386.rpm MQSeriesSDK-U486878-5.3.0-4.i386.rpm 
MQSeriesRuntime-U486878-5.3.0-4.i386.rpm MQSeriesClient-U486878-5.3.0-4.i386.rpm
error: failed dependencies:
        MQSeriesServer = 5.3.0 is needed by MQSeriesServer-U486878-5.3.0-4
        MQSeriesSDK = 5.3.0 is needed by MQSeriesSDK-U486878-5.3.0-4
        MQSeriesRuntime = 5.3.0 is needed by MQSeriesRuntime-U486878-5.3.0-4
        MQSeriesClient = 5.3.0 is needed by MQSeriesClient-U486878-5.3.0-4
wmservice: 03Jul03 15:23:08 ERROR: Return code 5 from rpm -i 
MQSeriesClient-U*-5.3.0-4.i386.rpm MQSeriesMsg_Zh_CN-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_Zh_TW-U*-5.3.0-4.i386.rpm MQSeriesMsg_de-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_es-U*-5.3.0.4.i386.rpm MQSeriesMsg_fr-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_it-U*-5.3.0-4.i386.rpm MQSeriesMsg_ja-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_ko-U*-5.3.0-4.i386.rpm MQSeriesMsg_pt-U*-5.3.0-4.i386.rpm 
MQSeriesRuntime-U*-5.3.0-4.i386.rpm MQSeriesSDK-U*-5.3.0-4.i386.rpm 
MQSeriesJava-U*-5.3.0-4.i386.rpm MQSeriesServer-U*-5.3.0-4.i386.rpm
wmservice: 03Jul03 15:23:08 ERROR: installation of mqm CSD failed - rolling back
wmservice: 03Jul03 15:23:08 Rollback entered - error code 19

Recommended response If you require the Embedded Messaging component, uninstall WebSphere Application Server Network Deployment, Version 5.0.1 before installing WebSphere Application Server Network Deployment , Version 5.0.2 on Linux/Intel.

Ignoring some error messages when installing WebSphere Application Server with embedded messaging from the CD-ROM

HPUX

Problem On HP-UX, when installing WebSphere Application Server with embedded messaging from the CD-ROM, the following warning messages are issued despite successful installation:
MQSERIES.MQM-CL-HPUX: A test command parameter is not valid." and "* 
"hostname:/cdrom/hpux/messaging/images":  Cannot open the
  logfile on this target or source.  Possibly the media is
  read-only or there is a permission problem." on mq_install.log.  
Recommended response You can ignore the warning messages, because the problem does not affect the successful installation of WebSphere Application Server with embedded messaging.

Installing WebSphere Application Server Network Deployment before WebSphere Application Server (base) creates an exception in SystemOut.log

HPUX

Symptom On HP-UX platforms, if you install WebSphere Application Server Network Deployment first, then later install WebSphere Application Server (base), the following exception is written to the SystemOut log file when you attempt to start WebSphere Application Server:
[date time CDT]   25491d JMSService    E MSGS0001E: Starting the JMSServer failed with 
exception: java.lang.Exception: MSGS0101E: Start Queue Manager command failed with exit code: 71
Problem In this specific scenario, the/var/mqm/mqs.ini directory needed to start the queue manager is missing.
Recommended response As a workaround, after completing the installation, and before starting the WebSphere Application server, run the following command:
ln -s /opt/mqm/lib/nls/C/amq.cat /usr/lib/nls/C/amq.cat

Now, copy the mqs.ini file from the /opt/mqm/samp directory to the /var/mqm directory

Finally, rerun the createMQ script:

./wasHome/bin createmq.sh <wasHome><cellName><nodeName><serverName>

where <wasHome> is the installation directory (that defaults to /opt/WebSphere/AppServer).

If you are not sure about your cellName, nodeName, and serverName, check the first line in the createMQ logfile that can be located in the wasHome/logs directory. The first line identifies the wasHome, cellName, nodeName, and serverName parameters passed to the script.

Note: Generally, you should install WebSphere Application Server (base) before installing WebSphere Application Server Network Deployment on the same host.

Uninstalling WebSphere Application Server Network Deployment does not remove the WebSphere MQ Java Client

UNIX

Problem On UNIX platforms, when uninstalling WebSphere Application Server Network Deployment, the following messages are displayed in the mq_uninstall.log file:
wmsetup: date time ==================================================================================================
wmsetup: date time Date: Tue Jun 24 12:17:58 PDT 2003
wmsetup: date time ==================================================================================================
wmsetup: date time Hostname: alinppc04
wmsetup: date time Operating System: Linux
wmsetup: date time User: uid=0(root) gid=0(root) groups=0(root),64(pkcs11),500(mqm),501(mqbrkrs)
wmsetup: date time Command line is: /opt/WebSphere/DeploymentManager/_uninst/mq/wmsetup uninstall /opt/WebSphere/DeploymentManager/mq_uninstall.log
wmsetup: date time Function is uninstall
wmsetup: date time Uninstall_wsm
wmsetup: date time Checking for installed wemps-runtime ...
wmsetup: date time package wemps-runtime is not installed
wmsetup: date time WebSphere Embedded Messaging not installed - no action required
wmsetup: date time Checking for installed MQSeriesRuntime ...
wmsetup: date time package MQSeriesRuntime is not installed
wmsetup: date time Return code 0 from Uninstall_wsm
wmsetup: date time Exiting - return code 0
wmsetup: date time ============================================================
Recommended response To resolve this problem, manually uninstall the embedded messaging components by following the instructions in the WebSphere Application Server information center, under the topic, "Uninstalling WebSphere Application Server.

On Windows 2003 Server, WebSphere Embedded Messaging Publish and Subscribe Edition does not uninstall

Windows

Symptom On Windows 2003 Server, after using Add and Remove Programs to uninstall WebSphere Application Server, if you close and then reopen Add and Remove Programs, you still see an entry for WebSphere Embedded Messaging Publish and Subscribe Edition. If you then try use Add and Remove Programs to remove WebSphere Embedded Messaging Publish and Subscribe Edition, you get a notice for Fatal Error during installation.
Problem On Windows 2003 Server, after using Add and Remove Programs to uninstall WebSphere Application Server, the WEMPS product is sometimes not removed. To prevent this problem, try using Add and Remove Programs to uninstall WEMPS before uninstalling WebSphere Application Server.
Recommended response As a workaround, manually remove the registries of Windows 2003 Server for WEMPS. To manually remove WEMPS, do the following steps:
  1. Go to www.microsoft.com .
  2. Click Downloads in the left panel.
  3. Type Windows Installer Cleanup Utility under Keywords (optional) and click Go.
  4. Follow the instructions to install the msicuu.exe program.
  5. Click Start > Run in your desktop.
  6. Select the product IBM WebSphere EMPS and click Remove.
  7. Remove the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphereEmbeddedMessagingPublishAndSubscribe.

  8. Delete the WEMPS directory, by default C:\Program Files\IBM WebSphere EMPS, and all its contents.

For more information about manually uninstalling messaging components, see the information center topic, "Manually uninstalling on Windows platforms." You can find this topic from the navigation panel by All topics by Feature > Getting started > Uninstalling WebSphere Application Server > Manually uninstalling on Windows.

Interoperability release notes

Problems with Xerces versions that are not Java 2 Platform, Enterprise Edition compliant

Problem Programs containing the Xerces parser routine that work on IBM WebSphere Application Server, Version 4.0.x might not work on IBM WebSphere Application Server, Version 5.

Versions of Xerces prior to 2.0.0, including the versions shipped with IBM WebSphere Application Server, Version 4.0.x, were not J2EE1.3 compliant. To meet J2EE1.3 certification constraints (DOM2/SAX2/JAXP1.1 (and no higher)), IBM WebSphere Application Server, Version 5 requires XML4J4.0.0 (Xerces 2.0 bug fixes).

In Xerces versions prior to 2.0.0 and Xalan versions prior to 2.2, the DOM, SAX, and JAXP APIs were bundled inside of the xerces.jar and xalan.jar files. In the most recent versions, these non-Apache XML APIs have moved into a separate JAR file in the XML common apache project. These common XML APIs are required by the specifications and contained within the IBM WebSphere Application Server, Version 5 j2ee.jar file.

The cause of the problem is that the class loader behavior mixes the classes that are required by J2EE1.3 with those of the older Xerces implementation.

Recommended response To work around this problem, use the version that ships with IBM WebSphere Application Server, Version 5.

Samples release notes

WebSphere Application Server, Version 5.0.2 Samples installation and instructions

WebSphere Application Server Version 5.0.2 contains updates for the Samples, translations for all Samples, and a new Web Services Sample. The Samples documentation update is located in the samples50_fp2 directory. You can find this directory in the root directory of WebSphere Application Server. The file name is readme.html and there is a translated Readme file for each supported language. The document contains instructions for uninstalling the WebSphere Application Server, Version 5 and Version 5.0.1 Samples, and installing the new Web Services Sample and the Version 5.0.2 Samples.

Installing the Applet Client Samples feature from the Application Clients 1.4 CD-ROM

If you install the Applet Client Samples feature from the Application Clients 1.4 CD-ROM, perform the following steps to update the Java security policy.

Add the following grant blocks into the client.policy file under the properties directory of the Application Clients installation root, for example, C:\Program Files\WebSphere\AppClient\properties\client.policy , if they are not present. Modify the entries for yourserver.yourdomain.com to reflect the complete name of the WebSphere Application Server to which you connect :

grant {
  permission java.io.FilePermission "${was.install.root}/samples/lib
/TechnologySamplesAppletClient/BasicCalculatorAppletClient.jar", "read";
  permission java.io.FilePermission "${was.install.root}/samples/lib
/TechnologySamplesAppletClient/BasicCalculatorClientCommon.jar", "read";
  permission java.io.FilePermission "${was.install.root}/samples/lib
/TechnologySamplesAppletClient/BasicCalculatorEJB.jar", "read";
};

grant codeBase "file:${was.install.root}/samples/lib/TechnologySamplesAppletClient/*" {
  permission java.util.PropertyPermission "*", "read";
  permission java.net.SocketPermission "yourserver.yourdomain.com", "connect";
};

grant codeBase "file:${was.install.root}/samples/lib/TechnologySamplesAppletClient/*" {
  permission com.ibm.websphere.security.WebSphereRuntimePermission "AdminPermission";
};

Adding the grant blocks to avoid receiving an exception when running Applet Client Samples from the Application Clients Version 5.0.2

Symptom When you run the Applet Client Samples from the Application Clients Version 5.0.2, the following exception is logged in the Java console of the browser:
--Looking-up Home... java.lang.ExceptionInInitializerError: 
java.security.AccessControlException: access denied (com.ibm.websphere.security.
WebSphereRuntimePermission AdminPermission)   
    at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:286)      
    at java.security.AccessController.checkPermission
(AccessController.java(Compiled Code))  
    at java.lang.SecurityManager.checkPermission
(SecurityManager.java(Compiled Code))        
    at com.ibm.websphere.management.AdminServiceFactory.getAdminService
(AdminServiceFactory.java:55)
Problem Additional access control policy is required for the Application Clients Version 5.0.2 to run the Applet Client Samples.
Explanation You can encounter this problem if you view the log in the Java console of the browser.
Recommended response To avoid this exception, add the following grant blocks into the client.policy file under the properties directory of the Application Clients installation root, for example, C:\Program Files\WebSphere\AppClient\properties\client.policy, if they are not present.
For JDK 1.3 client installs:
grant codeBase 
"file:${was.install.root}/samples/bin/TechnologySamplesAppletClient/BasicCalculator/*" {
  permission com.ibm.websphere.security.WebSphereRuntimePermission "AdminPermission";
};

For JDK 1.4 client installs:
grant codeBase 
"file:${was.install.root}/samples/lib/TechnologySamplesAppletClient/*" {
  permission com.ibm.websphere.security.WebSphereRuntimePermission "AdminPermission";
};

Information you should know about the Java 2 Platform, Enterprise Edition client samples launchAPI and classLoader

Symptom When running the Java 2 Platform, Enterprise Edition (J2EE) classLoader sample, the application output looks like the following:
-----------------------------------------------------------------
Running ClassLoaderClientMain from the 
J2EEAppClientClassLoader.ear file
-----------------------------------------------------------------

IBM WebSphere Application Server, Release 5.0
J2EE Application Client Tool
Copyright IBM Corp., 1997-2002
WSCL0012I: Processing command line arguments.
WSCL0013I: Initializing the J2EE Application Client Environment.
WSCL0100E: Exception received: com.ibm.etools.archive.exception.ArchiveWrappedEx
ception
Stack trace of nested exception:
com.ibm.etools.archive.exception.ResourceLoadException: IWAE0007E Could not load
 resource "META-INF/ibm-application-client-bnd.xmi" in archive "J2EEAppClientCla
ssLoaderClient.jar"
Stack trace of nested exception:
java.lang.NullPointerException
      at com.ibm.etools.archive.impl.InternalModuleHelper.getDDResourceURIIfPr
oxy(InternalModuleHelper.java:60)
      at com.ibm.etools.archive.impl.InternalModuleHelper.getDDResourceIfProxy
(InternalModuleHelper.java:64)
      at com.ibm.etools.archive.impl.InternalModuleHelper.appClientBindingsLoa
ded(InternalModuleHelper.java:146)
      at com.ibm.etools.archive.impl.InternalModuleHelper.fixupBndOrExtRootsIf
Necessary(InternalModuleHelper.java:44)
   ... more

When running the J2EE launchAPI sample, the application output looks like the following:

------------------------------------------------------------------ 
Running LaunchAPIClientMain from the LaunchAPI.ear file 
using launch API 
------------------------------------------------------------------ 
IBM WebSphere Application Server, Release 5.0 
J2EE Application Client Tool 
Copyright IBM Corp., 1997-2002 
WSCL0013I: Initializing the J2EE Application Client Environment. 
launch() failed.  See stack trace for details: 
java.lang.reflect.InvocationTargetException         
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. 
java:79)         					 
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces 
sorImpl.java:41)       
      at java.lang.reflect.Method.invoke(Method.java:371)         
      at com.ibm.websphere.samples.j2eeappclients.launchapi.LaunchAPIMain.main 
(LaunchAPIMain.java:83) 
Caused by: com.ibm.websphere.client.applicationclient.ClientContainerException: 
com.ibm.etools.archive.exception.ArchiveWrappedException 
Stack trace of nested exception: 
com.ibm.etools.archive.exception.ResourceLoadException: IWAE0007E Could not load  
 resource "META-INF/ibm-application-client-bnd.xmi" in archive "LaunchAPIClient. 
jar" 
Stack trace of nested exception: 
java.lang.NullPointerException         
      at com.ibm.etools.archive.impl.InternalModuleHelper.getDDResourceURIIfProxy
(InternalModuleHelper.java:60)         
      at com.ibm.etools.archive.impl.InternalModuleHelper.getDDResourceIfProxy 
(InternalModuleHelper.java:64)         
      at com.ibm.etools.archive.impl.InternalModuleHelper.appClientBindingsLoa 
ded(InternalModuleHelper.java:146)         
   ... more
Problem The file meta-inf/ibm-application-client-bnd.xmi in the J2EEAppClientClassLoaderClient.jar file in the samples/lib/J2EEAppClients/J2EEAppClientClassLoader.earfile is missing the following line :
<applicationClient href="META-INF/application-client.xml#Application-client_ID"/>

The file meta-inf/ibm-application-client-bnd.xmi in the LaunchAPIClient.jar file in the samples/lib/J2EEAppClients/LaunchAPI.ear file is missing the following line:

<applicationClient href="META-INF/application-client.xml#Application-client_ID"/>
Recommended response To solve this problem, complete the following steps:
  1. Add line <applicationClient href="META-INF/application-client.xml#Application-client_ID"/> before the line </clientbnd:ApplicationClientBinding> in the file samples\src\J2EEAppClients\ClassLoader\ClassLoaderClient\META-INF\ibm-application-client-bnd.xmi.
  2. Add line <applicationClient href="META-INF/application-client.xml#Application-client_ID"/> before the line </clientbnd:ApplicationClientBinding> in the file samples\src\J2EEAppClients\LaunchAPI\LaunchAPIClient\META-INF\ibm-application-client-bnd.xmi.
  3. Rebuild these samples by following the instructions in the Application Client Samples Gallery (see the section Client Technology Samples > J2EE application client > Build It Yourself).

Add to cart resets the quantity of an item to one in Pet Store Sample

When an item is added to the shopping cart, the item is added with an initial quantity of one. You can adjust the quantity to a higher number in the shopping cart. If that same item is added again to the shopping cart, the adjusted quantity is reset to one.

Passwords are not compared when creating a new account in Pet Store Sample

When creating a new account, you must provide a new password. The first Password field is not compared for a match with the second Password (Repeat) field.

Pet Store pages do not show animal pictures or details when HTTP transport is reconfigured to use a port other than 9080

Problem If the Pet Store pages do not show animal pictures or details when you reconfigure the IBM WebSphere Application Server to use an HTTP transport other than port 9080, update the URL of Pet Store Catalog DAOSQLURL to use the new port.
Recommended response You can reconfigure the URL resource to use the new port with the IBM WebSphere Application Server administrative console. Go to Resources > URL Providers (set scope to your Server) > Samples URL Provider - HTTPs > URLs > Pet Store Catalog DAO SQL URL. The port number is in the Specification field.

Forceful repopulating of Pet Store database fails

Problem The option to forcefully repopulate the Pet Store database fails with an internal server error HTTP 500 - The page cannot be displayed.
Recommended response Do not use this option.

National Language Version issues and limitations

All platforms

Applicability of the following list:

AIX

Linux

Solaris

Applicability of the following list:

Windows 2000

Windows NT

UNIX

HP-UX

Help links for Application Assembly Tool, Application Resource Client Tool and Tivoli Performance Viewer bring up the English files

Problem Help for the Application Assembly Tool, Application Resource Client Tool and Tivoli Performance Viewer appears only in English.
Response Change the path to the preferred language version to display the appropriate language (include list for languages if possible) list separately, if the paths are not the same.

Help search does not return hits for Latin-1 terms with diacritical markings

Problem The help search in the administrative console does not return search results for Latin-1 terms that contain diacritical markings (for example, German "fur", where the "u" includes an umlaut).
Response To work around this problem, use the decimal representation of the character in the search term (for example, "f&#252;r").

Cannot access readme and PDF installation files for Traditional Chinese and German languages through the LaunchPad

Problem You cannot access readme and PDF installation files for Traditional Chinese and German languages through the LaunchPad.
Response In any Web browser, view the following files located on the product CD.

The readme file for Traditional Chinese is located at:

<cd drive>\readme\readme_zh_tw.html

The installation PDF file for Traditional Chinese is located at:

<cd drive>\doc\installguide_zh_tw.pdf

The readme file for German is located at:

<cd drive>\readme\readme_de.html

The installation PDF file for German is located at:

<cd drive>\doc\installguide_de.pdf

Avoid missing characters in license agreement

Before installing the IBM WebSphere Application Server on a Traditional Chinese AIX machine, type the following to avoid missing characters within the license agreement:

cd /usr/lib/nls/loc/iconv/
mv IBM-eucTW_CNS11643.1986-1 IBM-eucTW_CNS11643.1986-1.save
mv big5_CNS11643.1986-1 big5_CNS11643.1986-1.save

Product registration displays as English when installing in Brazilian Portuguese

Problem When registering your product from the installation in Brazilian Portuguese, the product registration page displays in English.
Response To view the registration page in Brazilian Portuguese, you can enter the following URL, <install_root>\prt\PRT_Welcome_ptb.html or register the product using FirstSteps in Brazilian Portuguese.

Running servers in different code pages within a single cell is not supported

Both the IBM WebSphere Application Server Network Deployment node and the IBM WebSphere Application Server nodes must be on the same code page.

The Java virtual machine cannot translate coded Character Set Identifier used by the embedded messaging queue manager

Symptom When running the IBM WebSphere Application Server with global security enabled, the embedded messaging provider can fail to start with a MSGS0504E message and an UnsupportedEncodingException exception:
 MSGS0504E: JMS Server Security Service Thread received Socket Exception:
  java.io.UnsupportedEncodingException: Cp5050
Problem This message indicates that the Java virtual machine (JVM) cannot translate the Coded Character Set Identifier (CCSI) used by the embedded messaging queue manager.
Recommended response To work around this problem, set a locale and language value that map to a code page supported by the JVM. Refer to the WebSphere MQ messaging platform-specific books Web site at http://www-3.ibm.com/software/ts/mqseries/library/manualsa/manuals/platspecific.html for a "WebSphere MQ Platform Quick Beginnings V5.3" manual that is relevant to your platform. Look for a table in the manual with a list of locale and language to CCSI mappings supported by the queue manager. Then, select a locale and language that maps to a CCSID that is supported by the JVM. Set the selected locale and language, and restart the IBM WebSphere Application Server.

Cannot display newly created Windows domain users during application management for the non-English locales only

Symptom The newly created domain users are not retrieved when you perform application management. The newly created groups display correctly, however, and the newly created local users also display correctly.
Problem If you map users to roles by clicking A Role > Choose Users > Find Users, only users created on Primary Domain Controller before adding the client machine to the domain are displayed. If a new user is created while the client machine is already on the domain, the getUser function does not retrieve the new users created on Primary Domain Controller.
Description The getUser application programming interface (API) works correctly for the English locales, but does not work correctly for the non-English locales.

Persisted Session Time is displayed as a kanji character and ????? in Traditional Chinese locales

Symptom The advice name, Persisted Session Time, in the Runtime Performance Advisor (RPA) configuration in the administrative console is shown as a kanji character and ????? in Traditional Chinese locales only.
Problem You can access to the advice configuration setting on the administrative console by clicking Servers > Application Servers > server_name > Runtime Performance Advisor Configuration > Advice Configuration. The advice name, Persisted Session Time, is shown as kanji character and ????? if you select the Traditional Chinese as the language on the Web browser to get access to the administrative console.
Recommended response Treat the advice item displayed as a kanji character and ????? as Persisted Session Time.

Insufficient prerequisites cause warning messages during installation with AIX 4.3.3

AIX
Symptom When installing the Simplified Chinese version of the IBM WebSphere Application Server on AIX 4.3.3, warning messages display because of insufficient prerequisites. The error message indicates that the file levels X11.fnt.ucs.ttf, X11.fnt.ucs.ttf_TW, and X11.fnt.ucs.ttf_KR do not match the level of file X11.fnt.ucs.ttf_CN.
Problem The last file has a level of 4.3.3.25, while the others have the level 4.3.3.
Recommended response To work around this problem, force the installation by modifying the prereqChecker.xml file to the required file level.

Evaluating the product on National Language Version operating systems

AIX Solaris Windows 2000 Windows NT


The following steps are workarounds to evaluate IBM WebSphere Application Server and IBM WebSphere Application Server Network Deployment, Version 5 on National Language Version operating systems.

Changing the locale encoding to English to install WebSphere Application Server on SuSE 8.0 SLES for PowerPC

Linux

Symptom The WebSphere Application Server installation program is corrupted when you start the installation on SuSE SLES 8.0 PowerPC. The double-byte character set (DBCS) languages display the characters incorrectly. The single-byte character set (SBCS) languages display the characters correctly.
Problem The reason for this problem is either missing fonts on the system, or incorrectly called or displayed fonts.
Recommended response Change the locale encoding to English to properly install WebSphere Application Server on SuSE 8.0 SLES for PowerPC. To change the locale, open a terminal or window and complete the following steps:
  1. Type export LC_ALL=C and click Enter.
  2. Type export LANG=C and click Enter.
  3. To verify that the locale is properly set to English, type locale to see that all variables are set to C.

Japanese not recommended on Red Hat Advanced Server Version 2.1

Linux

The Red Hat Advanced Server Version 2.1 GUI language selection menu displays two selections for Japanese: Japanese (eucJP) and Japanese (SJIS).

Click Japanese (eucJP) to install and run the IBM WebSphere Application Server in a Japanese environment. Using Japanese (SJIS) is not recommended.

For reference see the Red Hat Japanese Web site at http://www.jp.redhat.com/support/7.2/sla/rh72faq.html .

A 404 Not Found exception occurs when cells contain nodes on different locales

UNIX

Problem On UNIX platforms, a com.ibm.websphere.management.filetransfer.client.TransferFailedException: File download failed [404].Message: 404 Not Found exception occurs when federating nodes with non-matching double-byte character set (DBCS) locales.
Recommended response Ensure that all nodes incorporated into the same cell are located on host machines with identical locale settings. Cells containing nodes on different locales do not function properly and are not supported.

Patches needed for correct character display of the installation panel on Asian language platforms

HP-UX

Symptom The installation panel displays garbled characters on Asian language platforms, including Korean, traditional Chinese, Japanese, and simplified Chinese, for the HP-UX 11i operating system.
Recommended response Verify that the following patches are installed on your HP-UX 11i machine:

Name Brief Description
B6848BA Ximian GNOME 1.4 GTK+ Libraries for HP-UX 11.00 and 11i
BUNDLE11i Required Patch Bundle for HP-UX 11i, February 2001 or later
PHSS_26974(for 11.0) or PHSS_26973 (for 11i) Korean TrueType fonts
PHSS_24937(for 11.0) or PHSS_26977 (for 11i) Traditional Chinese TrueType fonts
PHSS_26972(for 11.0) or PHSS_26971 (for 11i) Japanese TrueType fonts
PHSS_26976(for 11.0) or PHSS_24975 (for 11i) Simplified Chinese TrueType fonts
PHSS_25091(for 11.0) or PHSS_25092 (for 11i) Common TrueType fonts


You can find these patches at the following URL: http://www.hp.com/products1/unix/java/infolibrary/patches.html#1.

Application servers release notes

Editing the image path for the WebSphere Application Server service

Symptom When starting the WebSphere Application Server service, the Windows operating system might throw an error containing the phrase "Error 193: ... is not a valid Win32 application. Alternatively, it might report Could not start the ... service on Local Computer Error 193: 0xc1.
Problem Certain Windows systems cannot handle spaces in the path to the service executable well.
Recommended response If this problem occurs, complete the following steps:
  1. Click Start > Run.
  2. Enter regedit and click OK.
  3. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IBMWAS5Service.
  4. Double-click ImagePath registry value.
  5. Edit the path to wasservice.exe in the value data field by adding quotes around the path. For exmaple, "C:\Program Files\WebSphere\AppServer\bin\wasservice.exe" "IBMWAS5Service - server1".
  6. Click OK and exit regedit.

The service now starts without any errors.

The service shows incorrect status when the log root is changed

Symptom The WebSphere Application Server service might go to the started state and then return to the stopped state when you start the WebSphere Application Server service even though the server starts successfully. This change in state might happen if the default log root is altered in the variables.xml config file.
Problem The WebSphere Application Server service cannot find the process ID file (for example, server1.pid) to verify that the server starts successfully. The process ID is created relative to the log root.
Recommended response In order for the WebSphere Application Server service to display the correct status, you must modify the log root directory in your variable.xml file back to the default log root directory, for example, C:\WebSphere\AppServer\logs. Otherwise, you must issue the stopServer command to stop the server, for example,
C:\WebSphere\AppServer\bin\stopServer.bat server1

You might get a Java virtual machine core dump on AIX Version 5.2 and Version 5.1 upon server stress

Problem You might get a Java virtual machine (JVM) core dump on AIX Version 5.2 and Version 5.1 upon server stress.
Recommended response Upgrade AIX Version 5.2 to the latest maintenance level. Make sure that bos.mp and bos.mp64 are at least Version 5.2.0.11.

Upgrade AIX Version 5.1 to the latest maintenance level. Make sure that bos.mp64 is at least version 5.1.0.39, bos.mp at least version 5.1.0.38 and APAR "IY36884" is installed.

Object request brokers release notes

The ClassCastExceptions exceptions or Delegate not set error messages occur when you stop and restart an application

Problem When you stop and restart an application, the object request broker (ORB) creates a new ClientDelegate object, though some existing objects still have references to the old ClientDelegate object. The two objects conflict, allowing calls to go to the wrong underlying servant object, which results in the ClassCastExceptions exceptions or Delegate not set error messages followed by further application failures.
Recommended response Apply interim fix PQ85782.

HTTP server release notes

AIX

HP-UX

Linux

Windows

ImagePath entry not updated in registry when you change the document root

When you change the document root in the IBM HTTP Server Version 1.3.28 administration server, the ImagePath entry in the registry, corresponding to the HTTP server, is not updated. There are no reported functionality problems caused by this registry entry.

Forms Proxy Settings and Proxy Cache do not behave correctly

Problem When using Internet Explorer Version 6.0 to view the IBM HTTP Administration server, the Forms Proxy Settings and Proxy Cache do not behave correctly. If you select the radio buttons that display editable fields, the fields do not display.
Recommended response To work around this problem, use another version of the browser.

Using IBM HTTP Server IKEYMAN to create a key database causes a core

Symptom A core occurs while using the IKEYMAN or IKEYCMD utility, or during the IBM HTTP Server Secure Sockets Layer (SSL) initialization.
Problem An incompatibility exists between functions in various C or C++ run-time libraries. Depending on the order that the libraries are loaded, a core can occur or IBM HTTP Server fails to initialize. This problem is seen on various RedHat Intel versions, and SuSE SLES and RedHat on OS/390.
Description The GSKit libraries used by the IKEYMAN utility and the IBM HTTP Server SSL module require the C++ library libstdc++-libc6.1-1.so.2 file on the Intel platform and the libstdc++-libc6.1-2.so.3 file on the OS/390 platform. If the libraries do not exist, the IKEYMAN utility might provide only limited functionality and the IBM HTTP Server SSL fails to initialize. If another version of this library, or another library with a common function, loaded first, it might result in the use of an incompatible library routine.
Recommended response If you encounter this problem, set the environment variable LD_PRELOAD to the following values before starting IBM HTTP Server or IKEYMAN:
  • Intel: export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
  • OS/390: export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-2.so.3
This change forces the library to load first when the application starts.

Specifying the Listen 0.0.0.0.443 directive to the configuration file when you run IBM HTTP Server Version 2.0.42.2 on the Linux for PowerPC operating system

Note:This problem and response scenario is relevant to Secure Sockets Layer (SSL) or secure connection configuration.

Problem A PEER_ID_NOT_SET error occurs in the error log if you run IBM HTTP Server Version 2.0.42.2 on the Linux for PowerPC operating system without first specifying the Listen 0.0.0.0.443 directive to the configuration file to enable SSL.
Recommended response You must specify the Listen 0.0.0.0.443 directive to the configuration file when you connect to IBM HTTP Server Version 2.0.42.2.

The plug-in configuration fails for Domino 6 Web server during a full installation

Symptom The plug-in configuration fails for Domino 6 Web server during a full installation on Solaris Operating Environment, Windows and AIX platforms. The following example from a full installation on Solaris Operating Environment shows the errors thrown during the configuration phase:
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
/opt/lotus/notes/60010/sunspa/liblsxbe.so: ld.so.1: 
/opt/WebSphere/AppServer/java/bin/../bin/sparc/native_threads/java: 
fatal: libxmlcommon.so: open failed: No such file or directory
       at java.lang.ClassLoader$NativeLibrary.load(Native Method)
       at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1414)
       at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1338)
       at java.lang.Runtime.loadLibrary0(Runtime.java:744)
       at java.lang.System.loadLibrary(System.java:815)
       at lotus.notes.NotesThread.load(NotesThread.java:214)
			at lotus.notes.NotesThread.<client>(NotesThread.java:24)
Problem The plug-in configuration fails for Domino 6 Web server during a full installation on Solaris Operating Environment, Windows and AIX platforms. Please note that WebSphere Application Server, Version 5.0.2 is not a full installation on Solaris Operating Environment, Windows and AIX platforms. However, if you currently have a version of WebSphere Application Server product that is older than Version 5, and you want to upgrade your WebSphere Application Server product to Version 5.0.2, you must complete a full installation of Version 5 before installing Version 5.0.2.
Recommended response The solution is to manually configure the Domino Web server to use the plug-in. Complete the following steps:
  1. Start up the Domino Web server.
  2. Access the names.nsf file through your Web browser, for example, http://hostname.raleigh.ibm.com/names.nsf. Then you need to enter the name for the Administrator and the Administrator password.
  3. Click the Configuration link on the left side of the page.
  4. Click the Servers link on the left side of the page.
  5. Click the All Server Documents link on the left side of the page.
  6. Click the server you want to work with WebSphere Application Server.
  7. Click Edit Server at the top left of the center window.
  8. Click Internet Protocols.
  9. In the DSAPI section, add the path to the Domino plug-in. The plug-in gets installed in the WebSphere Application Server bin directory.
  10. Click Save and Close on the upper left hand corner of the center window.

    Note:If on Windows platforms, add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE > SOFTWARE > IBM > WebSphere Application Server > 5.0.0.0. Set the value for this variable to the location of the plugin-cfg.xml file.

  11. Restart the Domino Web server.

Issuing the ls -la command in the IBM HTTP Server directory on the HP platform shows files with 777 permissions

Symptom Issuing the ls -la command in the IBM HTTP Server directory on the HP platform shows files with 777 permissions.
Problem IBM HTTP Server files with world-writeable permissions on the HP platform run the risk of a security exposure.
Recommended response To remove the world-writeable permissions on the files with 777 permissions, issue the following command:
find <IHS install directory> -perm 777 -exec chmod o-w {} \;

For example:

find /opt/HTTPServer -perm 777 -exec chmod o-w {} \; 

You must change the permissions of these files to reduce the risk of security exposures. Also, if you follow these instructions and change the permissions, the functionality of IBM HTTP Server is not adversely affected.

Bringing up the IKEYMAN administrative console with the Conversational Monitoring System option for IBM HTTP server 1.3.28 and IBM HTTP Server 2.0.47

Symptom
  • You cannot bring up IKEYMAN.
  • IKEYMAN does not have the Conversational Monitoring System (CMS) database option to choose from when creating a key database for IBM HTTP Server.
Problem IKEYMAN is changed in Global Security Kit (GSKit) 7 to integrate IKEYMAN for Java Secure Socket Extension (JSSE) that is Java-based and GSKit that is C++-based. IKEYMAN is a tool used to manage digital certificates. You can now use the same IKEYMAN for WebSphere Application Server and IBM HTTP Server. For example, creating a Java Key Store (JKS) or a CMS key database from the same panel within IKEYMAN.

A key database enables a client application to connect to those servers that have digital certificates signed by those certificate authorities (CAs). You must perform extra steps to use the same IKEYMAN with the CMS option in addition to the JKS option. The CMS option is needed when you set up IBM HTTP Server for Secure Sockets Layer (SSL) transactions.

Recommended response Set the JAVA_HOME variable to the location of the IBM Software Development Kit on the machine. If you are using WebSphere Application Server, set the JAVA_HOME variable to the Java Runtime Environment (JRE) that is shipped with WebSphere Application Server.

For example:

  • On the Linux platform: Export the JAVA_HOME=/opt/WebSphere/AppServer/java variable.
  • On the UNIX platform: Run the <IHS install root>/bin/ikeyman, or <WAS_HOME/>bin/ikeyman.sh command, from a command prompt to bring up the IKEYMAN administrative console.
  • On the Windows platform: To bring up IKEYMAN, click Start > Programs > IBM HTTP Server 1.3.28 (or IBM HTTP Server 2.0.47) > Start Key Management Utility, or run <WAS_HOME>/bin/ikeyman.bat at a command prompt.

If you cannot bring up IKEYMAN after the previous steps, perform the following steps:

  1. Set the JAVA_HOME variable to the home of the IBM Software Development Kit for the Java platform located on your machine. If you are using WebSphere Application Server, you should set the JAVA_HOME variable to the JRE that is shipped with WebSphere Application Server.
  2. If you are not using the JRE that comes with WebSphere Application Server, and the gskikm.jar file exists in your JAVA_HOME directory, rename and move the $JAVA_HOME/jre/lib/ext/gskikm.jar file to a directory that is not visible to the IBM Software Development Kit class path, external directory, and the bootstrap class path. For example, on the Linux platform: mv $JAVA_HOME/jre/lib/ext/gskikm.jar/gskfiles/gskikm.jar.org.
  3. Ensure that the java.security file has the following providers:

    Note: You can find the java.security file in the security directory path. For example, the full path to the file on the Windows platform is C:\Program Files\IBM\Java141\jre\lib\security\java.security.

    security.provider.2=com.ibm.crypto.provider.IBMJCE
    security.provider.3=com.ibm.spi.IBMCMSProvider

    If you try to use cryptographic hardware with IBM HTTP Server, ensure that the file contains the following lines in the order that is shown here:

    security.provider.1=com.ibm.spi.IBMCMSProvider
    security.provider.2=com.ibm.crypto.provider.IBMJCE
    security.provider.3=com.ibm.jsse.IBMJSSEProvider
    security.provider.4=com.ibm.crypto.pkcs11.provider.IBMPKCS11

  4. If you are not using an IBM Software Development Kit or if the IBM Software Development Kit files in the lib\ext directory are older than the ones that come with the GSKit, you have to copy all the Java archive (JAR) files from the ibm\gsk7\classes\jre\lib\ext directory to the Java141\jre\lib\ext directory.
    • On the UNIX platform:

      To bring up IKEYMAN, run the<IHS install root>/bin/ikeyman, or <WAS_HOME>/bin/ikeyman.sh command, from a command prompt.

    • On the Windows platform:

      To bring up IKEYMAN, click Start > Programs > IBM HTTP Server 1.3.28 (or IBM HTTP Server 2.0.47) > Start Key Management Utility, or run WAS_HOME/bin/ikeyman.bat at a command prompt.

A null pointer exception is thrown during the interactive installation of IBM HTTP Server on AIX systems

AIX

Symptom When installing IBM HTTP Server as a standalone installation through the administrative console on the AIX platform, you can receive a null pointer Java error on the installation panels, when the installer begins to copy files to your machine.
Problem This situation is caused by an unstable AIX Object Data Manager (ODM) registry.
Recommended response To work around this problem:
  1. Exit the installer.
  2. Issue the lslpp -l|grep IHS command to check if there are remaining IBM HTTP Server registry entries that cannot exist.
  3. If there are remaining IBM HTTP Server registry entries, do a silent installation of IBM HTTP Server by running the following command:
    java -jar setup.jar -silent -P ihs.installLocation=<the desired install location>

Note: To remove the installation silently, add the -silent parameter to the regular uninstall command from the IBM HTTP Server installation location, for example:

java -jar _uninst/uninstall.jar -silent

Cannot start IBM HTTP Server 2.0.47 on AIX 5.2 systems

AIX

Symptom A potential IBM HTTP Server 2.0.47 startup failure exists on AIX 5.2 systems when a non-default AIX resolver configuration is used (for example, in /etc/netsvc.conf), and the IBM HTTP Server configuration file (for example, httpd.conf), uses Listen directives that do not specify an Internet Protocol address. The following is an example of the error messages issued by IBM HTTP Server:
[crit] (78) A remote host did not respond within the timeout period.: alloc_listener: failed to set up sockaddr for ::
Syntax error on line 130 of /usr/IBMIHS/conf/httpd.conf
Listen setup failed.
Problem This error is caused by a defect in the AIX resolver library.
Recommended response The defect is fixed by APAR IY40908 for AIX 5.2. The fix is shipped with AIX52B Gold and later.

Alternatively, you can take one of the following actions to solve the problem:

  • Use the IPv4-specific Listen directive in the IBM HTTP Server configuration file, for example, "Listen 0.0.0.0:80"
  • Do not override the default AIX resolver configuration.
  • Change the following line in the /etc/netsvc.conf file from:
    hosts = local = auth , bind

    to

    hosts = local = auth , bind , local

IBM HTTP Server 2.0.47 supports the AIX 5.1 and 5.2 Fast Response Cache Accelerator feature

AIX

IBM HTTP Server 2.0.47 supports the AIX 5.1 and 5.2 Fast Response Cache Architecture (FRCA) feature through the mod_afpa_cache.so plug-in module. However, you must apply the interim fix IY49388 for AIX 5.2. IBM HTTP Server 1.3.28 does not support the AIX FRCA feature.

Certificate revocation lists are not supported for IBM HTTP Server on HP-UX and Linux/s390

HP-UX Linux


Using certificate revocation lists (CRLs) with IBM HTTP Server HP-UX and Linux/s390 is not supported at this time.

Unable to use the default service names created by the installer because they are common

Windows

Problem In a same version coexistence scenario for IBM HTTP Server Version 1.3.28 or Version 2.0.47 on a Windows platform, you are unable to use the default service names created by the installer because they are common.
Recommended response To work around this problem, perform the following steps:
  1. Install the first copy of IBM HTTP Server, either by itself or with IBM WebSphere Application Server.
  2. Customize the service names for the first install by running the following commands from the first install location:
    apache -k install -n "IHS 1.3.28(1)"
            apache -k install -f conf\admin.conf -n "IHS 1.3.28 Administration (1)"
  3. Edit the AdminAlias directive in the <installLocation 1>\conf\admin.conf file to point to the new service name, for example "IHS 1.3.28(1)".
  4. Remove the default service names installed by the first installation by running:
    apache -k uninstall -n "IBM HTTP Server 1.3.28"
            apache -k uninstall -n "IBM HTTP Administration 1.3.28"
  5. Install the second copy of IBM HTTP Server, either by itself or with IBM WebSphere Application Server. The default service names correspond to the second installation.

Note: The custom service names previously mentioned must be unique on your system and are not required to be those exact strings.

Clustering and Workload management release notes

Applying interim fix PQ76448 when you use the Workload Manager Controller

Problem In a deployed environment where one or more WebSphere Application Servers are unavailable because of a disconnected network adapter, the Performance Monitoring Infrastructure (PMI) metric data cannot be returned back to the Workload Manager Controller (WLMC) even after the adapter is reconnected.
Recommended response To ensure the proper recovery of PMI metric data to the WLMC in either a test or production environment where the network adapter becomes disconnected, you must install interim fix PQ76448 from the following Web site:

http://www.ibm.com/software/webservers/appserv/was/support/ .

From the main page, click All code fixes and support tools in the Software downloads section. This takes you to the page to search for a specific download package.

Application services release notes

Dynamic cache

Cleaning the disk cache files after installing the fix pack if you use the disk cache function

Symptom If the server is configured to use the disk cache, you must delete the disk cache files because the disk cache files are not compatible to the previous version.
Problem Failure to remove the old disk cache files results in a ClassCastException exception in the systemerr.log file when you access the cache from the disk.
Recommended response To delete the disk cache, perform the following steps:
  1. If you do not know the disk cache offload location, do the following steps:
    1. Open the administrative server.
    2. Click Server > Application Server in the administrative console navigation tree.
    3. Click server.
    4. Click Dynamic Cache Service.
    5. The location is specified in the Disk offload field.

    If the location is not specified, the default directory WebSphere/appserver/your_node/server_name/_dynacache is used.

  2. Make sure that the you stop the server and delete all the files under the offload location.
  3. If you use Network Deployment, delete the disk cache files for each server.

Setting the flush attribute to true on every <jsp:include> tag in the cacheable JavaServer Pages file

Symptom When you obtain the JavaServer Pages (JSP) file from the dynamic cache, a part of the page is not displayed.
Problem The flush attribute is set to false on the <jsp:include> tag in the JSP file.
Description When the cacheable JSP file includes another JSP file and if the flush attribute is set to false on the <jsp:include> tag, any data written to the parent output stream before the <jsp:include> tag are not cached.
Recommended response Set flush=true on every <jsp:include> tag in the cacheable JSP file.

EJB modules release notes

The batchUpdate new feature cannot work for an EJB container-managed persistence bean when it is mapped to more than one table

WebSphere Application Server, Version 5.0.2 now has a new feature, batchUpdate, for EJB container-managed persistence (CMP) bean. However, the new feature cannot work for an EJB CMP bean when it is mapped to more than one table. For example, when mapping inherited enterprise beans as root-leaf to a database, the subclass enterprise beans are mapped to two tables.

A single access intent read ahead hint might not refer to the same bean type in more than one relationship

A single access intent read ahead hint might not refer to the same bean type in more than one relationship. For example, if a Department enterprise bean has a relationship employees with the Employee enterprise bean, and also has a relationship manager with the Employee enterprise bean, then a read ahead hint cannot specify both employees and manager.

Enterprise bean deployment and Sybase IMAGE type restrictions

Problem When deploying enterprise beans with container-managed persistence (CMP) types that are non-primitive and do not have a natural Java Database Connectivity (JDBC) mapping, the deployment tool maps the CMP type to a binary type in the database, where it is stored as a serialized instance. For Sybase, the JDBC type LONG VARBINARY is used, which the Sybase driver maps to the native type IMAGE. You cannot use VARBINARY, which has fewer restrictions than IMAGE in Sybase, because it is limited to a size of 255 bytes, which is too small for typical serialized Java objects. The specific restrictions on the IMAGE type are:
  • You cannot use IMAGE type in the WHERE clause of an SQL query.

    You can encounter this restriction whenever an enterprise bean contains an EJB-QL query that has a CMP type in the WHERE clause, which maps to the IMAGE type in the Sybase relational database (RDB).

  • You cannot use IMAGE type in select queries marked DISTINCT. This situation arises in these user scenarios:
    • When the DISTINCT key word is specified in an EJB-QL select query having a Java type mapping to IMAGE.
    • Enterprise beans that have finder and ejbSelect() methods returning java.util. Set and having CMP types mapping to IMAGE.
Recommended response To work around this problem, edit the EJB mappings in the WebSphere Studio Application Developer toolset and do either of the following:
  • Change the CMP type mapping from IMAGE or LONG VARBINARY to VARBINARY. Only take this action if you think the serialized instance of the CMP type is never larger than 255 bytes.
  • Map the CMP type to multiple RDB fields through a composer. For example, if the CMP type is a Java object X with an int field and a string field, then map X to two RDB fields INTEGER and VARCHAR, using a composer.
Refer to the WebSphere Studio Application Developer documentation for more information about using composers.

The CMP11 custom finder execution is interrupted by an exception

Symptom When a client executes a CMP11 custom finder returning a lazy collection or enumeration with greater than 25 elements, an internal failure can occur when WebSphere Application Server loads the 26th or higher referenced element from the database.
Problem The custom finder execution is interrupted by an exception similar to the following:
[6/19/03 19:43:10:345 PDT] 6d6ae585 EJSJDBCFinder E CNTR0040E: Finder failure as a resultof exception java.lang.NullPointerException
    at com.ibm.ejs.container.ContainerManagedBeanO.setCMP11LoadedForUpdate(ContainerManagedBeanO.java:262)
    at com.ibm.ejs.container.EJSHome.getBean(EJSHome.java:1463)
    ...
Explanation This failure causes a problem within the transaction the custom finder is called within, causing a transaction rollback.
Recommended response To resolve this problem, apply interim fix PQ75634 that is available from the following Web site:

http://www.ibm.com/software/webservers/appserv/was/support/.

From the main page, click All code fixes and support tools in the Software downloads section. This takes you to the page to search for a specific download package.

The EJB application using container-managed persistence beans might fail to run with the sql syntax

Symptom The EJB application using container-managed persistence beans might fail to run with the sql syntax. This is an Oracle syntax error dealing with an SQL CAST operation. You can see the following exception in the system:
log java.sql.SQLException: ORA-00910:specified length too long for its datatype
Problem The problem is a bug in the EJBDeploy program.
Explanation An incorrect CAST operator is generated into SQL for EJB entity beans. This happens when there are multiple EJB-RDB mappings in the EJB or JAR file and one of the mappings is for DB2 and another of the mappings is for another database such as Oracle. When there are multiple mappings, the EJBDeploy tool incorrectly assumes that all mappings are for DB2 and generates incorrect sql for the Oracle case.
Recommended response You can work around the problem by removing the unused mappings for the EJB or JAR file.

Client modules release notes

Applicability of the following list:

Install Application Client features before installing the interim fixes or the fix packs to avoid component regression problems

Problem When installing Application Clients V5.0.0 features from the product CD-ROM onto an existing Application Clients V5.0.x system, the installer reinstalls related components at the V5.0.0 level, which is a regression for those components back to the V5.0.0 level.
Recommended response There are two possible installation states in regard to the regression problem:
  • The system has not regressed because you have not yet installed the interim fixes or the fix packs. If this is true, you can avoid the problem by installing all features you might require before installing the interim fixes and the fix packs.
  • The system is already regressed because you have installed the interim fixes or the fix packs, and you then installed additional features from the Application Clients V5.0.0 CD-ROM. If this is true, you can remedy the problem by using the patcher utility to correct product history files and reinstalling the interim fixes or the fix pack. Using the patcher utility is described in the "Installing new features after applying fix packs (patch command)" topic in the English version of the information center.

IBM Software Development Kit is not upgraded successfully when you apply Application Client, Version 5.0.2 on Windows platforms

Symptom When you apply Application Client, Version 5.0.2 fix pack on Windows platform, one of the following errors might occur:
  • Fail to install fix pack on Windows XP Professional operating systems. You can get an error message, WUPD0218E: Fix pack installation failure: The component prereq.jdk failed to install. logged in the <install_root>\logs\update\XXXX_was50_client_fp2_win_selective-install.log file.
  • When executing the versionInfo or the java -version command, it fails with the following error message:
    Can't load library "<was_install_root>\java\jre\bin\core.dll", because Can't find 
    dependent libraries.
    Could not create the Java Virtual Machine.
  • After you install Application Client Version 5.0.2 fix pack, the version of the IBM Software Development Kit is not J2RE 1.3.1 IBM Windows 32 build cn131-20030618 or J2RE 1.3.1 IBM Windows 32 build cn141-20030618. You can retrieve the IBM Software Development Kit version by executing the java -fullversion command.
Problem IBM Software Development Kit is not upgraded successfully when you apply Application Client Version 5.0.2 fix pack on Windows platforms.
Explanation When Application Client is installed from the V5 Application Client CD-ROM, all the files in the <install_root>\java directory and its subdirectories are read-only. This causes a problem when you apply Application Client V5.0.2 fix pack. The installation of the fix pack fails or files in the <install_root>\java directory and its subdirectory are not replaced properly.
Recommended response If you have Application Client V5.0.2 fix pack installed, you must first uninstall the fix pack. It is recommended that you preform the following steps before applying the Application Client V5.0.2 fix pack:
  1. Open the Command Prompt.
  2. Issue the command attrib -r <install_root>\java.
  3. Issue the command attrib -r <install_root>\java\*.* /S /D.
  4. Issue the command xcopy <cdrom>\nt\jdk\java\*.* <install_root>\java /E /Y.
  5. Apply the fix pack.

Replacing the wrong $(WAS_ROOT) value with the correct client installation root directory name

Symptom Wrong values are specified for the com.ibm.ssl.keyStore and com.ibm.ssl.trustStore properties in the sas.client.props files located in the client installation properties directory.
Problem The $(WAS_ROOT) value should be substituted with the location of the client installation root.
Recommended response If the sas.client.props file contains $(WAS_ROOT) as part of the value for the com.ibm.ssl.keyStore and com.ibm.ssl.trustStore properties, edit the sas.client.props file in the properties directory and replace $(WAS_ROOT) with the following client installation root directory name:
  • On AIX platforms, use /usr/WebSphere/AppClient.
  • On UNIX and Linux platforms, use /opt/WebSphere/AppClient.
  • On Windows platforms, use C:\Program Files\WebSphere\AppClient or the directory you specified when installing.

Web services release notes

UDDI

An UDIN2041I error might occur with the wsadmin appserversetupuddi.jacl command

Problem The following scripting error might display when you run the wsadmin appserversetupuddi.jacl command:
UDIN2041I: Starting UDDI application. UDIN8019E: startApplication command for appname caught exception Exc. Values are: appname=UDDIRegistry, Exc=com.ibm.ws.scripting.ScriptingException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: Failed to make the SOAP RPC call: invoke  
Recommended response During installation, if you see the previous error after running the appserversetupuddi.jacl command, you can ignore the error. It is recommended that you start, or stop and restart the application server and then continue.

Errors occur if you stop and restart the UDDI registry application from the administrative console and then use the user console

Problem If you stop and restart the UDDI registry application from the administrative console, and then try to access the registry through the user console, you might find that an Error 500 - object is not an instance of a declaring class is displayed on the user console, and the error message SRVE0026E displays in the system log. You cannot access the UDDI registry until you restart the IBM WebSphere Application Server.
Recommended response To avoid seeing this problem when you restart the UDDI registry application, perform the following steps using the IBM WebSphere Application Server administrative console:
  1. Click Applications > Enterprise Applications.
  2. In the list of applications, locate and click the UDDI application link.
  3. Scroll down to the Related Items section and click Web Modules.
  4. Click gui.war.
  5. Change the Classload Mode value to PARENT_LAST (instead of PARENT_FIRST).

Web services engine

Ignoring the error messages when running the Web services application using an HTTP or a Java Messaging Service transport

Problem When running the Web services application using an HTTP or a Java Messaging Service (JMS) transport in WebSphere Application Server, Version 5.1 and later, the following error messages are displayed in the SystemOut.log file:
[9/30/03 17:58:20:387 CDT]  140727a PrivMBeanRegi E J2CA0108E: the parent MBean for 

[9/30/03 17:58:20:387 CDT]  140727a PrivMBeanRegi E J2CA0108E: the parent MBean for 

<null> could not be found, the identifier used to find the MBean is 
cells/svtlnx2/nodes/svtlnx2/resources.xml#builtin_jmsprovider.

[9/30/03 17:58:35:611 CDT]  17d1b24 ConnectionMan W J2CA0075W: An active 
transaction should be present while processing method allocateMCWrapper.
[9/30/03 17:58:35:625 CDT]  17d1b24 ConnectionMan W J2CA0075W: An active 
transaction should be present while processing method initializeForUOW.
Recommended response Ignore the error messages.

The correct directory of the pwbs_GetUrlPrefixesHelp.html file

Problem Currently, the pwbs_GetUrlPrefixesHelp.html file is incorrectly installed into the ..../adminconsole.war/com.ibm.ws.console.perftuningadmin/nl/en/pwbs_GetUrlPrefixesHelp.html directory and the .../adminconsole.war/com.ibm.ws.console.servermanagement/nl/en/pwbs_GetUrlPrefixesHelp.htmldirectory.
Recommended response To find the pwbs_GetUrlPrefixesHelp.html file from the Publish WSDL panel, you need to copy the file into the .../adminconsole.war/com.ibm.ws.console.webservices/nl/en/pwbs_GetUrlPrefixesHelp.html directory.

Accessing the Web Services for Java 2 Platform, Enterprise Edition Samples

Problem You cannot locate the Web Services Samples after installing WebSphere Application Server, Version 5 Fix Pack 2.

The new and updated Samples are installed into the samples50_fp2 directory for Fix Pack 2.

Recommended response To locate these Samples, inspect the contents of the install_root\samples50_fp2 directory:
  • If there is a readme.html file in that directory, follow those instructions to integrate the Web services for Java 2 Platform, Enterprise Edition (J2EE) Samples into the Samples Gallery.
  • If the readme.html is not present, the Samples Gallery was not installed with the original installation of WebSphere Application Server, Version 5. In this case, you can install the Web services for J2EE Samples by starting the server and using the administrative console to install the install_root\samples50_fp2\lib\WebServicesSamples\ file. To view the Web services for the J2EE Samples documentation after installation, start the server and open the following URL in your Web browser:
    http://localhost:9080/WebServicesSamples/docs/en/websvcsintro.html 

A Java API XML-based remote procedure call Simple Object Access Protocol handler is unable to access EJB container resources

Symptom A Java API XML-based remote procedure call (JAXRPC) Simple Object Access Protocol (SOAP) handler deployed on the server-side to an EJB-based Web service is unable to access the resources of the EJB container. A JAXRPC SOAP handler does not execute in the EJB container.
Problem A JAXRPC SOAP handler executes in the Java 2 Platform, Enterprise Edition (J2EE) 1.3 Web container of a router-module. The router module directs the SOAP request to the target enterprise bean. The environment of the router module container is visible to the handler, while the environment of the EJB container is not visible. This lack of visibility might cause unexpected and possibly misleading results to handlers accessing the container environment.
Recommended response Be aware that J2EE 1.3 does not require the execution of Web services JAXRPC SOAP handlers in an EJB container. Hence you risk encountering the previously described difficulties in your environment, unless you make developers aware of the visibility issue between handlers and the EJB container. (J2EE 1.4, however, requires handlers to execute in the context of the target EJB container.)

The messages that display are always in English regardless of the locale when the wsdeploy tool is run

Symptom The messages that display are always in English regardless of the locale when the wsdeploy tool is run.
Problem The translated messages are not available when the wsdeploy tool is run.
Recommended response Consult the articles for the wsdeploy tool in the information center for the usage and message information. The information in the information center is translated.

A Web Services Description Language file containing a Java Message Service endpoint URL fails the validation in the Web Services Description Language validator inside WebSphere Studio Application Developer

Symptom A Web Services Description Language (WSDL) file containing a Java Message Service (JMS) endpoint URL fails the validation in the WSDL validator inside WebSphere Studio Application Developer.
Problem If the JMS endpoint URL contains vertical bar ("|") characters as the property delimiters within the URL string, the WSDL validator treats the WebSphere Studio Application Developer document as invalid. The following example illustrates such a URL string:
jms:/queue?destination=jms/Q1|connectionFactory=jms/QCF1|targetService=Method1

The error occurs because the WSDL validator does not treat the "|" character as a valid delimiter within the URL string.

Recommended response To avoid this error, use the ampersand ("&") character as the property delimiter within the JMS URL string. For example:
jms:/queue?destination=jms/Q1&connectionFactory=jms/QCF1&targetService=Method1

The following list describes the ways in which the JMS endpoint URL string is entered into the WSDL document :

  • The Java2WSDL command-line tool (through the location option) inserts the specified endpoint URL string into the resulting WSDL file. When using this method, you must specify a JMS URL that contains "&" characters for the delimiters.
  • You can use the publish WSDL application to publish a WSDL file for your use. When using this application, you must use the "&" character as a delimiter when specifying the JMS URL prefix.
  • You can modify the WSDL document manually. If you modify the WSDL file manually, you must use the ampersand entity reference ("&amp;") within the WSDL file. For example, the previous URL string is similar to the following example inside the WSDL file:
    jms:/queue?destination=jms/Q1&amp;connectionFactory=jms/QCF1&amp;targetService=Method1

Migrating applications developed with the WebSphere Application Server, Version 5 Web services technology preview to WebSphere Application Server Version 5.0.2

Problem When migrating applications developed with the WebSphere Application Server, Version 5, Web services technology preview to WebSphere Application Server, Version 5.0.2, you must take the following steps or your applications will not execute properly.
Recommended response This section describes how to migrate from the Web services technology preview to WebSphere Application Server, Version 5.0.2.

You can normally reuse the Web Services Description Language (WSDL) file. If you created the WSDL file using the Java2WSDL command in the Web services technology preview and you encounter problems, regenerate the file. You must regenerate all Java classes generated by the WSDL2Java command in the technology preview. These classes fall into two categories, the development classes and the deployment classes. The development classes include the enterprise beans and exception classes generated by the WSDL2Java command. These classes are regenerated by running the wsdl2java -role develop-client (or -role develop-server) command. The deployment classes include *Stub.java, *Locator.java, *_Ser.java, *_Deser.java, and *_Helper.java classes. After you verify that no deployment class source code is included in the application EAR file, you can regenerate the deployment classes either by using the wsdeploy command, or by selecting Deploy Web Services on the application installation panels of the administrative console. Classes generated by the WSDL2Java command are identified by a comment at the top of the source file. You can reuse the original Web service client code and server implementation code. If you have any JAX-RPC handlers, rewrite the code to conform with SAAJ 1.1 (see http://java.sun.com/xml/saaj/ ). You can reuse the original webservices.xml and webservicesclient.xml deployment descriptors. Any information added to the original ibm-webservices-bnd.xml and ibm-webservicesclient-bnd.xml files need to be migrated to the new ibm-webservices-bnd.xmi and ibm-webservicesclient-bnd.xmi files.

In the Web services technology preview, all application exceptions extended IBM WebServicesFault. Now all application exceptions extend java.lang.Exception to comply with the J2EE specification.

A WebServicesFault exception is thrown by the application server run time for certain Web Services Description Language files

Symptom A WebServicesFault exception is thrown by the application server run time for certain Web Services Description Language (WSDL) files that define operations with the document style and literal use and use the Simple Object Access Protocol (SOAP) header to transmit the input data.
Problem If the WSDL files define an operation with document style and literal use and this operation maps the input to the SOAP header, the Web services run time fails to find the right operation for the target service, and a WebServicesFault exception is thrown.
Recommended response To solve the problem, you must change the WSDL files so that the previously noted operation does not have any input that uses the SOAP header to transmit the data.

Web services clients using the Java Development Kit 1.4.1 on some operating systems fail to initialize

Problem A WebSphere Application Server Web services client, which uses the Java Development Kit (JDK)1.4.1 fails to initialize on some operating systems. The same client using JDK 1.3.1 does not experience this problem. Currently, this problem has only occurred on Solaris Operating Environment 9 and SuSE Linux systems. On these systems, the client receives an exception similar to the following:
WSCL0100E: Exception received: java.lang.ExceptionInInitializerError
        at java.lang.Class.forName1(Native Method)
        at java.lang.Class.forName(Class.java:173)
        at com.ibm.ws.webservices.engine.encoding.DefaultTypeMappingImpl.class$(DefaultTypeMappingImpl.java:128)
        at com.ibm.ws.webservices.engine.encoding.DefaultTypeMappingImpl.<init>(DefaultTypeMappingImpl.java:311)
        at com.ibm.ws.webservices.engine.encoding.DefaultTypeMappingImpl.getSingleton(DefaultTypeMappingImpl.java:138)
        at com.ibm.ws.webservices.engine.description.PortDesc.<init>(PortDesc.java:186)
        at com.ibm.ws.webservices.engine.deployment.wsdd.WSDDPort.<init>(WSDDPort.java:147)
        at com.ibm.ws.webservices.client.ClientXMLProcessor.addServiceRef(ClientXMLProcessor.java:523)
        at com.ibm.ws.webservices.client.ClientXMLProcessor.processFileContents(ClientXMLProcessor.java:297)
        at com.ibm.ws.webservices.client.ClientXMLProcessor.loadWebServicesClientXML(ClientXMLProcessor.java:334)
        at com.ibm.ws.webservices.component.WSClientImpl.start(WSClientImpl.java:131)
        at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:543)
        at com.ibm.ws.client.applicationclient.ClientComponentInitImpl.start(ClientComponentInitImpl.java:73)
        at com.ibm.ws.client.applicationclient.ClientContainer.initializeComponents(ClientContainer.java:579)
        at com.ibm.ws.client.applicationclient.ClientContainer.init(ClientContainer.java:174)
        at com.ibm.websphere.client.applicationclient.launchClient.createContainerAndLaunchApp(launchClient.java:590)
        at com.ibm.websphere.client.applicationclient.launchClient.main(launchClient.java:420)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
        at java.lang.reflect.Method.invoke(Method.java:371)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
Caused by: java.lang.IllegalArgumentException: Unterminated quote
        at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:712)
        at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:511)
        at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:460)
        at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:441)
        at      
        at com.ibm.ws.webservices.engine.types.Time.<clinit>(Time.java:89).null(Unknown Source)

In addition to the com.ibm.ws.webservices.engine.types.Time class, this error can also occur in the com.ibm.ws.webservices.engine.encoding.ser.CalendarDeserializer class.

Recommended response Apply interim fix PQ75766 to solve this problem.

The regenerated Java stubs might fail to recompile when a Web service or Web service client is created using the WSDL2Java tool

Symptom When a Web service or Web service client is created using the WSDL2Java tool in WebSphere Application Server, Version 5.0.2 to Version 5.0.2.5 or Version 5.1 to Version 5.1.0.3 and then the same application Java stubs are regenerated in Version 5.0.2.6 and higher or Version 5.1.0.4 and higher, the regenerated Java stubs might fail to recompile.
Problem The interim fix PQ87511 for this problem changes the case of some file names to adhere to specifications, but older applications might be coded to use the file names generated in the older versions of the WSDL2Java tool.
Recommended response If the regenerated Java stubs fail to recompile, the Java compilation errors might indicate where in the customer code the file names need to be modified to meet the case of the file names generated by the new WSDL2Java tool

Web services gateway

Configuring Web service security in the Web services gateway

If you change an existing security configuration for a Web service in the gateway, for the changes to take effect you must restart the application server on which the gateway is running (for more information see the information center topic, "Enabling Web Services Security (WS-Security) for the gateway").

Configuring ID Assertion in the Web services gateway

When you edit the service security configuration for a Web service in the gateway , you cannot select ID Assertion. You can navigate to the section Accepted identification methods, and select the ID Assertion check box, but when you click Apply Changes this change is not applied. For more information see the product documentation article, "Enabling Web Services Security (WS-Security) for the gateway."

Web services gateway requires interim fix PQ75913

If you use the Web services gateway, you must apply interim fix PQ75913 that is available from the following Web site:

http://www.ibm.com/software/webservers/appserv/was/support/.

From the main page, click All code fixes and support tools in the Software downloads section. This takes you to the page to search for a specific download package.

Web services gateway backup and restore limitations

Problem In this release of the Web services gateway, the following manual interventions are required when backing up and restoring a gateway. (For more information see the product documentation article, "Backing up and restoring a gateway configuration.")
Recommended response
  • Channels

    The local end point address is not backed up. Before you restore your saved XML configuration file, open it in an XML or ASCII text editor then find the <channels> tag. For each <Channel> under the <Channels> tag, find the <LocalEndPointAddress type="text"> tag and replace the null value inside this tag with the URL value inside the <ExternalEndPointAddress type="text"> tag.

  • Services

    If your saved configuration includes a service that is deployed to two channels, then the gateway stops during the restore. In this case, stop then restart the application server. The service is then restored but without a target service defined. Redefine the target service manually.

  • Security

    Restoring encryption information causes an error page to be displayed when you try to select the Security page in the browser of gateway. Remove encryption information (see the product documentation article "Configuring the gateway security bindings") before you back up the gateway, then re-enter this information manually after you restore the gateway.

  • Proxy authentication

    If you back up a gateway configuration in which the two check boxes Enable proxy authentication and Use Gateway proxy credentials for invoking WebServices are both enabled (see the product documentation article "Enabling proxy authentication for the gateway"), then after you restore the gateway both these check boxes are cleared. Re-enable them manually.

Preserving an existing Web services gateway configuration when installing the fix pack

The update installer installs the enterprise applications for the Web services gateway in the /installableApps directory of WebSphere Application Server Network Deployment. You then deploy the gateway enterprise applications across the cell as a separate step.

To install Fix Pack 2, complete the following steps:

Note:

  1. Install Fix Pack 2 by following the instructions in the product documentation article, "Installing fixes and fix packs."
  2. If your Version 5 or 5.0.1 gateway is running in a cell, remove the application server from the cell. This is because the gateway enterprise application needs to be updated with a J2EE client application, and this cannot be done when the application is running in a cell.
  3. Locate the wsgwsave.jar file in the WebSphere_DeployMgr_root/WSGW/install directory (where WebSphere_DeployMgr_root is the deployment manager root directory - by default WebSphere/DeploymentManager). Copy this file to a convenient directory on the machine on which the target application server is running.
  4. On the machine on which the target application server is running, use the WebSphere Application Server Application Assembly Tool (AAT) to import the wsgwsave.jar utility into the gateway application (for more information on using the AAT, see the product documentation article, "Assembling applications"). To import the wsgwsave.jar utility into the gateway application, complete the following steps:
    1. Start the AAT.
    2. From the File menu, click File > Open, then browse to the install_root/installedApps/node_name directory (where install_root is the root directory of your target application server (by default WebSphere/AppServer) and node_name is the application server node name).
    3. Select the wsgw.ear file, then open the application.
    4. From the pop-up menu for the Application Client folder, click import.
    5. Browse to the location of the wsgwsave.jar file. Select this file and click Open. When asked to confirm values, click OK.
    6. Select File > Save to update the application.
  5. On the machine on which the target application server is running, use the WebSphere Application Server launchClient tool to launch the utility wsgwsave.jar and back up the configuration data from the gateway (for more information on using the launchClient tool, see the product documentation article, "Running application clients"). To back up the configuration data from the gateway, complete the following steps:
    1. From a command line, change the directory to install_root/bin.
    2. Type the following command:

      launchClient install_root/installedApps/node_name/wsgw.ear -CCjar=wsgwsave.jar location_to_write_file_to

      where location_to_write_file_to is the full path and file name under which you want the configuration file to be saved (the file name can be any valid Java filename). For example (Windows systems): launchClient C:\WebSphere\ApplicationServer\installedApps\myNode\wsgw.ear -CCjar=wsgwsave.jar C:\gatewayconfig.xml.

  6. If necessary, add the target application server back into the cell.
  7. Complete the installation of the Version 5.0.2 gateway by following the instructions in the product documentation article, "Web services gateway - Completing the installation." This undeploys the existing applications and deploys the Version 5.0.2 gateway enterprise applications.
  8. To restore the data from your back up file, follow the restore steps in the product documentation article, "Backing up and restoring a gateway configuration."

Running Web services that use Generic classes and Web services that use Deployed Java classes on the same instance of the Web services gateway

Problem Web services that use Generic classes and Web services that use Deployed Java classes cannot be run on the same instance of the Web service gateway, unless a further interim fix is applied.
Explanation Without this fix, when a service is deployed using Generic classes, the typemappings that are required by the gateway for Generic classes overwrite the default typemappings for any service that uses Deployed Java classes; then all subsequent invocations of the services that use Deployed Java classes fail.
Recommended response The interim fix package that solves this problem is PQ75913. It is available from the following Web site: http://www.ibm.com/software/webservers/appserv/was/support/. From the main page, click All code fixes and support tools in the Software downloads section. This takes you to the page to search for a specific download package.

Configuring the Web services gateway channels for successful back up and restore of the gateway

In the gateway, an extended channel end point address is required if the gateway on which the channel is running is part of a distributed gateway deployment (for more information see the product documentation article, "Deploying channels to the Web services gateway"). If you want to use the gateway back up and restore features to create a distributed gateway deployment (for more information see the information center topic, "Backing up and restoring a gateway configuration"), then you must configure all the channels with extended end point addresses before you back up the gateway.

A NullPointerException exception occurs in the WSIFOperation_JCA class

Problem A WSIFMessage can be constructed with no parts in order to send a message with no body. If this WSIFMessage is sent through the Web Services Invocation Framework (WSIF) J2EE Connector Architecture (JCA) provider, a NullPointerException exception can occur in the WSIFOperation_JCA class.
Recommended response To resolve this problem, apply interim fix PQ75913 that is available from the following Web site:

http://www.ibm.com/software/webservers/appserv/was/support/.

From the main page, click All code fixes and support tools in the Software downloads section. This takes you to the page to search for a specific download package.

Installing or upgrading the Web services gateway

Problem When you install WebSphere Application Server, or an upgrade or fix pack, the installation program does not install the Web services gateway enterprise applications. When you run the installation program, and select the Web services gateway component, then the files that are required for running the gateway are copied into directories within your application server directory structure.
Recommended response To install the latest version of the gateway into your application server, complete the steps described in Completing the installation.

Session management of deployed target services in the Web services gateway

Problem The Web services gateway does not support session management and maintenance of deployed target services using HTTP cookies.
Recommended response Use Simple Object Access Protocol (SOAP) headers to support session management and maintenance of deployed target services.

Web Services Invocation Framework

Web services security

Editing the HTTP basic authentication and Secure Sockets Layer configuration for the Web or EJB modules

For security to work properly with Web services, you must take the following actions.

Problem You must edit the HTTP basic authentication (user ID and password) and Secure Sockets Layer (SSL) configuration for the HTTP outbound request in the client security bindings of the Web services using the administrative console after you deploy the Web services application.
Recommended response You can edit the HTTP basic authentication and SSL configuration for the Web services from the administrative console by performing the following steps:
  1. Click Enterprise Applications > application_name.
  2. Under Related Items, click Web Module or EJB Module > URI_file_name > Web Services: Client Security Bindings.
  3. Look for HTTP Basic Authentication and HTTP SSL Configuration to the right.
  4. To configure the HTTP basic authentication, click edit and enter the user ID and password.
  5. Click OK.
  6. To configure the HTTP SSL configuration, click edit.
  7. Select HTTP SSL Enabled.
  8. Select an SSL alias for the HTTP SSL configuration.
  9. Click OK.

The Web services technology preview is not supported on WebSphere Application Server, Version 5.0.1 or later

The Web services technology preview is not supported on WebSphere Application Server, Version 5.0.1 or later. WebSphere Application Server, Version 5.0.2 includes Web services support that supersede the Web services technology preview.

Assembly tools release notes

All platforms

UNIX

Help files are viewable only from a locally installed browser

Problem If you access any of the IBM WebSphere Application Server tools from a remote machine, for example, the Assembly Toolkit, the remote browser cannot display the help files. You can only view the help files from a locally installed browser.
Recommended response To work around this problem, close all the Netscape sessions on the remote machine and click Help. A new Netscape session starts and you can then view the Help files.

Assembly Toolkit displays unsupported type for application client resource reference

When configuring a resource reference for an application client module in the Assembly Toolkit, the Type field lists javax.resource.cci.ConnectionFactory as an available resource reference. This type is not supported by the J2EE application client run time. The supported types are:

Running the Assembly Toolkit on UNIX platforms causes errors

Unix
Problem When you run the Assembly Toolkit on UNIX platforms, a sample of errors that display follows:
...Font specified in font.properties not found [-urw-itc 
zapfdingbats-medium-r-normal--*-%d-*-*-p-*-sun-fontspecific]
Font specified in font.properties not found [-urw-itc 
zapfdingbats-medium-r-normal--*-%d-*-*-p-*-sun-fontspecific]
...
Recommended response The Assembly Toolkit or installer functions are not affected by these errors. These messages display in the command shell that spawned the Java GUI. You can disregard these messages.

Messaging and Extended messaging release notes

All platforms

Linux

HPUX

UNIX

Solaris

Windows

Embedded Java Message Service provider installation fails

Problem It is possible for the embedded Java Message Service (JMS) provider installation to fail without any visible warning. This situation can occur as a result of the JMS provider prerequisite checker returning an error that the IBM WebSphere Application Server installation is not expecting. The IBM WebSphere Application Server installation completes, but the JMS provider is not installed.
Recommended response If the JMS installation fails, look for details in the mq_prereq.log file in the /tmp directory and in the create_mq.log and mq_install.log files in the install_root/log directory. When you have corrected the situation, install the embedded JMS provider separately by clicking Custom installation then selecting either one or both of the following options, as required: Embedded Messaging Server and Embedded Messaging Client. For more information about installing the embedded JMS provider, see the information center topic, "Installing WebSphere embedded messaging as the JMS provider."

In the single server environment, the embedded Java Message Service server and IBM WebSphere Application Server run on the same single Java virtual machine

Problem In the single server environment, the embedded Java Message Service (JMS) server and IBM WebSphere Application Server run on the same single Java virtual machine. Due to this architecture, if the MQ process (such as amq*.exe - not JMS process but MQ native process) dies and restarts while the JMS server is running, you must restart IBM WebSphere Application Server (ordinarily named server1) manually. This shutdown also can affect other installed applications.
Recommended response Restart the application server (server1).

Note: In the distributed server environment, the JMS server and the application server run in separate processes. Therefore, the JMS server is not required to restart the application server.

Selecting the Java Message Service resources when deploying the WAR file

When you deploy a WAR file and select the Java Message Service (JMS) resources that you defined, you receive a warning message without selecting the JMS resources.

Information you need to know about using server-side and client-side selectors

The default behavior for the internal Java Message Service (JMS) broker is to use server-side selectors. The default behavior for external brokers is to use client-side selectors. The reason for the latter is that not all brokers support server-side filtering. Those that do, are not all JMS compliant in their implementation process.

Component-managed authentication alias not specified

Problem When using Java Message Service (JMS), informational messages similar to the following can occur:
[10/31/02 9:13:20:438 EST] 6a55451c ConnectionFac I J2CA0107I: Component-managed authentication
Recommended response If the named connection factory ends in JMSManagedConnection@nnnn, where nnnn is a multi-digit number, the informational message can be ignored. A connection factory with this type of name is created internally by the JMS server and does not require a component-managed authentication alias.

Stopping the queue manager while running the embedded Java Message Service provider stops IBM WebSphere Application Server

Problem When you run the embedded Java Message Service (JMS) provider and the queue manager stops, IBM WebSphere Application Server is also stopped.
Recommended response To recover the queue manager and IBM WebSphere Application Server, you must start the application server.

Recommended approach to installing WebSphere Application Server on top of WebSphere MQ

When planning to install a WebSphere Application Server, Version 5.1 release on a machine that already has a copy of WebSphere MQ V5.3 installed on it, you are recommended to complete the following steps:

  1. Ensure that all the WebSphere MQ features required by the WebSphere Application Server embedded messaging are installed:
     - on UNIX:
       - for WebSphere Application Server Network Deployment or Client: 
    	Java Messaging
      - for WebSphere Application Server (base): Runtime, Base (or SDK), 
    	Server, Client, Java Messaging and All Message Catalogs 
      - on Windows:
      - for WebSphere Application Server ND or Client: Java Messaging 
      - for WebSphere Application Server (base): Server and Java Messaging
  2. Ensure that WebSphere MQ V5.3 is upgraded to CSD04 which is the appropriate prerequisite CSD level:
    - CSD1 for WebSphere Application Server v5.0
    - CSD3 for WebSphere Application Server v5.0.1
    - CSD4 for WebSphere Application Server v5.0.2 and v5.1.0
  3. Install the WebSphere Application Server V5.1 GM release

After the initial installation of WebSphere MQ and WebSphere Application Server, you should service WebSphere MQ independently of the WebSphere Application Server fix packs. This approach helps to avoid failures in uninstalling WebSphere Application Server fix packs.

Uninstalling fix pack fails when External MQ already installed

Solaris

Problem Consider the scenario on Solaris Operating Systems, where you have installed WebSphere MQ with the CSDs needed for WebSphere Application Server, then install WebSphere Application Server, and one WebSphere Application Server fix pack (for example, WAS 5.0.1 or WAS 5.0.2). If you try to uninstall the fix pack release to return to the GA level of WebSphere Application Server, the uninstall process fails and the following messages are displayed in the /opt/WebSphere/AppServer/logs/update/..._was50_fpn_solaris_uninstall.log:
PTF Results: ========================================================= 
Time Stamp (End)      
: dateTtime PTF Result            : failed PTF Result Message: 
========================================================= 
WUPD0243E: 
Fix pack uninstall failure: 
The update for component was50_fpn_solaris for fix pack external.mq 
could not be uninstalled. 
========================================================= 

In addition, the following messages are displayed in the date_time_was50_fpn_solaris_external.mq_uninstall.log:

wmservice: date time =======================================
wmservice: date time Date: Tue Jul 1 16:18:10 BST 2003 wmservice: 
date time 
==================================================================
 
wmservice: date time Hostname: slipstream wmservice: date time Operating System: 
SunOS wmservice: date time User: uid=0
(root) gid=1(other) wmservice: date time Command line is: 
/opt/WebSphere/AppServer/properties/version/backup/external.mq/pt
fs/was50_fpn_solaris/components/external.mq/CSD/wmservice uninstall 
/opt/WebSphere/AppServer/logs/update/date_time_was50_fp
2_solaris_external.mq_uninstall.log wmservice: date time Function is 
uninstall wmservice: date time Get_ver_rel mqm.java wm
service: date time Checking for installed product "mqm", 
class "java" wmservice: date time Check for csd levels expr: syntax
 error wmservice: date time ... mqm.java 5.3.0.2.4 wmservice: 
date time Uninstall_service .... pkgrm: ERROR: no package ass
ociated with &lt;mqm_upd02> wmservice: date time return code 1 from 
pkgrm wmservice: 
date time ... Uninstall_servi
ce returns 1 wmservice: date time Return code 1 from Uninstall_wsm wmservice: 
date time Exiting - return code 1 wmservice: 
date time ============================================================
The last step of the WebSphere Application Server fix pack uninstallation fails because the external.mq component cannot be uninstalled.
Recommended response To fix this problem, delete the mqVer.properties file in the /opt/WebSphere/AppServer/properties/version/backup/external.mq/ptfs/was50_fpn_solaris/components/external.mq/directory, where was50_fpn_solaris indicates the fix pack release (for example, was50_fp2_solaris for Fix Pack 2). Then retry the uninstall of the fix pack release (for example, Fix Pack 1 or Fix Pack 1).

Log in appropriately on Linux platforms to pick up secondary user groups for root on all platforms: Intel, S/390 and PPC

Linux

Problem When you install WebSphere Application Server on SLES 8 or United Linux V1.0 platforms running on Intel-based, PPC, or S/390 machines, the following entries are displayed in the SystemOut.log file:
[date time CDT] 60cf2faf JMSRegistrati A MSGS0601I: WebSphere Embedded Messaging 
has not been installed
[date time CDT] 60cf2faf JMSEmbeddedPr A MSGS0050I: Starting the Queue Manager
[date time CDT] 60cf2faf JMSEmbeddedPr E MSGS0058E: Unable to start the JMS 
Server as WebSphere Embedded Messaging has not been installed
[date time CDT] 60cf2faf JMSService    E MSGS0001E: Starting the JMS Server 
failed with exception: java.lang.Exception: MSGS0058E: Unable to start the 
JMS Server as WebSphere Embedded Messaging has not been installed
Also, the following associated messages are added to the mq_install.log file:
wmsetup: date time Checking if user "root" is in group "mqm"
wmsetup: date time
wmsetup: date time ERROR: Group "mqm" exists, id "root" is defined to 
the group but does not
wmsetup: date time have the group in its current set of effective groups.
wmsetup: date time Current group membership is :
wmsetup: date time uid=0(root) gid=0(system) groups=2(bin)
wmsetup: date time You may need to login.
wmsetup: date time
wmsetup: date time ... RC 4 from Check_root
wmsetup: date time ERROR: User "root" not in group "mqm" 
wmsetup: date time Check_root mqbrkrs
wmsetup: date time Checking for group "mqbrkrs" ...
wmsetup: date time lsgroup returned "mqbrkrs id=203 admin=false users=root 
adms=root registry=files " RC=0
wmsetup: date time Checking if user "root" is in group "mqbrkrs"
wmsetup: date time
wmsetup: date time ERROR: Group "mqbrkrs" exists, id "root" is defined to 
the group but does not
wmsetup: date time have the group in its current set of effective groups.
wmsetup: date time Current group membership is :
wmsetup: date time uid=0(root) gid=0(system) groups=2(bin)
wmsetup: date time You may need to login.
wmsetup: date time
wmsetup: date time ... RC 4 from Check_root
wmsetup: date time ERROR: User "root" not in group "mqbrkrs"
Recommended response To prevent this problem, use ssh instead of telnet to log in.

As a workaround, after logging in and experiencing this problem, run the following command:

su -

Ensure that the required utilities and compatibility libraries are installed before installing WebSphere Application Server on RedHat V8 platforms running on Intel-based machines

Linux

Problem On RedHat V8 platforms running on Intel-based machines, during the Application Server startup process, the following entries are displayed in the SystemOut.log file:
[date time EST] 1cda953b JMSEmbeddedPr A MSGS0052I: Starting the Broker
[date time EST] 1cda953b BrokerManager E MSGS0255E: Broker Manager unable to 
attach to Queue Manager - unknown Queue
[date time EST] 1cda953b JMSService    E MSGS0001E: Starting the JMS Server 
failed with exception: com.ibm.mq.MQException: MQJE001: Completion Code 2, 
Reason 2085
The following associated messages are added to the mq_install.log file:
which: no uudecode in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
  The program uudecode was not found on this system.  This will not prevent
  the installation, however you should run the command "amqiclen -x"
  after the installation has completed, before queue managers are started.
Also, the createMQ log shows the following information:
Issuing: env wempsdeletebroker WAS_redhat801_jmsserver -w
wempsdeletebroker: error while loading shared libraries: 
libstdc++-libc6.2-2.so.3: cannot open shared object file: No such 
file or directoryrc=127
Issuing: env wempscreatebroker WAS_redhat801_jmsserver -i dummy -a 
dummy -q 
WAS_redhat801_jmsserver -n "" -u "" -p "" -b -j
wempscreatebroker: error while loading shared libraries: 
libstdc++-libc6.2-2.so.3: cannot open shared object file: 
No such file or directoryrc=127
Issuing: env wempsservice WAS_redhat801_jmsserver -r 
BrokerUUID=FFFFFFFF-0000-0000-0000-000000000000
wempsservice: error while loading shared libraries: 
libstdc++-libc6.2-2.so.3: cannot open shared object file: 
No such file or directoryrc=127
Recommended response To prevent this problem, ensure that the required utility package (which includes uuencode and uudecode) and the libstdc++ compatibility libraries are installed; for example, RH8.0/RPMS/shareutils. (The RPMS are on the Linux distribution CDs.) The exact name and version number of the package depends on the Linux distribution:

Dependency RedHat package name SuSE package name
uudecode sharutils sharutils
libstdc++ compatibility libraries compat-libstdc++ compat (needs to be version 2002.12.6.0 or later)


On Linux platforms, embedded messaging broker does not shut down due to libstdc++ problem

Linux

Symptom On SuSE SLES8 and United Linux V1.0, when shutting down WebSphere Application Server, the last entry in the SystemOut.log file is:
[date time CDT] 1a87ba29 JMSEmbeddedPr A MSGS0054I: Stopping the Broke
Also, a Java core file :javacore29282.1054144121.txtgets that is created at approximately the same time [date at timeTIFILENAME] as the embedded messaging broker tries to shut down.
Problem On SuSE SLES8 or United Linux V1.0, when shutting down WebSphere Application Server, the embedded messaging broker does not shutdown properly, because of a libstdc++ problem.
Recommended response You should upgrade the operating system to the latest Service Pack, which includes the fix for the libstdc++ problem.

On Linux/Intel (RedHat V8) platforms, installation of WebSphere Application Server stops during the embedded messaging installation stage

Linux

Symptom On Linux (RedHat v8), the installation of WebSphere Application Server stops during the embedded messaging installation stage. The last line of the mq_install.log is:
wmsetup: date time Installing MQSeriesClient-5.3.0-1.i386.rpm 
MQSeriesMsg_Zh_CN-5.3.0-1.i386.rpm 
 MQSeriesMsg_Zh_TW-5.3.0-1.i386.rpm
MQSeriesMsg_de-5.3.0-1.i386.rpm 
MQSeriesMsg_es-5.3.0-1.i386.rpm 
MQSeriesMsg_fr-5.3.0-1.i386.rpm
MQSeriesMsg_it-5.3.0-1.i386.rpm 
MQSeriesMsg_ja-5.3.0-1.i386.rpm 
MQSeriesMsg_ko-5.3.0-1.i386.rpm 
MQSeriesMsg_pt-5.3.0-1.i386.rpm 
MQSeriesRuntime-5.3.0-1.i386.rpm 
MQSeriesSDK-5.3.0-1.i386.rpm 
MQSeriesJava-5.3.0-1.i386.rpm 
MQSeriesServer-5.3.0-1.i386.rpm:
The last line of the master installation log (/tmp/log.txt) is:
(date time), Setup.product.install, com.ibm.wizard.
platform.linux.LinuxProductServiceImpl, msg1,installing 
Exec Action From Directory (mqUnixInstallAction)
Problem RPM lock files exist that prevent the product installation from continuing.
Recommended response For information about solving this problem, see the bugzilla report at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74726

Installing WebSphere Application Server, Version 5.0.2 Network Deployment on top of WebSphere Application Server, Version 5.0.1 Network Deployment fails on Linux/Intel

Problem The installation of WebSphere Application Server Network Deployment, Version 5.0.2 on top of WebSphere Application Server Network Deployment, Version 5.0.1 fails on the Linux/Intel platform. The following message displays in the
/opt/WebSphere/DeploymentManager/logs/update/20030703_152306_was50_nd_
fp2_linux_selective-install.log
file.
PTF Results:
=========================================================
Time Stamp (End)      : 2003-07-03T15:23:09Z
PTF Result            : failed
PTF Result Message:
=========================================================
WUPD0218E: Fix pack installation failure: The component 
external.mq failed to install.
The associated errors in the
/opt/WebSphere/DeploymentManager/logs/update/20030703_152306
_was50_nd_fp2_linux_external.mq_install.log
file are:
wmservice: 03Jul03 15:23:08 Installing 
MQSeriesServer-U486878-5.3.0-4.i386.rpm 
MQSeriesJava-U486878-5.3.0-4.i386.rpm 
MQSeriesSDK-U486878-5.3.0-4.i386.rpm 
MQSeriesRuntime-U486878-5.3.0-4.i386.rpm 
MQSeriesClient-U486878-5.3.0-4.i386.rpm
error: failed dependencies:
MQSeriesServer = 5.3.0 is needed by 
MQSeriesServer-U486878-5.3.0-4
MQSeriesSDK = 5.3.0 is needed by 
MQSeriesSDK-U486878-5.3.0-4
MQSeriesRuntime = 5.3.0 is needed by 
MQSeriesRuntime-U486878-5.3.0-4
MQSeriesClient = 5.3.0 is needed by 
MQSeriesClient-U486878-5.3.0-4
wmservice: 03Jul03 15:23:08 ERROR: Return code 5 from rpm -i 
MQSeriesClient-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_Zh_CN-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_Zh_TW-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_de-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_es-U*-5.3.0.4.i386.rpm 
MQSeriesMsg_fr-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_it-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_ja-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_ko-U*-5.3.0-4.i386.rpm 
MQSeriesMsg_pt-U*-5.3.0-4.i386.rpm 
MQSeriesRuntime-U*-5.3.0-4.i386.rpm 
MQSeriesSDK-U*-5.3.0-4.i386.rpm 
MQSeriesJava-U*-5.3.0-4.i386.rpm 
MQSeriesServer-U*-5.3.0-4.i386.rpm
wmservice: 03Jul03 15:23:08 ERROR: installation 
of mqm CSD failed - rolling back
wmservice: 03Jul03 15:23:08 Rollback entered - error code 19
Recommended response If you require the Embedded Messaging component, uninstall WebSphere Application Server Network Deployment, Version 5.0.1 before installing WebSphere Application Server Network Deployment , Version 5.0.2 on Linux/Intel.

You can ignore some error messages when installing WebSphere Application Server with embedded messaging from the CD-ROM

HPUX

Problem On HP-UX, when installing WebSphere Application Server with embedded messaging from the CD-ROM, the following warning message is issued despite successful installation:
MQSERIES.MQM-CL-HPUX: A test command parameter is not valid." and "* 
"svthp9:/cdrom/hpux/messaging/images":  Cannot open the
logfile on this target or source.  Possibly the media is
read-only or there is a permission problem." on mq_install.log.  
Recommended response You can ignore this warning message, because the problem does not affect the successful installation of WebSphere Application Server with embedded messaging.

Installing WebSphere Application Server Network Deployment before WebSphere Application Server (base) creates an exception in SystemOut.log

HPUX

Problem On HP-UX platforms, if you install WebSphere Application Server Network Deployment first, then later install WebSphere Application Server (base), the following exception is written to the SystemOut log file when you attempt to start WebSphere Application Server:
[date time CDT]   25491d JMSService    E MSGS0001E: 
Starting the JMSServer failed with exception: 
java.lang.Exception: MSGS0101E: Start Queue Manager 
command failed with exit code: 71
In this specific scenario, the/var/mqm/mqs.ini directory needed to start the queue manager is missing.

Note: Generally, you should install WebSphere Application Server (base) before installing WebSphere Application Server Network Deployment on the same host.

Recommended response As a workaround, after completing the installation, and before starting the WebSphere Application server, run the following command:

ln -s /opt/mqm/lib/nls/C/amq.cat /usr/lib/nls/C/amq.cat

Now, copy the mqs.ini file from the /opt/mqm/samp directory to the /var/mqm directory

Finally, rerun the createMQ script:

./wasHome/bin createmq.sh <wasHome><cellName><nodeName><serverName>

where <wasHome> is the installation directory (that defaults to /opt/WebSphere/AppServer).

If you are not sure about your cellName, nodeName, and serverName, check the first line in the createMQ logfile that can be located in the wasHome/logs directory. The first line identifies the wasHome, cellName, nodeName, and serverName parameters passed to the script.

Uninstalling WebSphere Application Server Network Deployment does not remove the WebSphere MQ Java Client

UNIX

Problem On UNIX platforms, when uninstalling WebSphere Application Server Network Deployment, the following messages are displayed in the mq_uninstall.log file:
wmsetup: date time =====================================
wmsetup: date time Date: Tue Jun 24 12:17:58 PDT 2003
wmsetup: date time =====================================
wmsetup: date time Hostname: alinppc04
wmsetup: date time Operating System: Linux
wmsetup: date time User: uid=0(root) gid=0(root) 
groups=0(root),64(pkcs11),500(mqm),
501(mqbrkrs)
wmsetup: date time Command line is: /opt/WebSphere/DeploymentManager
/_uninst/mq/wmsetup 
uninstall /opt/WebSphere/DeploymentManager/mq_uninstall.log
wmsetup: date time Function is uninstall
wmsetup: date time Uninstall_wsm
wmsetup: date time Checking for installed wemps-runtime ...
wmsetup: date time package wemps-runtime is not installed
wmsetup: date time WebSphere Embedded Messaging not installed - 
no action required
wmsetup: date time Checking for installed MQSeriesRuntime ...
wmsetup: date time package MQSeriesRuntime is not installed
wmsetup: date time Return code 0 from Uninstall_wsm
wmsetup: date time Exiting - return code 0
wmsetup: date time ============================================================
Recommended response To resolve this problem, manually uninstall the embedded messaging components by following the instructions in the WebSphere Application Server information center, under the topic, "Uninstalling WebSphere Application Server.

Uninstalling WebSphere Application Server, without first removing any fix packs, does not remove the embedded messaging components

HPUX UNIX Solaris


Problem After apparently uninstalling WebSphere Application Server successfully, some embedded messaging packages still exist.
Recommended response To fix this problem, manually uninstall the embedded messaging components by following the instructions in the WebSphere Application Server information center under the topic, "Uninstalling WebSphere Application Server."

Uninstalling a WebSphere Application Server fix pack fails because the external.mq component cannot be uninstalled

Solaris

Symptom On Solaris Operating Environment, consider the scenario where you:
  1. Install WebSphere Application Server V5 (base or Network Deployment).
  2. Install the WebSphere Application Server V5.0.1 fix pack release.
  3. Install the WebSphere Application Server V5.0.2 fix pack release.
  4. Uninstall the WebSphere Application Server V5.0.2 fix pack release (to return to the WebSphere Application Server V5.0.1 release).
The last step fails and the following messages are displayed in the /opt/WebSphere/AppServer/logs/update/date_time_was50_fp2_solaris_uninstall.log directory:
Results:
=========================================================
Time Stamp (End)      : dateTtime
PTF Component Result  : failed
PTF Component Result Message:
=========================================================
WUPD0246E: Fix pack update failure: An exception occurred 
while preprocessing the content of fix pack was50_fp2_solaris,
 component external.mq
=========================================================
Also, the following messages are displayed in the date_time_was50_fp2_solaris_external.mq_uninstall.log directory :
wmservice: date time =======================================
wmservice: date time Date: Tue Jul 1 16:18:10 BST 2003
wmservice: date time =======================================
wmservice: date time Hostname: slipstream
wmservice: date time Operating System: SunOS
wmservice: date time User: uid=0(root) gid=1(other)
wmservice: date time Command line is: 
/opt/WebSphere/AppServer/properties/version/backup/external.
mq/ptfs/was50_fp2_solaris/components/external.mq/CSD/wmservice 
uninstall /opt/WebSphere/AppServer/logs/update/date_time_was50_
fp2_solaris_external.mq_uninstall.log
wmservice: date time Function is uninstall
wmservice: date time Get_ver_rel mqm.java
wmservice: date time Checking for installed product "mqm", 
class "java"
wmservice: date time Check for csd levels
expr: syntax error
wmservice: date time ... mqm.java 5.3.0.
wmservice: date time uninstall of CSD not possible, current 
level is 5.3.0.
wmservice: date time Exiting - return code 23
Problem The last step of the WebSphere Application Server fix pack uninstall fails because the external.mq component cannot be uninstalled.
Recommended response To fix this problem, complete the following steps:
  1. Delete the mqVer.properties file in the /opt/WebSphere/AppServer/properties/version/backup/external.mq/ptfs/was50_fp2_solaris/components/external.mq/ directory.
  2. Remove the upgrade that was applied to the external.mq component by running the following command as root:
    pkgrm mqm-upd04 
    
    Reply y[es] to all prompts.

    Note: Do not remove mqm-upd04 if you have installed IBM WebSphere MQ as a separate product.

  3. Retry the uninstallation of Fix Pack 2.

On Windows 2003 Server, WebSphere Embedded Messaging Publish and Subscribe Edition does not uninstall

Windows

Symptom On Windows 2003 Server, after using Add and Remove Programs to uninstall WebSphere Application Server, if you close and then reopen Add and Remove Programs, you still see an entry for WebSphere Embedded Messaging Publish and Subscribe Edition (WEMPS). If you then try use Add and Remove Programs to remove WEMPS, you get a notice for Fatal Error during installation.
Problem On Windows 2003 Server, after using Add and Remove Programs to uninstall WebSphere Application Server, the WEMPS product is sometimes not removed.
Recommended response To prevent this problem, try using Add and Remove Programs to uninstall WEMPS before uninstalling WebSphere Application Server. As a workaround, manually remove the registries of Windows 2003 Server for WEMPS.

To manually remove WEMPS, do the following:

  1. Go to www.microsoft.com .
  2. Click Downloads in the left panel.
  3. Type Windows Installer Cleanup Utility under Keywords (optional) and click Go.
  4. Follow the instructions to install the msicuu.exe program.
  5. Click Start > Run in your desktop.
  6. Select the product IBM WebSphere EMPS and click Remove.
  7. Remove the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphereEmbeddedMessagingPublishAndSubscribe.

  8. Delete the WEMPS directory, by default C:\Program Files\IBM WebSphere EMPS, and all its contents.

For more information about manually uninstalling messaging components, see the information center topic, "Manually uninstalling on Windows platforms."

Data access release notes

Connectivity-general

Limited connection caching available for servlets

Caching of connection handles across servlet methods is limited to Java Database Connectivity (JDBC) and Java Message Service (JMS) resources. Other non-relational resources, such as Customer Information Control System (CICS) or IMS, currently cannot have their connection handles cached in a servlet. This limitation only applies to single-threaded servlets since multithreaded servlets do not allow caching of connection handles.

To work around this problem, you need to get, use, and close the connection handle within each method invocation.

Misleading scope when installing RAR file at the server level

When installing a RAR file, by clicking Resources > Resource Adapters > Install RAR, the scope you define on the Resource Adapters page has no effect on where the RAR file gets installed. You can only install RAR files at the node level. The scope on the Install RAR page determines the node to install. However, the scope you set on the resource adapters panel determines the scope of the new Resource Adapters, which you can install at the server, node, or cell level.

Databases-DB2

No CLOB data is inserted into the database when you use the DB2 UDB V7.2 FP7 client to connect to a DB2 on the z/OS database

Symptom No CLOB data is inserted into the database when using the DB2 UDB V7.2 FP7 client to connect to a DB2 on z/OS database.
Problem This problem happens because of an error in the DB2 UDB Connect code. Instead of inserting the CLOB data into the column, the data inserted is an empty string. The problem is fixed in DB2 UDB V7.2 FP8 or FP9. It is also fixed in DB2 UDB V8.1.
Recommended response Update to the correct version of DB2 UDB FP to resolve this problem.

Upgrading to DB2 V8.1 to avoid a memory leak during the stress run using DB2 V7.2 on Windows 2000 platforms

You can upgrade to DB2 V8.1 to avoid a memory leak during the stress runs when you use DB2 V7.2 on Windows 2000 platforms.

An error is thrown if you use the ws_ant command to perform the database customization for Structured Query Language in Java on HP platforms

Symptom If you use the ws_ant command to perform the database customization for Structured Query Language in Java (SQLJ) on HP platforms, you can receive an error similar to the following:
[java] [ibm][db2][jcc][sqlj] 
[java] [ibm][db2][jcc][sqlj] Begin Customization
[java] [ibm][db2][jcc][sqlj] encoding not supported!!
Problem The cause of this error might be that your databases were created using the HP default character set. The Java Common Client (JCC) driver depends on Software Development Kit to perform the codepage conversions. However, the HP default codepage is not supported by the Software Development Kit shipped with WebSphere Application Server.
Recommended response Set your LANG to the ISO locale before creating the databases. It should be similar to the following:
export LANG=en_US.iso88591 

Refer to the DB2 Tech Notes at http://www-3.ibm.com/software/data/db2/udb/ad/v8/bldg/t0004877.htm for details.

Enabling the batchUpdate feature when running WebSphere Application Server, Version 5.0.2 with the DB2 Legacy CLI-based JDBC driver is ignored by the run time

Problem Enabling the batchUpdate feature when running WebSphere Application Server, Version 5.0.2 with the DB2 Legacy CLI-based JDBC driver is ignored by the WebSphere Application Server run time due to a problem in DB2 which can cause data integrity problems.
Recommended response If you want to use the batchUpdate feature for WebSphere Application Server, Version 5.0.2, run WebSphere Application Server with the DB2 Universal JDBC driver instead of the DB2 Legacy CLI-based JDBC driver.

Known limitations when you connect a DB2 8.1 client to a back level server using a DB2 XA data source

Problem Limitations exist when you connect a DB2 8.1 client to a back level server, for example, DB2 7.2 FP8, using a DB2 XA data source:
  • If there is no fix pack installed on the client, testing the connection for the data source stops the application server with no error log if the connection is tested from the administrative console. If it is tested from the wsadmin tool at the command prompt, you can receive the following exceptions:
      wsadmin>$AdminControl testConnection 
        TradeDataSource(cells/DefaultNOde/nodes/Def
        aultNode:resources.xml#DataSource_1056390840594)
        WASX7015E: Exception running command: "$AdminControl testConnection 
        TradeDataSource(cells/DefaultNOde/nodes/DefaultNode:resources.
        xml#DataSource_1056390840594)"
        ; exception information:
        com.ibm.websphere.management.exception.ConnectorNotAvailableException
        org.apache.soap.SOAPException: [SOAPException: faultCode=SOAP-ENV:Client;     
        msg=Connection reset by peer: socket closed;
        targetException=java.net.SocketsException:
        Connection reset by peer: socket closed]
    
  • If you install Fix Pack 2 on a DB2 8.1 client, the application server does not stop, but returns the following error:
      389b0a5 DataSourceCon E DSRA8040I: Failed to connect to the DataSource. 
        Encountered : java.lang.Exception: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI 
        Driver] SQL30070N "0x1055" Command is not supported. SQLSTATE=58014 
        at com.ibm.ws.rsadapter.DSConfigurationHelper.testConnectionForGUI(
        DSConfigurationHelper.java:1786)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.ibm.ws.management.DataSourceConfigHelperMBean.testConnectionToData
        Source2(DataSourceConfigHelperMBean.java:511)
    
Recommended response Upgrade the DB2 server level to the same level as the DB2 client.

Consult the document located at http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8infocenter.d2w/report?target=mainFrame&fn=r0010969.htm. The document is under the section XA-compliant transaction managers.

The WebSphere Application Server Java virtual machine stops after you run the force application command in the DB2 command line

Symptom The WebSphere Application Server Java virtual machine (JVM) stops when you run the force application command in DB2 UDB Server.
Problem When you use DB2 XA data source in WebSphere Application Server with DB2 UDB Server, the WebSphere Application Server JVM stops after you run the force application command in the DB2 command line.

If you use the DB2 Legacy CLI-based JDBC Driver Provider (XA), you can see the WebSphere Application Server JVM stop as soon as you run the force application command. If you use the DB2 Universal JDBC Driver Provider (XA), you might or might not see the WebSphere Application Server JVM stop right after running the force application command. However, you might see the WebSphere Application Server JVM stop later.

Recommended response DB2 is aware of this problem. You can consult DB2 Support. The APAR number is JR18535.

This problem is fixed in DB2 V8.1 FP4. Upgrade to DB2 V8.1 FP4 to avoid the problem.

Upgrading DB2 V8.1 FP2 or a later version to avoid receiving an exception when the Java 2 security is enabled

Symptom If you enable Java 2 security in WebSphere Application Server and try to use the DB2 Universal JDBC provider to connect to DB2 V8.1 FP1 or an older version, a java.security.AccessControlException exception similar to the following example is displayed from the DB2 Java Combined Client (JCC) driver.
java.security.AccessControlException: access denied 
(java.lang.RuntimePermission accessClassInPackage.sun.io)
       at java.security.AccessControlContext.checkPermission
(AccessControlContext.java(Compiled Code))
       at java.security.AccessController.checkPermission
(AccessController.java(Compiled Code))
       at java.lang.SecurityManager.checkPermission
(SecurityManager.java(Compiled Code))
       at com.ibm.ws.security.core.SecurityManager.checkPermission
(SecurityManager.java(Compiled Code))
       at java.lang.SecurityManager.checkPackageAccess
(SecurityManager.java(Compiled Code))
       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java(Compiled Code))
       at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
       at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
       at com.ibm.db2.jcc.c.o.a(o.java:153)
       at com.ibm.db2.jcc.a.d.a(d.java:1069)
       at com.ibm.db2.jcc.a.be.a(be.java:1549)
       at com.ibm.db2.jcc.a.be.m(be.java:513)
       at com.ibm.db2.jcc.a.be.i(be.java:217)
       at com.ibm.db2.jcc.a.be.c(be.java:54)
       at com.ibm.db2.jcc.a.s.c(s.java:53)
       at com.ibm.db2.jcc.a.bq.h(bq.java:118)
       at com.ibm.db2.jcc.c.cf.i(cf.java:893)
       at com.ibm.db2.jcc.c.cg.a(cg.java:1540)
       at com.ibm.db2.jcc.c.cg.executeQuery(cg.java:312)
Problem This problem is due to the fact that the DB2 JCC driver does not have a doPrivileged call when it tries to load some classes.
Recommended response Upgrade your DB2 server to DB2 V8.1 FP2 or a later version. If you cannot upgrade your DB2 server, grant the permission, java.lang.RuntimePermission "accessClassInPackage.sun.io", to your applications. However, the second solution is NOT recommended.

Cannot run the DB2 legacy call level interface-based Java Database Connectivity driver and the DB2 Universal Java Database Connectivity driver in the same Java virtual machine

Symptom WebSphere Application Server fails if you use the DB2 legacy call level interface (CLI)-based Java Database Connectivity (JDBC) driver and the DB2 Universal JDBC driver in the same WebSphere Application Server Java virtual machine (JVM).
Problem The failure occurs when using DB2 V8.1 FP5 and lower. The failure is because of a DB2 problem with coexistence of the DB2 legacy CLI-based JDBC driver and the DB2 Universal JDBC driver that are used in the same JVM.
Recommended response Upgrade to DB2 V8.1 FP6 and higher.

Using the correct user ID and password to connect to the DB2 Universal Java Database Connectivity driver

Symptom If you do not use a user ID and password, or if you use some combination of an invalid user ID or password to connect to the DB2 Universal Java Database Connectivity (JDBC) driver, you still can get the connection. However, when the connection is used in an XA transaction, an XAException exception is displayed with an XAER_PROTO error code.
Problem The DB2 Universal JDBC driver requires the correct user ID and password to acquire a connection that is unlike the legacy call level interface (CLI)-based JDBC driver.
Recommended response Verify that you use the correct user ID and password to connect to the DB2 Universal JDBC driver. DB2 is aware of the problem.

Using DB2 V8.1 FP3 on the HP-UX platform might cause defunct processes

Symptom When you use DB2 V8.1 FP3 on the HP-UX platform, the defunct processes are displayed in the system. The following example illustrates the defunct processes:
db2admin 3162322  393328   1          <0:00 defunct>
Problem Using DB2 V8.1 FP3 on the HP-UX platform might cause defunct processes. The defunct processes can accumulate over time and consume system resources.
Recommended response DB2 has fixed this problem. Upgrade your DB2 database to DB2 V8.1 FP5.

A NullPointerException exception is thrown if the serverName property is not provided when running type 4 DB2 Universal Java Database Connectivity driver

Problem When you create a data source of DB2 Universal Java Database Connectivity (JDBC) driver and set the driverType property to 4, you must provide the serverName property.
Description If you do not provide the serverName property, DB2 throws a NullPointerException instead of an exception with meaningful message.

An ArrayIndexOutOfBoundsException exception occurs when reading the CLOB data from the query result set

Symptom An ArrayIndexOutOfBoundsException exception occurs when reading the CLOB data from the query result set.
Problem The exception occurs only when the data that is retrieved can be expanded because of the character conversion. A typical scenario that causes this exception is that you retrieve the CLOB data from the query result set as an ASCII stream and then read the stream. The following example illustrates the exception trace:
java.lang.ArrayIndexOutOfBoundsException
       at COM.ibm.db2.jdbc.app.DB2InputStream.SQLReadArrayOfByte(Native Method)
       at COM.ibm.db2.jdbc.app.DB2InputStream.read(DB2InputStream.java(Compiled Code))
       at COM.ibm.db2.jdbc.app.DB2InputStream.read(DB2InputStream.java(Compiled Code))
Recommended response DB2 is aware of the problem. Contact DB2 for this problem.

When using DB2 Legacy JDBC Driver XA data source of DB2 8.1 FP5 and the AutoCommit setting is on, closing the result set cannot end the transaction

Symptom When using DB2 Legacy JDBC Driver XA data source of DB2 8.1 FP5 and the AutoCommit setting is on, closing the result set cannot end the transaction. This error causes an XAException exception with an XAER_OUTSIDE error code being thrown if you try to start an XA transaction after closing the result set.
Problem This error is a defect in DB2 Legacy JDBC driver.
Recommended response DB2 is aware of this problem. The APAR number is IY54743. Contact DB2 for a fix.

Databases-IBM Cloudscape

A NullPointerException exception occurs when you run WebSphere Application Server against Cloudscape (Version 5 and Version 5.1) and use callable statements

Symptom When running WebSphere Application Server against Cloudscape Version 5 and Version 5.1 and using callable statements, you might receive the following NullPointerException exception (message text in English only):
Unexpected exception ERROR 38000: The exception 'java.lang.NullPointerException' 
was thrown while evaluating an expression, possible causes: not calling 
registerOutputParameter and calling setNull on BIT VARYING output parameter.
       at com.ibm.db2j.protocol.Database.Errors.StandardException.newException
(StandardException.java:386)
       at com.ibm.db2j.protocol.Database.Errors.StandardException.unexpectedUserException
(StandardException.java:567)
       at com.ibm.db2j.impl.BasicServices.ClassManager.Reflect.ReflectMethod.invoke
(ReflectMethod.java:53)
       at com.ibm.db2j.impl.Database.Language.Execution.Generic.CallStatementResultSet.open
(CallStatementResultSet.java:75)
       at com.ibm.db2j.impl.Database.Language.Interface.Generic.GenericPreparedStatement.execu
te(GenericPreparedStatement.java:351)
Problem This case is rare and is usually an application error that is caused by the application not calling registerOutputParameter but calling setNull on the Bit Varying type parameter.
Recommended response If you encounter this problem and use callableStatements, ensure that you call the registerOutputParameter method.

Cannot see the descriptive error messages when running WebSphere Application Server, Version 5.0.2 against the Cloudscape Network Server or the DB2 universal driver

When running WebSphere Application Server, Version 5.0.2 against the Cloudscape Network Server or the DB2 universal driver, you cannot see the descriptive error messages from the database unless the retrieveMessagesFromServerOnGetMessage data source custom property is set to true. By default, the full message text is not returned to the client when a server-side error occurs. This property is disabled by default. See the DB2 release notes for more information on.

Setting the driverType data source custom property to 4 when you run WebSphere Application Server, Version 5.0.2 with Cloudscape using the Network Server framework

Problem When running WebSphere Application Server, Version 5.0.2 with Cloudscape using the Network Server framework, you can receive the following exception if you either forget to set the driverType data source custom property or set it to 2:
com.ibm..db2.jcc.b.SQLException: Unexpected throwable caught 
java.lang.UnsatisfiedLinkError:  DBConnect
Recommended response To avoid receiving the exception, set the driverType data source custom property to 4. Consult with information center topics for more information.

Cloudscape Version 5.0.x is deprecated in WebSphere Application Server, Version 5.0.2

Cloudscape Version 5.0.x is deprecated in WebSphere Application Server, Version 5.0.2 and is not supported or shipped with any future releases of WebSphere Application Server.

Information about how to uninstall Cloudscape Version 5.1.x

You can issue the java -jar cloudscapeUninstall.jar command to uninstall Cloudscape Version 5.1.x if going back to Cloudscape Version 5.0.x after installing Cloudscape Version 5.1.x. You can find the cloudscapeUninstall.jar file in the install_root/cloudscape51/Uninstaller, and the file is only created after installing Cloudscape Version 5.1.x.

See the WebSphere Application Server information center for the information on how to install Cloudscape Version 5.1. You need to be aware of the fact that after migrating your database to run with the new Cloudscape (using upgrade=true connectionAttributes) you can no longer run it with Cloudscape Version 5.0.

The administrative console displays DB2 settings instead of Cloudscape when you create a new Cloudscape JDBC Provider Network Server using the universal JDBC driver provider

Problem When creating a new Cloudscape JDBC Provider Network Server using the universal JDBC driver provider through the administrative console in WebSphere Application Server, Version 5.0.2, the administrative console fills in the DB2 universal data sources settings by default instead of the Cloudscape Network Server ones. Those settings include:
  1. the DataStoreHelper class
  2. the data source custom properties
The incorrect settings do not include the implementation class, which is just like the DB2 Universal one.
Recommended response If you want to create the Cloudscape JDBC Provider Network Server using the universal JDBC driver provider, perform the following steps to manually modify the entries in the administrative console:
  1. Change the DataStoreHelper class to:
    com.ibm.websphere.rsadapter.CloudscapeNetworkServerDataStoreHelper
  2. You only need the following custom properties:
    - driverType       4 (type 4 driver is the only valid value for Network Server)
      - serverName       server TCP/IP address or name.  required
      - databaseName     database name  (e.g. c:\mydb). required
      - retrieveMessagesFromServerOnGetMessage:  required by WAS not the database: 
    Defaults to false by the database, but must be set to true in WAS.
    

    The following data source custom properties are optional:

    portNumber  port number where Network Server listens for connection       
     requests.  required.  (Note: by default Network Server listens on port 1527.) 
        logWriter
        traceLevel       
        traceFile
        traceFileAppend
        deferPrepares              
    Works as documented except that  the prepare on EXECUTE STATEMENT is never deferred 
    (those are cloudscape native stuff)
     resultSetHoldability           Defaults to CLOSE_CURSORS_AT_COMMIT for    Cloudscape.  
    This is the only valid value for  Network Server. Use the JDBC 3.0 API's for setting 
    holdability.
     securityMechanism           Network Server supports the following   security Mechanisms.
     com.ibm.db2.jcc.DB2BaseDataSource.CLEAR_TEXT_PASSWORD_SECURITY    -- default
     com.ibm.db2.jcc.DB2BaseDataSource.ENCRYPTED_PASSWORD_SECURITY 
    

Cloudscape displays an exception when you access the result set after the transaction is committed

Problem When you run WebSphere Application Server with Cloudscape using the Cloudscape network server framework, Cloudscape displays an exception when you access the result set after the transaction is committed despite the fact that the cursor holdability is false by default.
Recommended response This problem does not exist when you run in Cloudscape embedded. This problem has been reported to Cloudscape. You can consult Cloudscape Support.

Ensure that your application does not rely on an exception that occurs.

Adding quotes to the installCloudscape51.bat or installCloudscape51.sh file if the install_root path includes spaces

If the install_root path includes spaces, for example, c:\program files\WebSphere\AppServe, you must modify the installCloudscape51.bat or installCloudscape51.sh file to add quotes ("") around the install_root path as follows:

Databases-Microsoft SQL Server

An error occurs when enlisting a global transaction and subsequent calls to the ResultSet.next method might stop

Symptom An error occurs when enlisting a global transaction. Subsequent calls to the ResultSet.next method might stop. The error is an XAException with error code -3 (XAER_RMERR) and is similar to the following errors:
javax.transaction.xa.XAException 
  at com.ddtek.jdbcx.sequelink.SequeLinkImplXAResource.start(Unknown Source)
                                                                                  
  at com.ddtek.jdbcx.slbase.BaseXAResource.start(Unknown Source)
                                                                                              
  at com.ddtek.jdbcspy.SpyXAResource.start(Unknown Source)
                                                                                                         
Problem This error is caused by a bug in the SequeLink Java Database Connectivity (JDBC) driver. Case 15007076 is opened against DataDirect Technologies for this problem.
Description The XAResource.start error causes the stop in the ResultSet.next method.
Recommended response To work around this problem, switch to the Connect JDBC driver to connect to the Microsoft SQL server. When a patch is received from DataDirect Technologies, a corresponding patch for the WebSphere embedded SequeLink driver is available on the DataDirect Driver Updates download page of WebSphere Application Server:

ftp://ftp.software.ibm.com/software/websphere/info/tools/DataDirect/datadirect.htm

Databases-Oracle

The Connection.setReadOnly method of Oracle database behaves differently in WebSphere Application Server

Problem Oracle does not support readonly connections. However, you can still call the connection.setReadOnly(true) method. After the connection.setReadOnly(true) method is called, the connection.isReadOnly() method returns true but the connection is still a non-readonly connection. When the connection.setReadOnly(boolean) method is called, the Oracle database starts a transaction.
Description The connection.setReadOnly(boolean) method of Oracle database behaves differently in WebSphere Application Server from the Oracle behavior previously described. When the connection.setReadOnly(true) method is called, an SQLException exception is displayed to indicate that the Oracle database does not support readonly connections. When the connection.setReadOnly(false) method is called, Application Server does not call the setReadOnly(false) method to the native Oracle connection. In either the connection.setReadOnly(false) method or the connection.setReadOnly(true) method, no Oracle transaction can start.

Database-Informix

An issue with XA transactions and IBM Informix Dynamic Server is identified

Symptom An issue with XA transactions and IBM Informix Dynamic Server is identified. This issue might cause a number of exceptions including, but not limited to: "java.sql.SQLException: Could not position within a table" or "java.sql.SQLException: Could not do a physical-order read to fetch next row." This problem might affect a number of WebSphere Application Server applications that require XA transactions support from IBM Informix Dynamic Server.
Recommended response Currently, no solution exists for the problem. IBM Informix Dynamic Server is working to resolve the issue.

Security release notes

All platforms

HPUX

Solaris

UNIX

WebSphere Application Server security help files incorrectly mapped

Problem

Some of the links from the following WebSphere Application Server security windows to their corresponding help files are incorrectly mapped:

Environment > Naming > CORBA Naming Service Users

Environment > Naming > CORBA Naming Service Users > Add

Environment > Naming > CORBA Naming Service Groups

Environment > Naming > CORBA Naming Service Groups > Add

System Administration > Console Groups > Add

  • Note: In the System Administration > Console Groups > Add window, the links to the help located next to Group Description and Role Description are correct. However, the link to the help text at the top of the help window is incorrect.

Recommended response If you access a help file that does not correspond to the appropriate WebSphere Application Server window, use the following table to locate the correct help information. When you access the incorrect help file, find the listing of help files located under Core Console on the left side of your current help file window and click the appropriate link.

Window path Correct Help file
Environment > Naming > CORBA Naming Service Users CORBA Naming Service users settings
Environment > Naming > CORBA Naming Service Users > Add CORBA Naming Service users settings
Environment > Naming > CORBA Naming Service Groups CORBA Naming Service groups
Environment > Naming > CORBA Naming Service Groups > Add CORBA Naming Service groups
System Administration > Console Groups > Add Console groups settings


Secure interoperability between WebSphere Application Server, Version 5 and WebSphere Application Server, Version 5.0.1 or later fails when the Lightweight Directory Access Protocol base distinguished name in not correctly normalized in the WebSphere Application Server, Version 5 configuration

Problem WebSphere Application Server, Version 5.0.1 or later system has a normalized distinguished name. When a WebSphere Application Server, Version 5.0.1 or later version sends a security token to a WebSphere Application Server, Version 5 system that contains a non-normalized distinguished name, the request is rejected due to the mismatched distinguished names during authorization. A common example of a request that fails is when a WebSphere Application Server, Version 5 node is synchronizing the configuration from a WebSphere Application Server, Version 5.0.1 or later deployment manager. Another example is that a request fails when a WebSphere Application Server, Version 5.0.1 or later servlet or enterprise bean makes a downstream request to a WebSphere Application Server, Version 5 enterprise bean. However, a request going from a WebSphere Application Server, Version 5 system to a WebSphere Application Server, Version 5.0.1 or later system does not fail.
Explanation In WebSphere Application Server, Version 5.0.1 or later, the distinguished name is normalized according to the Lightweight Directory Access Protocol (LDAP) specification. In WebSphere Application Server, Version 5, the normalization of the distinguished name is not done. The normalization consists of removing spaces in the base distinguished name before or after commas and equal symbols.

An example of a non-normalized base distinguished name is "o = ibm, c = us" or "o=ibm, c=us". .

An example of a normalized base distinguished name is "o=ibm,c=us".

It is preferred that the distinguished name is manually normalized when you enter the base distinguished name in the configuration. In WebSphere Application Server, Version 5.0.1 or later, the normalization occurs automatically at the run time.

Recommended response To ensure the interoperability between WebSphere Application Server, Version 5 and Version 5.0.1 or later, manually normalize the base distinguished name in the LDAP configuration on a WebSphere Application Server, Version 5 system by removing all the spaces before and after the commas and equal symbols.

WebSphere Application Server does not start when Java 2 security is enabled using the IBM Software Development Kit 1.4.1 beta release

Symptom WebSphere Application Server does not start when Java 2 security is enabled using the IBM Software Development Kit 1.4.1 beta release.
Problem WebSphere Application Server goes into a recursion and a final core dump when Java 2 security is enabled using the IBM Software Development Kit 1.4.1 beta release.

Note: This problem applies to IBM Software Development Kit 1.4.1 beta release of the WebSphere Application Server. This is not a problem for WebSphere Application Server running on the IBM Software Development Kit 1.3.X.

Recommended response

To avoid the error, do not enable Java 2 security.

By default, Java 2 security is disabled, but automatically enabled when global security is enabled through the administrative console. You should disable the Java 2 Security checkbox to disable Java 2 security.

If you fail to do this in the administrative console and have already saved your changes and tried to restart the server, you can use the wsadmin tool to disable Java 2 security.

wsadmin -conntype NONE
wsadmin>$AdminConfig modify "(cells/<node name>/security.xml)" 
{{enforceJava2Security {false}}}

wsadmin>$AdminConfig save
wsadmin>exit

Ignoring the error message about the missing ws-security.xml file in the Java Message Service server

Symptom An error or warning message is generated about the missing file %install_root%/bin/wsinstance/configdefaults/templates/system/nodes/servers/jmsserver/ws-security.xml when the Java Message Service server is started.
Problem This file is not installed during the WebSphere Application Server, Version 5.0.2 update process.
Recommended response You can ignore the error or warning message.

A Web services security enabled application fails to start

Symptom A Web services security enabled application fails to start. You can receive an error message similar to the following:
[6/19/03 11:13:02:976 EDT] 421fdaa2 KeyStoreKeyLo E WSEC5156E: An exception while retrieving the key from KeyStore object: java.security.UnrecoverableKeyException: Given final block not properly padded
Problem The cause of the problem is that the keypass (password) provided for a particular key in a Key Store is invalid. The Key Store passwords are specified in the KeyLocators elements of the bindings file(s) (ws-security.xml, ibm-webservices-bnd.xmi or ibm-webservicesclient-bnd.xmi).
Recommended response Check the keypass values for keys specified in the KeyLocators elements of the bindings file(s) and correct any that are incorrect.

The Federal Information Processing Standards security is enabled through the Secure Sockets Layer settings and the deployment manager cannot communicate with the node agent using the Simple Object Access Protocol connector

Symptom The Federal Information Processing Standards (FIPS) security is enabled through the Secure Sockets Layer (SSL) settings and the deployment manager cannot communicate with the node agent using the Simple Object Access Protocol (SOAP) connector.
Problem The provider is not set properly for the SOAP client connector.
Explanation The SOAP client must use a FIPS (Java Secure Sockets Extension) JSSE provider when the server is listening on a FIPS enabled socket.
Recommended response You must modify the java.security file to provide the FIPS properties to JSSE in both the deployment manager and each node.

In the WebSphere/AppServer/java/jre/lib/security/java.security directory and in the WebSphere/DeploymentManager/java/jre/lib/security/java.security directory, modify the following provider list:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.ibm.crypto.fips.provider.IBMJCEFIPS
security.provider.3=com.ibm.crypto.provider.IBMJCE
security.provider.4=com.ibm.fips.jsse.IBMJSSEFIPSProvider
security.provider.5=com.ibm.jsse.IBMJSSEProvider
security.provider.6=com.ibm.security.cert.IBMCertPath
security.provider.7=com.ibm.crypto.pkcs11.provider.IBMPKCS11

Problems with the Java Message Service protocol within Web services when security is enabled

Symptom The following exception occurs when you are creating a URL connection using the Java Message Service (JMS) protocol within Web services when global security is enabled:
java.security.AccessControlException: access denied 
(java.lang.RuntimePermission accessClassInPackage.sun.net.www.protocol.jms)
 at java.security.AccessControlContext.checkPermission
(AccessControlContext.java(Compiled Code))
 at java.security.AccessController.checkPermission
(AccessController.java(Compiled Code))
 at java.lang.SecurityManager.checkPermission
(SecurityManager.java(Compiled Code))
 at com.ibm.ws.security.core.SecurityManager.checkPermission
(SecurityManager.java(Compiled Code))
  at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java(Compiled Code))
If this permission is granted into the was.policy file of the application, the error that occurs is a MalformedURLException.
Problem Some security code sets the java.protocol.handler.pkgs system property, overriding what is already specified for the JMS protocol.
Recommended response You can disable the global security to avoid receiving the exception. You can also programmatically add the protocol back to the java.protocol.handler.pkgs system property by appending the following string to the end of the value already set in this system property using a | character as a delimiter:
com.ibm.ws.protocol
You must do this prior to making the Web service invocation.

A 500 type error is thrown when you click Import Keys in the Lightweight Third Party Authentication panel multiple times and save the changes each time in the administrative console

Symptom In the administrative console, when you click Import Keys in the Lightweight Third Party Authentication (LTPA ) panel multiple times in the same session and save it each time, the following message might be displayed on the console intermittently:
Error 500
An error occurred while processing request: /syncworkspace.do
Message: Server caught unhandled exception from servlet [action]: 
java.lang.IllegalStateException

Note: When you enter a wrong password in the LTPA panel during importing the keys and save the password, the save operation displays error messages in the WebSphere Status Window at the bottom of the administrative console. The keys are not updated in the run time and the old set of keys is used. However, the keys and the wrong password are saved in the configuration. This configuration is used during the next startup of the server(s)

Therefore, if you save a wrong password accidentally, do not restart the server(s) unless the password is changed because the server(s) can fail to start if the keys and the password do not match.

Problem The cause for this error is that an invalidated session is referred to under some circumstances.
Recommended response To avoid receive this error, log out and log in back to the administrative console using a new window. Import the keys if necessary. If the problem persists, use the wsadmin tool.

If you enter a wrong password and save the password during importing the keys, you can use the following wsadmin commands to change the password to the correct value (the keys should be saved during the save operation). Do not restart any servers unless the password is changed for each of them.

set LTPA [$AdminConfig list LTPA]

set ltpaPw theCorrectPassword

$AdminConfig modify $LTPA [list [list password $ltpaPw]]

$AdminConfig save

Web services security is not supported in a pure Java client (also known as a non-managed client)

Symptom Web services security is not supported in a pure Java client (also known as a non-managed client). Web services security is only supported in a managed client in WebSphere Application Server, Version 5.0.2 or later.
Problem The Web services security constraints do not apply to the outbound client or Web services acting as the client Simple Object Access Protocol (SOAP) message if the application code does not use the Java 2 Platform, Enterprise Edition (J2EE) programming model, therefore the J2EE environment (including security handlers) is not available to the client. This includes Web services security. You might configure to digitally sign, encrypt, and generate the security tokens. For the outbound message for a client or Web services acting as a client, the SOAP message is not digitally signed or encrypted and the security is not token inserted into the message.
Recommended response Change the application to a managed client application and use the J2EE programming model to invoke Web services.

AccessControlExceptions exceptions might be reported in the system log file that are associated with the JavaMail-related configuration files

Symptom In the system log file, WebSphere Application Server might report AccessControlExceptions exceptions that are associated with certain JavaMail-related configuration files such as .mailcap, mailcap, javamail.providers, and so on.
Problem These exceptions are benign. This is not an application or system problem because the JavaMail anticipates the exceptions and handles them appropriately. The WebSphere SecurityManager is rather verbose in logging possible violations of the Java 2 security access control exceptions.
Recommended response To reduce this redundant reporting, you can grant read access to each reported JavaMail configuration file. For more information, see information center topics, "AccessControlException" and "Configuring app.policy files."

An error occurs when you use the wsadmin tool with the Remote Method Invocation connector and security enabled if only the administrative scripting client is installed during a WebSphere Application Server base installation

Symptom The following error displays whey you try to use the wsadmin tool with the Remote Method Invocation (RMI) connector and security enabled if only the administrative scripting client is installed during a WebSphere Application Server base installation.
C:\WebSphere\AppServer\bin>wsadmin  -host smhardh1   -conntype  RMI -port  9809
WASX7023E: Error creating "RMI" connection to host "smhardh1"; exception information: 
com.ibm.websphere.management.exception.ConnectorNotAvailableException
WASX7213I: This scripting client is not connected to a server process; please refer 
to the log file
C:\WebSphere\AppServer\logs\wsadmin.traceout for additional information.
WASX7029I: For help, enter: "$Help help"  
wsadmin>exit
Problem When you install the administrative scripting feature from the installation of the base product of WebSphere Application Server, the certpath.jar file is missing in thejava/jre/lib/ext directory. When you use the RMI connector, you need this JAR file.
Recommended response To solve this problem, perform a WebSphere Application Server full installation and get the certpath.jar file from the ${install_root}/java/jre/lib/ext directory and copy it to the administrative scripting ${install_root}/java/jre/lib/ext directory.

An alternative is to install the full installation of the base product of WebSphere Application Server which includes the certpath.jar file.

Federal Information Processing Standards are supported in WebSphere Application Server, Version 5.0.2 or later

WebSphere Application Server, Version 5.0.2 or later supports a configuration option to use only Federal Information Processing Standards (FIPS) 140-2 certified cryptography modules including IBM Java Cryptography Extension Federal Information Processing Standards (IBMJCEFIPS) and IBM Java Secure Socket Extension Federal Information Processing Standards (IBMJSSEFIPS).

When WebSphere Application Server, Version 5.0.2 or later has FIPS-certified cryptography modules enabled, it uses the IBMJCEFIPS provider exclusively and does not use the IBMJCE provider. Also, when these cryptography modules are enabled, you can configure WebSphere Application Server to use the IBMJSSEFIPS provider on a per port basis.

The IBMJCEFIPS and IBMJSSEFIPS providers that are packaged in WebSphere Application Server, Version 5.0.2 or later are currently in the FIPS certification process. The IBMJCEFIPS and IBMJSSEFIPS modules in WebSphere Application Server, Version 5.0.2, are being certified using the IBM Software Development Kit, Version 1.3.1. The modules are undergoing certification for the Windows and AIX platforms and Solaris Operating System only.

IBM is firmly committed to FIPS certification and to meet the Government Security Standards. The IBMJSSEFIPS and IBMJCEFIPS providers are undergoing FIPS 140-2 certification. For more information, see the Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List.

Applications with Web services security enabled cannot interoperate between Version 5.1 and Version 5.0.2 Application Servers

Problem Applications with Web services security enabled cannot interoperate between Version 5.1 and Version 5.0.2 Application Servers. The error message "digest mismatch" is displayed.
Description An error exists in the canonicalization algorithm for XML digital signatures, which is fixed in WebSphere Application Server, Version 5.1. For Web services security to interoperate between WebSphere Application Server Version 5.1 and Version 5.0.2 application servers, you must update Version 5.0.2..
Recommended response Download the latest cumulative interim fix for WebSphere Application Server, Version 5.0.2 security. You can download this update by accessing the WebSphere Application Server support Web site and clicking All Updates (Fixes, patches, etc.). The update containing this interim fix will be available after the Version 5.0.2.1 interim fix.

Interoperability issue exists between WebSphere Application Server for z/OS and WebSphere Application Server distributed packages when Secure Sockets Layer is supported, but not required

Symptom An interoperability issue exists between WebSphere Application Server for z/OS and WebSphere Application Server distributed packages when Secure Sockets Layer is supported, but not required.
Problem WebSphere Application Server distributed packages set an integrity required flag for the Common Secure Interoperability Version 2 (CSIv2) inbound configuration to true by default because Secure Sockets Layer (SSL) requires integrity at a minimum. However, WebSphere Application Server for z/OS interprets this flag as an SSL requirement.
Recommended response In the security.xml file for WebSphere Application Server distributed packages system, change the following line from:
 <CSI xmi:id="IIOPSecurityProtocol_1066667906706">
    <claims xmi:type="orb.securityprotocol:CommonSecureInterop" 
xmi:id="CommonSecureInterop_1066667906706" stateful="true">
              ...
        <requiredQOP xmi:type="orb.securityprotocol:TransportQOP" 
xmi:id="TransportQOP_1066667906706" establishTrustInClient="false" 
enableProtection="false" confidentiality="false" integrity="true"/>
              ...
    </claims>

to

  <CSI xmi:id="IIOPSecurityProtocol_1066667906706">
    <claims xmi:type="orb.securityprotocol:CommonSecureInterop" 
xmi:id="CommonSecureInterop_1066667906706" stateful="true">
              ...
        <requiredQOP xmi:type="orb.securityprotocol:TransportQOP" 
xmi:id="TransportQOP_1066667906706" establishTrustInClient="false" 
enableProtection="false" confidentiality="false" integrity="false"/>
              ...
    </claims>

You also can make the previous change using the WebSphere Application Server administrative scripting commands.

Simple WebSphere Authentication Mechanism is not supported in WebSphere Application Server Network Deployment

Symptom In the information center, the WebSphere Application Server Network Deployment documentation refers to the Simple WebSphere Authentication Mechanism (SWAM).
Problem The SWAM is not supported by WebSphere Application Server Network Deployment. WebSphere Application Server Network Deployment provides one authentication mechanism: Lightweight Third Party Authentication (LTPA).
Recommended response The reason for this problem is that SWAM security credentials are valid only on the server that created them, but LTPA credentials can be forwarded to remote server processes. For more information on LTPA, see "Configuring Lightweight Third Party Authentication" in the WebSphere Application Server Network Deployment documentation.

Cannot start the application server on Solaris Operating Environment and HP platforms with IBM Software Development Kit 1.4.1

HPUX Solaris


Symptom For the IBM Software Development Kit 1.4.1 beta on Solaris Operating Environment and HP platforms only, the application server cannot start after the installation. You see the following error in the SystemOut.log file even before security is enabled:
[6/23/03 17:03:01:543 CDT]   e93999 HttpTransport A SRVE0171I: Transport http is 
listening on port 9,080.
[6/23/03 17:03:02:542 CDT]   e93999 TraceNLS      u No message text associated 
with key Unable.to.create.server.socket in bundle com.ibm.ejs.resources.seriousMessages
[6/23/03 17:03:02:539 CDT]   e93999 SSLServerSock E Unable to create server socket
[6/23/03 17:03:02:588 CDT]   e93999 WebContainer  E SRVE0146E: Failed to Start 
Transport on host , port 9443. 
The most likely cause is that the port is already in use. Please ensure that no 
other applications are using this port 
and restart the server. com.ibm.ws.webcontainer.exception.TransportException: 
Failed to start transport https: 
java.io.IOException: java.lang.RuntimeException: Export restriction: SunJSSE only
        at com.ibm.ws.webcontainer.http.HttpTransport.startTransport(HttpTransport.java:132)
        at com.ibm.ws.webcontainer.WebContainer.startTransports(WebContainer.java:634)
        at com.ibm.ws.runtime.component.WebContainerImpl.startTransports
			(WebContainerImpl.java:319)
        at com.ibm.ws.runtime.component.WebContainerImpl.vetoableChange
			(WebContainerImpl.java:343)
        at java.beans.VetoableChangeSupport.fireVetoableChange(VetoableChangeSupport.java:300)
        at java.beans.VetoableChangeSupport.fireVetoableChange(VetoableChangeSupport.java:320)
        at java.beans.VetoableChangeSupport.fireVetoableChange(VetoableChangeSupport.java:217)
        at com.ibm.ws.runtime.component.ComponentImpl.setState(ComponentImpl.java:95)
        at com.ibm.ws.runtime.component.ComponentImpl.setStartState(ComponentImpl.java:132)
        at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:123)
        at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:543)
        at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:418)
        at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:183)
        at com.ibm.ws.runtime.WsServer.start(WsServer.java:128)
        at com.ibm.ws.runtime.WsServer.main(WsServer.java:225)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
Problem On platforms that have the IBM Software Development Kit 1.4.1, the IBM Java Secure Sockets Extension (JSSE) implementation cannot be plugged in due to the export restrictions. The IBM Software Development Kit 1.4.1 implementation prevents other JSSE implementations from being supported, at least in the international version of IBM Software Development Kit 1.4.1 shipped with WebSphere Application Server. Because of this, the out-of-the-box configuration does not allow the server to start on these two platforms, even when security is disabled. This is because the HTTP transports tries to start and they need the Secure Sockets Layer (SSL) implementation to function. For the IBM Software Development Kit 1.4.1 beta, there is not enough time to modify the configuration correctly to bypass this problem.
Recommended response To start the server, you must edit the security.xml file (even if security is disabled) to change the SSL configuration to use the Sun JSSE, the Java Cryptography Extension (JCE) and the SunX509 providers. You need to add the following properties into the security.xml at the following location:
${install_root}/config/cells/cellname/security.xml
The following is what the DefaultSSLSettings default configuration entry looks like after the edits.
<repertoire xmi:id="SSLConfig_1" alias="wsbpc11/DefaultSSLSettings">
<setting xmi:id="SecureSocketsLayer_1" keyFileName="${install_root}/etc/
DummyServerKeyFile.jks" keyFilePassword="{xor}CDo9Hgw=" keyFileFormat="JKS" tr
ustFileName="${USER_INSTALL_ROOT}/etc/DummyServerTrustFile.jks" trustFilePassword="
{xor}CDo9Hgw=" trustFileFormat="JKS" clientAuthentication="false" securityLev
el="HIGH" enableCryptoHardwareSupport="false">
        <cryptoHardware xmi:id="CryptoHardwareToken_1" tokenType="" libraryFile="" 
password=""/>
        <properties xmi:id="Property_4" name="com.ibm.ssl.protocol" value="SSLv3"/>
        <properties xmi:id="Property_5" name="com.ibm.ssl.contextProvider" value="SunJSSE"/>
        <properties xmi:id="Property_6" name="com.ibm.ssl.trustManager" value="SunX509"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.keyManager" value="SunX509"/>
        <properties xmi:id="Property_8" name="com.ibm.ssl.enabledCipherSuites" value="SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"/>
        <properties xmi:id="Property_9" name="com.ibm.ssl.keyStoreProvider" value="SUN"/>
        <properties xmi:id="Property_10" name="com.ibm.ssl.trustStoreProvider" value="SUN"/>
      </setting>
    </repertoire>
The following are the properties which you add or modify. All other information is left the same.
<properties xmi:id="Property_5" name="com.ibm.ssl.contextProvider" value="SunJSSE"/>
        <properties xmi:id="Property_6" name="com.ibm.ssl.trustManager" value="SunX509"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.keyManager" value="SunX509"/>
        <properties xmi:id="Property_8" name="com.ibm.ssl.enabledCipherSuites" value="SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"/>
        <properties xmi:id="Property_9" name="com.ibm.ssl.keyStoreProvider" value="SUN"/>
        <properties xmi:id="Property_10" name="com.ibm.ssl.trustStoreProvider" value="SUN"/>

If the ${USER_INSTALL_ROOT}/java/jre/lib/security/java.security file does not get updated, the following is what the provider list should be:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.crypto.provider.SunJCE
security.provider.3=com.ibm.security.cert.IBMCertPath
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.rsajca.Provider
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.ibm.crypto.provider.IBMJCE
security.provider.8=com.ibm.crypto.pkcs11.provider.IBMPKCS11
You should also add the following to the ${USER_INSTALL_ROOT}/properties/sas.client.props file after the existing SSL information:
com.ibm.ssl.contextProvider=SunJSSE
com.ibm.ssl.keyManager=SunX509
com.ibm.ssl.trustManager=SunX509
com.ibm.ssl.keyStoreProvider=SUN
com.ibm.ssl.trustStoreProvider=SUN

Note: Global security cannot be enabled without a fix and is not supported in this beta for Solaris Operating Environment and HP platforms.

The location of the Simple Object Access Protocol security properties file is incorrect in the setupClient.bat and setupClient.sh files

UNIX

Problem Note: This issue concerns the application client's installation of WebSphere Application Server, Version 5 Fix Pack 1.

The setupClient.bat file on Windows platforms and the setupClient.sh file on UNIX platforms incorrectly specify the location of the Simple Object Access Protocol (SOAP) security properties file.

Explanation In the setupClient.bat file, the correct location should be:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props

In the setupClient.sh file, the CLIENTSOAP variable should be:

CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
Recommended response In the setupClient.bat and setupClient.sh files, complete the following steps:
  1. Remove the leading / after file:.
  2. Change sas to soap.

Administrative console release notes

All platforms

Applicability of the following list:

Netscape browser

All platforms

AIX

Linux

Solaris

UNIX

Resolve the administrative console port conflict

Problem The administrative console port is in conflict with an application already running on the machine.
Recommended response You can change this port in the following files:
  • <install_root>/config/cells/<cellname>/nodes/<nodename>/servers/<servername>/server.xml
  • <install_root>/config/cells/<cellname>/virtualhosts.xml
Change all occurrences of port 9090 (or whatever port was selected during installation time in an IBM WebSphere Application Server coexistence scenario) to the desired port for the administrative console. Alternatively, shut down the other application using this port before starting the IBM WebSphere Application Server.

The correct directory of the pwbs_GetUrlPrefixesHelp.html file

Problem Currently, the pwbs_GetUrlPrefixesHelp.html file is incorrectly installed into the ..../adminconsole.war/com.ibm.ws.console.perftuningadmin/nl/en/pwbs_GetUrlPrefixesHelp.html directory and the .../adminconsole.war/com.ibm.ws.console.servermanagement/nl/en/pwbs_GetUrlPrefixesHelp.htmldirectory.
Recommended response To find the pwbs_GetUrlPrefixesHelp.html file from the Publish WSDL panel, you need to copy the the file into the .../adminconsole.war/com.ibm.ws.console.webservices/nl/en/pwbs_GetUrlPrefixesHelp.html directory.

Resizing the Netscape browser results in an error

Problem If you resize your Netscape browser, you can get a Data Missing error.
Recommended response You can ignore the error message; it disappears in 60 seconds.

Resizing the Netscape browser causes an error 404 message

Symptom When connecting to the IBM WebSphere Application Server administrative console from a Netscape browser, resizing the browser can cause an error 404 message to occur.
Problem This situation occurs because the browser reloads the frame when resizing the window.
Recommended response To avoid getting the error message, you can refrain from resizing the Netscape browser window, or you can connect to the IBM WebSphere Application Server administrative console using an Internet Explorer browser.

Netscape screen blanks out while using the administrative console

Problem While working with the right-hand panel of the administrative console to do regular administrative tasks, the browser screen blanks out intermittently.
Recommended response To work around this problem, do one of the following:
  • After the problem occurs, close the Netscape browser, log in again, and continue working.
  • Use the Internet Explorer browser from a Windows machine.
  • Use Netscape 7.x, Mozilla 1.x, Opera 5, or Konqueror browsers on the platform, depending on which is available. Although there is not formal support for these browsers, they have all been used successfully with the product and in many cases work better than the previous 4.7.x series of Netscape browsers.

Resizing Netscape Version 4.7 causes errors

Problem You receive the following error messages when resizing Netscape Version 4.7:
Error 0
  An error occurred while processing request: http://localhost:9090/admin/upload.do

  message:

  Details
  com.ibm.websphere.servlet.error.ServletErrorReport:
         at java.lang.Class.newInstance0(Native Method)
         ... 
Explanation After resizing Netscape 4.7, Netscape has to reload the page just as it initially loads the page on the first request. For pages that do not expect POST data, it is not a problem. But for pages that do, Netscape 4.7 cannot retain the data.

Netscape browser displays ---???--- instead of a blank line for the drop down lists

Symptom If you use the Netscape browser to access the Web Services Security GUI panels, the drop down lists which are supposed to contain a blank line display "---???---" instead of the blank line.
Problem This is because Netscape Version 4.79 does not properly interpret "" or " " as a blank.
Explanation This is in the signature method(), digest method(), canonicalization method() drop downs, and others when Netscape 4.79 is used to access the panels on an AIX system. This problem does not occur when you use Internet Explorer, which properly displays a blank line.
Recommended response There is no workaround if you use Netscape 4.79, which is the supported level of Netscape for this release.

Enabling Netscape Version 4.7 to display double-byte character set correctly

AIX Linux


Problem When using Netscape on AIX platforms without the translated package, the English version of Netscape is available for all locale environments as the default package. However, the English version of Netscape does not display double-byte character set (DBCS) characters on the browser radio buttons and title bars because the fonts are mismatched.
Recommended response To work around this problem, you can install the message resource to make the translated version of Netscape available on a DBCS environment. Use the translated version of Netscape to display the corrupted DBCS correctly. Change the locale from English to the expected DBCS locale before starting Netscape. For example, issue the following commands to display the Japanese contents on Ja_JP (AIX Shift JIS locale):
$ export LANG=Ja_JP 
$ netscape&

How to check the installed package

For the AIX platform:

  1. Run the lslpp -aL | grep Netscape.msg command.
  2. Check the language and locale information using Netscape.msg package. For example, the result of the command run in step 1 is as follows for the system having Japanese-translated Netscape:
    # lslpp -aL | grep Netscape.msg
    Netscape.msg.Ja_JP.communicator.rte
    Netscape.msg.ja_JP.communicator.rte 

For the Red Hat Linux Version 7.2 platform:

Run the rpm-ql netscape-common command to get the list of installed files.

In case of Netscape Version 4.78 on Red Hat Linux Version 7.2, the translated packages for seven languages including four DBCS languages (Japanese, Korean, Simplified Chinese, and Traditional Chinese) are included in a common package.

How to install the package

For the AIX platform:

Install the Netscape.msg.%L.communicator.rate package where %L is the locale information for the System Management Interface Tool (SMIT) or SMITTY to use. This message resource is provided by the Bonus Pack CD or the Expansion Pack CD for AIX platform, which provides the Netscape common package.

Perform the following steps to install the package:

  1. Set the media which has the Netscape installation image. For AIX 5L platform, set the Expansion Pack media.
  2. Go to the directory which has the Netscape installation package. For AIX 5L platform Expansion Pack, go to the installp/ppc directory.
  3. Start SMIT or SMITTY.
  4. Click System Environments > Manage Language Environment > Change/Show Applications for a Language > Add Language for Application Already Installed.
  5. In the Add Language for Application Already Installed field select a language (locale) from the drop-down menu list for the Language translation to install field.
  6. Click OK.
  7. In the Add Language for Application Already Installed field enter the directory location. Enter "." for the current directory or /cdrom/installp/ppc for the full path as input directory for the software. Do not select cdrom as the input device because the installation package does not exist on the root directory of the CD-ROM.
  8. Click OK.
  9. Click List to check if the configuration is correct. The configuration is correct if Netscape is on the list of installed application. Start the installation now.
  10. Click OK.
  11. Exit SMIT or SMITTY.

For Red Hat Linux Version 7.2 platform:

The default Netscape installation can install each translated resource as part of the common package. There is no way to install the translated package individually. However, TrueType fonts (TTF packages) require installation for each language to correctly display the translated resources on Netscape. Use the following to check if the required font files are correctly installed:

$ rpm -qa | grep ttf
resources.0-4
ttfm-0.9.1-8
ttfonts-ja-1.0-6
ttfonts-ko-1.0-10
ttfonts-zh_CN-2.11-5
ttfonts-zh_TW-2.11-5

When performing the addNode function to add a node to the cell, the addNode status messages are displayed with "Chinese-like" characters

AIX

Symptom When you start the administrative console with Netscape Communicator 4.792 on an AIX 5.2 system and perform the addNode function to add a node to the cell, the addNode status messages are displayed with "Chinese-like" characters. These characters are not really Chinese characters; they only appear to be. The same problem also occurs for the removeNode function.
Problem Netscape Communicator 4.792 on an AIX 5.2 system is incompatible with WebSphere Application Server. WebSphere Application Server supports Netscape Communicator 4.79 but not 4.792.
Recommended response

To resolve the problem, perform either of the following steps:

  • Use a machine that is not running AIX 5.2 and use the browser on that machine to start the administrative console.
  • Run the addNode or removeNode command from the command line of the node that is to be added to or removed from the cell.

Using Netscape Version 4.79 on a Solaris Operating Environment causes problems

Solaris
Problem Using Netscape Version 4.79 on a Solaris Operating Environment to access the administrative console causes problems with some key text translations with the zh_TW.EUC locale.
Recommended response This situation is not a problem when you use Netscape Version 4.7. The officially supported version of Netscape on a Solaris Operating Environment is Version 4.79, but in this case the workaround is to use Netscape Version 4.7.

Limitations occur when using Netscape with Solaris Operating Environment

Solaris
Symptom If you click Troubleshooting > Logs and Trace > <server> > Diagnostic Trace > Modify, the window that pops up allowing you to select the Components and Groups to trace might not display a scroll bar, preventing you from viewing all the components and groups.
Problem The text area displaying the selected components, groups, and trace levels does not have a vertical scroll bar. This omission is a limitation of Netscape on a Solaris Operating Environment.
Recommended response To work around this problem, refresh the window to show the scroll bar.

Netscape browser must be capable of launching from a terminal window on all UNIX platforms

UNIX

To make sure the Netscape browser can launch from a terminal window, edit or create a file called profile in the /etc directory and add the Netscape directory to the system path. For example:

PATH=$PATH:/opt/Netscape
export PATH

Scripting release notes

An error occurs when you use the wsadmin tool with the Remote Method Invocation connector and security enabled if only the administrative scripting client is installed during a WebSphere Application Server base installation

Symptom The following error occurs whey you try to use the wsadmin tool with the Remote Method Invocation (RMI) connector and security enabled if only the administrative scripting client is installed during a WebSphere Application Server base installation.
C:\WebSphere\AppServer\bin>wsadmin  -host smhardh1   -conntype  RMI -port  9809
WASX7023E: Error creating "RMI" connection to host "smhardh1"; exception information: com.ibm.websphere.management.exception.ConnectorNotAvailableException
WASX7213I: This scripting client is not connected to a server process; please refer to the log file
C:\WebSphere\AppServer\logs\wsadmin.traceout for additional information.
WASX7029I: For help, enter: "$Help help"  
wsadmin>exit
Problem When you install the administrative scripting feature from the WebSphere Application Server base installation, the certpath.jar file is missing in thejava/jre/lib/ext directory. When you use the RMI connector, you need this JAR file.
Recommended response To solve this problem, perform a WebSphere Application Server full installation and get the certpath.jar file from the ${install_root}/java/jre/lib/ext directory and copy it to the administrative scripting ${install_root}/java/jre/lib/ext directory.

An alternative is to install the full WebSphere Application Server base installation which includes the certpath.jar file.

Commands testConnection and getPropertiesForDataSource are deprecated

Problem This note documents two commands as deprecated. The two commands are testConnection and getPropertiesForDataSource commands in the AdminControl scripting object.
Explanation

$AdminControl TestConnection configId props

This command is deprecated.

This command might give false results and does not work when connected to a node agent. As of WebSphere Application Server, Version 5.0.2 or later, the preferred way to test a data source connection is the testConnection command passing in the data source configuration ID as the only parameter.

Running this command in WebSphere Application Server, Version 5.0.2 or later returns the following message:

WASX7390E: Operation not supported - testConnection command with config id
and properties arguments is not supported. Use testConnection command with
config id argument only.

$AdminControl getPropertiesForDataSource configId

This command is deprecated and there is no replacement.

This command incorrectly assumes the availability of the configuration service when you run it in the connected mode.

Running this command in WebSphere Application Server, Version 5.0.2 or later returns the following message:

WASX7389E: Operation not supported - getPropertiesForDataSource command is not supported.

Using a WebSphere Application Server, Version 5.0.2 or later wsadmin scripting client to connect to a Version 5.0.2 or later server to create or update the native type configuration data

Symptom This note documents a restriction using a WebSphere Application Server Version 5 or Version 5.0.1 wsadmin scripting client, to connect to a Version 5.0.2 or later server.

Exception occurs when you create or modify configuration attribute that uses Java native type. The following exception occurs when you update a boolean type attribute:

WASX7015E: Exception running command: "$AdminConfig modify $targetMappings 
{{enable false}}"; exception information: com.ibm.ws.scripting.ScriptingException: 
WASX7239E: Unexpected error setting attribute "enable" of type "boolean" to value "false."  
Additional information may be found in the trace log.
Problem The reason for this exception is that certain WebSphere Application Server, Version 5.0.2 or later configuration data use Java native types that are not recognized by a WebSphere Application Server, Version 5 or Version 5.0.1 wsadmin scripting client. The known Java native types include boolean, int, and long.
Recommended response To work around this problem, use a WebSphere Application Server, Version 5.0.2 or later wsadmin scripting client to connect to a Version 5.0.2 or later server to create or update the native type configuration data.

System performance degrades when you configure the node agent failover with a certain script

Problem If you configure the nodeagent failover with the script created by {intall_root/bin/startServer.sh nodeagent -script startnodeagent.sh -background script, the system performance degrades. A message similar to the following displays:
Feb 28 14:48:37 wastst12 init: Id "was" respawning too fast: disabled for 5 minutes
Recommended response Configure the nodeagent failover with the script created by the {install_root} /bin/startServer.sh nodeagent -script startnodeagent.sh file to work around the problem..

Administrative data and Server configuration files release notes

Empty NetworkDeploymentCell directory is left in the configuration directory

Problem When you install IBM WebSphere Application Server, and you run addNode then removeNode, sometimes an empty NetworkDeploymentCell directory is left in the configuration directory making the wsadmin tool think these two cells are configured.
Description The WebSphere Application Server product cannot delete the directory because the directory is locked by another application. The most common reason for this situation is that another application uses that directory or its subdirectory as the current working directory, or another application opens a file under that directory or subdirectory. This problem is most commonly seen on Windows platforms, but it can happen on other platforms.
Recommended response To work around this problem, manually delete the empty directory structure, then restart the servers that use this configuration directory.

Issuing the addNode command can replace the plugin-cfg.xml file

After federating the Node, the addNode command backs up the plugin-cfg.xml file from the <install_root>/config/cells directory to the config/backup/base/cells directory. The addNode command in Fix Pack 2 regenerates a new plugin-cfg.xml file at the Deployment Manger and the nodeSync operation copies the files to the node level.

Enabling authentication in the file transfer service

In WebSphere Application Server Network Deployment, Version 5.0.1 or later, the file transfer service is enhanced to provide role-based authentication. Two versions of the file transfer Web application are provided. By default, the version that does not authenticate its caller is installed. This default supports compatibility between the WebSphere Application Server Network Deployment, Version 5 and Version 5.0.1.

After all the nodes in your cell are upgraded from WebSphere Application Server Network Deployment, Version 5 to Version 5.0.1, Version 5.0.2, Version 5.1, Version 5.1.1, you can activate the authentication in the file transfer by redeploying the file transfer application at the deployment manager. The compatible version is shipped in the ${install_root}/installableApps/filetransfer.ear file. The secured version is provided in the ${install_root}/installableApps/filetransferSecured.ear file.

A wsadmin JACLl script is provided to help you redeploy the file transfer. The script is redeployFileTransfer.jacl and you can find it in the ${install_root}/bin directory. After the deployment manager and all the nodes are upgraded to WebSphere Application Server Network Deployment, Version 5.0.1, Version 5.0.2, Version 5.1, or Version 5.1.1, you can deploy the secured file transfer service by running the script. The syntax for running the script is:

wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOn ear_file_path"

For example, when running the script from the c:/WebSphere/DeploymentManager/bin directory, the syntax is similar to the following example:

wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOn 
c:/WebSphere/DeploymentManager/installableApps"

If you want to go back to run the file transfer service without authentication, you can run the script as shown in the following example:

wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOff ear_file_path"

Performance data and tools release notes

Editing the plugin-cfg.xml file and changing the value of the ESIEnable variable

For performance purposes, edit the plugin-cfg.xml file and change the value of the ESIEnable variable, if it exists, from false to true.

<Property Name="ESIEnable" Value="true"/>

Setting the maximum pool size to the advised value and set the minimum pool size to half of the advised value

Symptom The Tivoli Performance Viewer Advisor and the Runtime Performance Advisor (RPA) might issue a message telling you to change the thread pool size, without specifying whether to change the minimum or maximum size. An example of such a message is Tune 0202W: Increasing the ORB thread pool to 1 may improve performance.
Problem The rule does not specify whether to change the minimum or maximum size of the thread pool.
Recommended response You should set the maximum pool size to the advised value and set the minimum pool size to half of the advised value.

The prepared statement recommendation might be too large

Symptom The Tivoli Performance Viewer Advisor or the Runtime Performance Advisor (RPA) issues advice telling you to increase the size of the prepared statement cache to an unreasonably large value, for example, 3000. On some systems this adjustment can cause a system failure or an out of memory error.
Problem If the application has a very large number of prepared statements that are all consistently used, a lot of discards exist from the cache. The advisors see the number of discards from the cache and recommend increasing the size of the prepared statement cache. The advisors do not currentlyconsider the memory resources used by the prepared statement cache entries.
Recommended response Do not increase the prepared statement cache above 1000, unless you are sure that you have appropriate resources.

The Tivoli Performance Viewer Advisor and the Runtime Performance Advisor might give contradictory advice on shared resources

Symptom The Tivoli Performance Viewer Advisor and the Runtime Performance Advisor (RPA) might give contradictory advice for Java Database Connectivity (JDBC) Resources configured at the node or cell level and used at the server level.
Problem When servers share a resource, each server might use the resource differently. The advisors only provide advice within the scope of a single server, without consideration of how other servers might be using the shared resource.
Recommended response Compare advice about the shared JDBC resources from all the application servers before taking such advice. If the advice is consistent, take it. If the advice is inconsistent, use your best judgment to configure the shared resources.

Ignoring the advice to set the configuration for the Java virtual machine heap size maximum on iSeries

Symptom When you use the Tivoli Performance Viewer advisor to monitor a WebSphere Application Server running on iSeries, the advisor might show the following warnings:
"TUNE5003W: The JVM maximum heap size is unusually small.  Typically, the maximum heap size is greater than or equal to..." 
or
"TUNE5005W: The initial JVM  heap size is greater than the maximum heap size."
Problem On iSeries, the default maximum for the Java virtual machine (JVM) heap size is set to 0, to indicate an unlimited size.
Recommended response You should ignore the advice to set the configuration for the JVM heap size maximum on iSeries.

Removing the Performance Advisors Technology Preview JAR files after upgrading to Fix Pack 2 from a previous installation with the Performance Advisors Technology Preview installed

Symptom After upgrading to Fix Pack 2 from a previous installation with the Performance Advisors Technology Preview installed, the Tivoli Performance Viewer Advisor and Runtime Performance Advisor (RPA) might not function properly. Typical exceptions might be:
"[ServletException in:/secure/layouts/detailTitleLayout.jsp] Cannot find bean com.ibm.ws.console.pertuningAdmin.RPAAdviceDetailForm in scope Null"
"An error occurred while processing request: /com.ibm.ws.console.perfTuningAdmin.forwardCmd.do.  Message com.ibm.ws.performance.tuning.rule.RuleLookup: method <init>=(Ljava/io/InputStream;) V not found"
Problem The Performance Advisors Technology Preview JAR files in the install_root/classes directory are not removed by the Fix Pack 2 installer. The classes in the JAR files conflict with the new classes for the Performance Advisors installed with Fix Pack 2.
Recommended response The Performance Advisors Technology Preview JAR files are no longer needed. You should manually remove them from the classes directory. You can do this before or after the installation of Fix Pack 2.

The fix pack installer does not update the files that are transferred during federation

Symptom If you install WebSphere Application Server Network Deployment, Version 5 or Version 5.0.1, including federation of your nodes, and then install Fix Pack 2, the Runtime Performance Advisor (RPA) does not work correctly and might throw exceptions when it is enabled. When enabling the RPA, you can receive exceptions similar to the following:
"RPARuleEngineController caught unexpected exception java.lang.Exception: could not  get input stream for perftuners.xml from ..." 
or
"[ServletException in:/secure/layouts/tabsLayout.jsp]  Error - Tag Insert : At least one of the following attribute must be defined :  template|page|attribute|definition|name|beanName. Check tag syntax'" 
Problem The fix pack installer does not update the files that are transferred during federation. The RPA configuration file (perftuners.xml) is moved during federation so it is not correctly handled by the fix pack installer.
Recommended response Immediately after applying Fix Pack 2, you should manually copy the RPA configuration file into the Network Deployment configuration directory. From the node installation, copy %install_root%/config/cells/<cellName>/nodes/<nodeName>/perftuners.xml to the Deployment Manager installation at <DeploymentManagerHome>/config/cells/<cellName>/nodes/<nodeName>/perftuners.xml. Note: If the file synchronization service is running then synchronization might delete the perftuners.xml file from the node. In this case, the file might be extracted from the perftuning.jar file found in the %install_root%/lib directory.

Tivoli Performance Viewer cannot connect to a running server if security is enabled

Symptom Tivoli Performance Viewer cannot connect to a running WebSphere Application Server. The SystemOut.log file of the server located at the $install_root/logs/<servername> directory might display errors similar to the following:
SECJ0305I: Role based authorization check failed for security name <null>, accessId 
no_cred_no_access_id while invoking method.
Problem If security is enabled in WebSphere Application Server, Version 5, Tivoli Performance Viewer cannot connect to the server using a Simple Object Access Protocol (SOAP) connector if the proper user login and password are not set in the SOAP properties file.
Recommended response Set the user name and password in the soap.client.props file located at the $install_root/properties directory. Set the values for the keys com.ibm.SOAP.loginUserid and com.ibm.SOAP.loginPassword. The password can be encrypted using the PropFilePasswordEncoder utility located in $install_root/bin. You can find more information by searching the topic, "Running your monitoring applications with security enabled" in the WebSphere Application Server, Version 5 information center.

Tivoli Performance Viewer cannot set all Performance Monitoring Infrastructure levels to None if the Runtime Performance Advisor is enabled

Symptom When trying to set the monitoring level for a Performance Monitoring Infrastructure (PMI) module to None through Tivoli Performance Viewer, you can find that the monitoring level for the module continually reverts back to High.
Problem If the Runtime Performance Advisor (RPA) is enabled on the server, it sets the monitoring level for PMI modules back to High. This behavior is by design, because the RPA requires data for certain modules.

Ignoring the NotSerializableException exception when setting a servlet session manager Performance Monitoring Infrastructure module to level maximum

Problem When setting a servlet session manager Performance Monitoring Infrastructure (PMI) module to level maximum (or enabling session object advisor rule), you can receive a message similar to the following:
"SessionContex E Exception is: java.io.NotSerializableException: ....."
Recommended response The session manager throws this exception when a declared serializable object in the session is not serializable. From PMI usage only, you can ignore the exception. However, if the exception object is from a user application, you must figure out if the wrong declaration of serialization has any other side effects.

Setting the monitoring level for the the Servlet Session Manager modules to Medium or higher

Symptom The Tivoli Performance Viewer advisor might display the following error message:
"TUNE0324W: There was an unknown error  detected in the Runtime Performance Advisor.  Check the application server logs and  enable trace."
Problem If the monitoring level for the servlet session manager Performance Monitoring Infrastructure (PMI) modules is set to None or Low, and if session persistence is enabled under Web Container > Session Management > Distributed Environment Settings, the error message is displayed because not enough session data are available for the advisor to give advice about the session size.
Recommended response You must set the monitoring level for the the servlet session manager modules to Medium or higher. You can do this either through Tivoli Performance Viewer or through the administrative console.

The node agent SystemOut.log message repeats continuously on an AIX platform when the Performance Monitoring Infrastructure is enabled

Problem On an AIX platform when the Performance Monitoring Infrastructure is enabled, the following node agent SystemOut.log message repeats continuously:
No PMI Module found for the Mbean systemModule
Recommended response To avoid receiving the message, install the bos.perf file set on an AIX platform.

Install the bos.perf.libperfstat and bos.perf.perfstat files on an AIX platform

Problem On an AIX platform, Tivoli Performance Viewer does not show the counters and performance data from the system data module.
Recommended response Install the bos.perf.libperfstat and bos.perf.perfstat files on an AIX platform.

To verify if both files are on your system, issue the following commands:

lslpp -achq  bos.perf.libperfstat
lslpp -achq  bos.perf.perfstat

If you see a message similar to Fileset bos.perf.libperfstat not installed, install the required bos.perf.libperfstat and bos.perf.perfstat files from the AIX base installation Web site.

Using tools on the HP platform to check the memory usage of the WebSphere Application Server process might show a high memory usage

Problem Using tools on the HP platform to check the memory usage of the WebSphere Application Server process might show a high memory usage (with the maximum set to 256 MB).
Description The virtual number shown in glance and other tools does not represent the actual physical memory committed in use. This behavior is normal on the HP platform.

When enabling Java Virtual Machine Profiler Interface with the XrunpmiJvmpiProfiler flag on Red Hat Enterprise Linux V3.0 systems, the application server might not start

Symptom When enabling Java Virtual Machine Profiler Interface (JVMPI) with the XrunpmiJvmpiProfiler flag on Red Hat Enterprise Linux V3.0 systems, the application server might not start.
Problem The legacy C libraries are not installed.
Recommended response Follow the instructions in the Installation release note titled "Providing necessary prerequisites for Red Hat Enterprise Linux V3.0"



Searchable topic ID:   relnotes
Last updated: Jun 21, 2007 10:47:44 PM CDT    WebSphere Application Server Network Deployment
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/

Library | Support | Terms of Use | Feedback