IBM WebSphere Application Server
Version 3.5 for Linux
Release Notes

Last updated 12/18/00 @ 2:30 p.m. Eastern time

This document contains the Release Notes for IBM WebSphere Application Server Version 3 Release 5 for Linux (Intel) and Linux on S/390. This release brings the features of IBM WebSphere Application Server Version 3.5.1 (in other words, Version 3.5 with Fix Pack 1 applied) to many popular Linux distributions. See the prerequisites Web page for the supported distributions and versions:

http://www.ibm.com/software/webservers/appserv/doc/v35/prereq.html

Check the Support page for subsequent Version 3.5 Fix Packs for your installation of IBM WebSphere Application Server on Linux, such as Version 3.5.3:

http://www-4.ibm.com/software/webservers/appserv/efix.html

Although this document focuses on items specific to using the product on Linux, it includes a short section for problems discovered during testing on Linux, but that are suspected to apply to all operating systems. Consider referring to the Fix Pack 1 and Version 3.5 base Release Notes documents for additional problems, workarounds, and limitations that could apply to the product on Linux.

When printing this document, it is recommended that you use "landscape" formatting.

Release Notes

The Release Notes contain information about known defects and the workarounds.

Items specific to IBM WebSphere Application Server for Linux

Problem Linux Distribution Workaround
When using the Custom installation option to configure the product to use an existing database, double-check the default value provided for the JDBC driver location. It is likely you will need to modify it.

If you encounter this problem after installation, the symptom will be that the administrative server (using startupServer.sh) fails to start.

All When prompted for the location of the JDBC driver for DB2, overwrite the default value with the path to your database instance home.

For example, if the Oracle driver is located at /usr/oracle/myoracle/jdbc/lib/classes111.zip, then enter the location /usr/oracle/myoracle/. See the driver location section of InfoCenter article 1.2.3.6 for further guidance.

If you discover this problem after installation (the administrative server will not start because it cannot find the database), correct the problem by editing these WebSphere Application Server files:

  • product_installation_root/startupServer.sh

    In this script, set the DB_INSTANCE_HOME variable correctly.

  • product_installation_root/bin/admin.config

    From the com.ibm.ejs.sm.adminserver.classpath directive, remove the extraneous path information. For DB2, look for the second occurrence of /sqllib/java12/db2java.zip and remove it.

Do not edit the files unless you encounter this problem, or new problems could be introduced. After making the changes, attempt to start the administrative server.

When using the Custom installation option to configure the product to use an existing Oracle database, be sure to specify the database URL in the correct format. The example provided by the script is provided in typical DB2 format, instead of Oracle format. All An example of an Oracle URL is:

jdbc:oracle:thin:@<machine name>:1521:<database_name>

where <machine name> is the short or the fully qualified hostname of the Oracle server machine.
JAVA_HOME cannot be set before installing, or while running, IBM WebSphere Application Server Version 3.5 for Linux. All Before installing or running WebSphere Application Server for Linux, ensure that JAVA_HOME is not set.

For example, note that the Caldera startup shell scripts set JAVA_HOME=/usr/java. Other Linux operating systems might have similar statements in their startup scripts.

Additional installation step is required. All Locate the following step in the installation and configuration instructions for WebSphere Application Server Version 3.5 on Linux:

Copy the WebSphere Samples to the Web server document root, shown here as document_root:

cp -r /opt/IBMWebAS/WSsamples document_root
cp -r /opt/IBMWebAS/WSsamplesIDB document_root

It is recommended that you then perform an additional copy statement:

cp -r /opt/IBMWebAS/theme document_root

If you are going to operate a machine in a cluster of WebSphere application servers performing workload management, you must execute certain commands on each machine to prepare it. All Issue the following instructions at a system command prompt:

echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
ifconfig lo:1 down
ifconfig lo:1 clusteraddress netmask 0.0.0.0 up

Typically, you will need to issue these commands each time the machine is rebooted.

The Web-based installation of the WebSphere Administrative Console as described in documentation article 1.2.2.4.1.2 does not provide an option for installing the console this way on Linux. All None
The WebSphere Administrative Console does not display Hangul characters, meaning Korean and Traditional Chinese are not supported configurations for displaying the product administrative interface. All None
The functionality provided by the IBM Distributed Debugger and Object Level Trace on Linux is similar to that provided on Solaris.

Therefore, for information regarding the use of the IBM Distributed Debugger and Object Level Trace on Linux, please refer to the existing documentation for that on Solaris. This information includes the F1 help, the online information webs, and the samples documentation.

All None
When I use step debug while debugging applications running on my Application Server on Linux, the IBM Distributed Debugger hangs. All None. You can use step over or step into instead. There is no workaround to this problem at the moment. It is a JDK problem.
WebSphere Application Server for Linux on S/390 cannot connect to a remote DB2 database instance on a machine running WebSphere Application Server for Linux (Intel) because the DB2 versions are incompatible (7.1 on S/390 and 6.1 on the Intel machine).

Even if the remote node and database are cataloged correctly, DB2 will display the error message:

SQL5048N The release level of the database client is not supported by the release level of the database server.

All None.
The JDK used by WebSphere Application Server Version 3.5 requires glibc updates to Linux servers in some cases. Caldera Obtain these glibc updates from the Caldera Web site:

ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/glibc-2.1.3-4S.i386.rpm
ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/glibc-localedata-2.1.3-4S.i386.rpm
ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/glibc-devel-static-2.1.3-4S.i386.rpm
ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/glibc-devel-2.1.3-4S.i386.rpm

It is suggested that you place them in an empty temporary directory, from which you can run this command one time to apply all four updates:

rpm -Fhv glibc-*i386.rpm

Note, if the directory in which you placed these files contains any pre-existing files matching the above command parameters, those updates will be applied, too.

You need an additional RPM to obtain full SMP support. RedHat Obtain the RPM from:

ftp://ftp.redhat.com/pub/redhat/updates/6.2/i386/glibc-2.1.3-21.i386.rpm

Typically, the command for installing the RPM is as follows:

rpm -Uvh glibc-2.1.3-21.i386.rpm

Migration steps are required for moving from IBM WebSphere Application Server Version 3.0.2.x for Linux to Version 3.5 for Linux. RedHat To migrate from 3.0.2.x:
  1. Upgrade to 3.0.2.2 from 3.0.2.1 if you have not done so already.

  2. Export the 3.0.2.2 configuration:

    1. Add /opt/IBMWebAS/lib/tasks.jar to your classpath (if using Version 3.0.2.2 or below).
    2. Change directory to /opt/IBMWebAS/bin

    3. Issue the command:

      ./XMLConfig.sh -export /tmp/export.xml -adminNodeName <hostname>

      where is not the fully qualified name, but the name of the WebSphere administrative server node on that machine.

  3. Drop the existing instance, install Fixpack 5 (on the CD), recreate the instance.

  4. Run migration.sh from the WebSphere Application Server Version 3.5 for Linux product CD, using the export.xml file from above as a parameter, such as:

    ./migration.sh /tmp/export.xml

  5. Edit the file admin.config in the WebSphere Application Server bin directory.

  6. Set install.initial.config=false.

  7. Start WebSphere Application Server.

  8. Import your XML configuration:

    1. Change directory to /opt/IBMWebAS/bin

    2. Issue the command:

      ./XMLConfig.sh -import /tmp/export.xml -adminNodeName <hostname>

IBM UDB DB2 6.1 requires configuration to install correctly in some cases. SuSE Because the following steps are performed by the product installation script, you should not encounter this problem. The steps are provided here in case you cannot use the script for some reason.

If using SuSE, perform these steps to change some RPM entries, allowing DB2 6.1 to install correctly with the SuSE glibc packages.

From the DB2 installation directory (from which you will install DB2) issue the command:

cd db2/install/dummyrpm

From the dummyrpm directory, issue this command to install the DB2 glibc patch:

rpm -ivh glibc-2.0.7-0.i386.rpm

You can now install DB2.

Default DB2 user IDs created during operating system installation cause problems because they are not in their standard locations. SuSE Usually, such IDs are created in /home/[username], where [username] is either db2inst1, db2fenc1, or db2as. The SuSE installation creates them elsewhere, meaning WebSphere Application Server has trouble finding and using them. For example, it expects db2inst1 to be located in /home/db2inst1, and with a default password of db2inst1.

Delete the non-standard user IDs and create them again using the standard values (home directories starting with /home).

Use the operating-system-level user administration tool of your choice, such as YAST, to perform these tasks:

  1. In the user administration facility, delete all three users.

  2. Create the users. Set their group as one of the default administrative groups created by SuSE.

    You must use one of the default administrative groups because on SuSE you are not allowed to create a db2 instance for a user ID that is a member of the users group, which is the default group that new users belong to unless you assign them to one of the default groups created by SuSE.

After you perform the above steps, the IDs that you use for the db2 instances should function properly.

The WebSphere Administrative Console help files and the HTML version of the product documentation cannot be displayed on an S/390 machine. Linux on S/390 View the help files and HTML documentation from a machine containing a Web browser. An S/390 machine does not contain a Web browser.

Using a Web browser, users can view and download the help and documentation from the WebSphere Application Server InfoCenter Web page at http://www.ibm.com/software/webservers/appserv/infocenter.html.

To access the help files, open the InfoCenter and navigate to article 6.6. On the left side navigation panel, article 6.6 is available by clicking Application Server -> 6. Administer applications -> Help files. Also, from the Web-based InfoCenter, users can download PDF versions of the documentation to view locally.

Additional items

These are problems and limitations discovered during product testing on Linux. They are likely to apply to the product on other supported operating systems as well.

Problem Workaround
IBM HTTP Servers and Apache Servers require EAPI support for use with IBM WebSphere Application Server. If you get the following error, then your Web server does not have EAPI support:

Cannot load /opt/IBMWebAS/bin/mod_app_server.so into server: /opt/IBMWebAS/bin/mod_app_server.so: undefined symbol: ap_ctx_get ./apachectl start: httpd could not be started

The error will be displayed in the command window or shell from which you started the Web server. You are likely to encounter this error if you obtained the Web server by compiling the Apache Server source code from www.apache.org.

To correct the problem, change the LoadModule line in the Web server configuration file (httpd.conf) to point to the non-EAPI file, such as /opt/IBMWebAS/bin/mod_app_server_noeapi.so.
When using the Chinese version of the product with a DB2 database, extra parameters are required while creating and connecting to the database.

A symptom of this problem is that blank or Chinese characters on the WebSphere Administrative Console (Java console) are displayed as garbage.

At minimum, this problem occurs on Turbo Linux.

When you create the WAS database to hold the WebSphere administrative data, add codeset and territory parameters to the command as shown:

db2 create database was using codeset GBK territory zh_CN

When connecting to the database, run the command to change the db2codepage from 819 to 1386:

db2set db2codepage=1386
db2 terminate

If you use the WebSphere Application Server Version 3.5 for Linux installation script to install DB2 and create the WAS database, you will encounter this problem because the script does not contain the above codeset and territory parameters.

It is recommended that you install DB2 by hand (instead of using the product script), then create your WAS database, being sure to include the above parameters. Then install WebSphere Application Server, using the Custom database configuration option provided by its installation script. The Custom option allows you to configure the product to use an existing database installation.

Alternatively, if you allow the WebSphere Application Server to create the WAS database automatically, then drop the database and create it again using the above parameters. Do so after installing WebSphere Application Server but before starting WebSphere Application Server.

While using the WebSphere Administrative Console (Java console) to browse inside a JAR file for a particular enterprise bean to deploy, you could encounter an "invalid drive" error. The error typically occurs when the user clicks a bean to select it for deployment. Here are three ways to avoid the problem:
  • Double-click the bean instead of single-clicking it.
  • Deploy the entire JAR file instead of the single bean.
  • Enter the full path to the JAR file, including its name, in the entry field of the deployment browser.
The Resource Analyzer does not connect correctly to server that you reference by its fully qualified name. You must invoke the Resource Analyzer script using the short name of the server to which you want to connect.