IBM WebSphere Application Server
Advanced Single Server Edition Version 4.0.6, and
Advanced Edition Version 4.0.6
Release Notes

Last updated: 06/16/2003

This document contains the Release Notes for WebSphere Application Server Advanced Single Server Edition Version 4 Fix Pack 6 (4.0.6) and Advanced Edition Version 4 Fix Pack 6 (4.0.6). Note that WebSphere Application Server Version 4 Fix Pack 6 (4.0.6) does not support TurboLinux on zOS.

These notes will be updated periodically. For the latest version of these Release Notes, check the IBM WebSphere Application Server InfoCenter page at http://www.ibm.com/software/webservers/appserv/infocenter.html.

This document covers the following topics:

The prerequisite products for the IBM WebSphere Application Server

The following Web site lists the prerequisite products for the IBM WebSphere Application Server:

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

Required Reading: Third Party Licenses for Version 4.0.6

Read the license for each product that you intend to use. These licenses are provided in English only.

What's New in Version 4.0.6

WebSphere Application Server Version 4.0.6 provides prerequisite upgrades for the following:

Installing Version 4.0.6

Complete installation instructions for Version 4.0.6 are included in the README file shipped with the fix pack installation code. Read the README file before installing Version 4.0.6. Note that fix packs are cumulative and contain all updates and fixes shipped in previous fix packs.

If you are upgrading to WebSphere Application Server Version 4.0.6 and you use DataDirect (formerly Merant) drivers to connect to backend databases, upgrade to the latest version of these drivers. See the IBM Support site for more information.

Using the TechNotes database

The TechNotes database contains additional information about known defects and the workarounds. The TechNotes database also includes some supplemental information for topics covered in the WebSphere Application Server documentation.

To search the TechNotes database, go to the TechNotes database Web page, select a component, and click Go. You can also search the database by keywords.

Possible problems and suggested fixes

This section contains information about known defects and the workarounds. If a problem that you encounter is not mentioned in this section, examine the TechNotes database for information on that problem.

Installation and configuration

All operating systems

UNIX

AIX

HP-UX

Linux

Solaris Operating Environment

Windows2000

Windows NT

Regenerating the plug-in configuration after installing WebSphere Application Server fix packs (Defect PQ61587)

After installing a WebSphere Application Server fix pack, regenerate the plug-in configuration. Before you begin, ensure that your hardware and supporting software requirements meet prerequisites for the fix pack. The lists of prerequisite products needed for IBM WebSphere Application Server are at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html. Then install the fix pack using the instructions in the README file that accompanies the fix pack downloadable files.

To regenerate the configuration, complete the following steps:

The launchClient environment does not support the use of embedded DataDirect (Defect PQ62617)

The WebSphere Application Server Java 2 Platform, Enterprise Edition (J2EE) Application client run time (launchClient) does not support the use of the embedded DataDirect database driver as a local client Java Database Connectivity (JDBC) resource. Attempting to do so results in a "License verification failed" error.

The DataDirect driver performs a license check to make sure you have a valid license to use the DataDirect drivers. A license key is provided by DataDirect and this key needs to be set as the on database connection objects using the oemID field. DataDirect has provided IBM a license key to be used by WebSphere Application Server run time when a database connection is created on the server. However, on the client, the J2EE specification requires a javax.sql.DataSource object to be returned to the client application instead of a database connection, as on the server. Therefore, WebSphere Application Server J2EE application client run time does not create or maintain database connection objects and cannot set the oemID license field. The client application code needs to create the connection object from the data source object returned by the application client run time and set the oemID field. IBM's agreement with DataDirect prohibits IBM from distributing the license key in a form that is usable by the client application in this situation. If the client application must access the database directly, then a client license needs to be acquired from DataDirect.

In general, WebSphere Application Server does not provide client database drivers. If your client application uses a database directly, you must provide the database drivers on the client machine. This could involve contacting your database vendor to acquire client database driver code and licenses.

Instead of accessing the database directly, it is recommended that your client application use an enterprise bean. Accessing a database through an enterprise bean eliminates the need to have database drivers on the client machine, since the database access is handled by the enterprise bean running on WebSphere Application Server.

Install compatibility library to start the DB2 installer (Defect 131527.RN)

If you issue the db2setup command to start the DB2 installer, and the compat-2001.5.29-0.s390.rpm package is not installed, the setup command fails with an error stating that the installer is unable to load the libstdc++-libc6.1-2.so.3 library.

To work around this problem, verify that compat-2001.5.29-0.s390.rpm package is installed. You can verify that this package is installed by issuing the following command:
rpm -qa | grep compat-2001.5.29-0.

If that package name is not returned as the output of the command, locate the rpm file on your base SuSE SLES 7.0 CD-ROMs and install it.

Configuring WebSphere Application Server data source for SQL Server / Type 4 Driver (Defect 133863.RN)

A. Before you install WebSphere Application Server, ensure that you have done the following:

  1. Install Microsoft SQL Server and the Datadirect-WebSphere Type 4 Driver, including Java Transaction API (JTA) driver zip files. Or, you can install Microsoft SQL Server and the Microsoft Type 4 Driver by executing the setup.exe program.
  2. Use the SQL Server to create a user, a database, and associate the user with that database.
  3. Install the SQL Server Java Database Connectivity (JDBC) XA stored procedures. The installation requires three steps:

B. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Single Server Edition.

  1. Start WebSphere Application Server and log in to the Advanced Single Server Edition administrative console.
  2. Perform the following steps to create JDBC Driver:
    1. In the navigation tree, click Resources > JDBC Drivers.
    2. Under JDBC Drivers, click New.
    3. Select the resource provider User-defined JDBC Driver from the drop-down list, and click Next.
    4. Under Properties, do the following:

        a. Type the location of the driver JAR files for the server class path.
        • For Datadirect-WebSphere Type 4 Driver on Windows platforms, use a semicolon (;) to separate the two paths. For example: D:\ConnectJDBC\lib\base.jar;D:\ConnectJDBC\lib\util.jar;D:\ConnectJDBC\lib\sqlserver.jar;D:\ConnectJDBC\spy\lib\spy.jar;
        • For Datadirect-WebSphere Type 4 Driver on UNIX platforms, use a colon (:) to separate the two paths.
        • For Microsoft Type 4 Driver on Windows platforms, use a semicolon (;) to separate the two paths. For example: D:\ConnectJDBC\lib\msbase.jar;D:\ConnectJDBC\lib\msutil.jar;D:\ConnectJDBC\lib\mssqlserver.jar
        • For Microsoft Type 4 Driver on UNIX platforms, use a colon (:) to separate the two paths.

        b. Type a name for the driver. The driver you specified is added to the WebSphere Application Server JDBC Drivers list.
        c. Type a description (optional).
        The implementation class:
        • For Datadirect-WebSphere Type 4 Driver, type com.ibm.websphere.jdbcx.sqlserver.SQLServerDataSource.
        • For Microsoft Type 4 Driver, type com.microsoft.jdbcx.sqlserver.SQLServerDataSource.

    5. Click OK.
  3. Click Save.
  4. Configure the data source for an MS SQL Server:
    1. In the navigation tree, click JDBC Drivers.
    2. Expand the category for the driver you just created, and select Data Sources.
    3. A list of data sources created with the driver (initially empty) displays on the right.
      4. Click New to create a new data source.
    4. Under Properties, do the following:

        a. Type a name for your data source. The name is used to identify your data source on the data sources list.
        b. Type a JNDI name for applications to look up your data source (for example, jdbc/myDataSource).
        c. Optionally, type a description and specify a category.
        d. Type the name of an existing MS SQL Server database to use for your data source.
        e. Type a valid user ID as the default ID for connecting to MS SQL Server.
        f. Type the default password for the chosen user ID.
        g. In the remaining fields, specify the connection pooling properties as you would for any other data source.
    5. Click Resource Properties
      • New serverName
        Use these values in the property sheet (leave the rest blank):

        Name:serverName
        Type: java.lang.String
        Value: servername

        Note: servername is the actual host name.

        Click OK on the Resource Properties: serverName panel.

      • New portNumber
        Use these values in the property sheet (leave the rest blank):

        Name: portNumber
        Type: java.lang.Integer
        Value:        port_number

        Note: port_number is the actual port number for the port number field. 1433 is the default portNumber of SQLSERVER.

        Click OK on the Resource Properties: portNumber panel.

      • New disable2Phase
        Use these values in the property sheet (leave the rest blank):

        Name: disable2Phase
        Type: java.lang.Boolean
        Value: true

        Click OK on the Resource Properties: disable2Phase panel.

    6. Click OK on the Data Sources panel to add your data source to the list.
    7. Click Save.
    8. Expand the Type 4 Driver entry you created. Select Data Sources and verify that your data source is in the list on the Data Sources panel.

C. Configure WebSphere Application Server Advanced Edition to use the SQL Server with Type 4 Driver as an administrative database.

  1. Install WebSphere Application Server Version 4.0.1 with DataDirect as database type and apply Fix Pack 5 to Version 4.0.1.
  2. Copy all of JDBC Driver JAR files to WebSphere Application Server library directory, for example, xcopy -R C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib C:\WebSphere\AppServer\lib.
  3. Check <WAS_HOME>\lib directory for the following JAR files:
  4. Update the admin.config file.

    5. Change value: com.ibm.ejs.sm.adminServer.dbportNumber = 1433 (default is "19996").

  5. Add one line at the end of the admin.config file: com.ibm.ejs.sm.adminServer.dbselectMethod=cursor.
  6. Update the initial_setup.config file:
    Change value:
  7. Start WebSphere Application Server and the administrative console.
  8. To run the sampleApp application successfully, make some changes on the Type 4 Driver data source:

D. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Edition.

  1. Start WebSphere Application Server and the administrative console.
  2. Complete the following steps to configure new JDBC provider under JDBC Provider Properties:

    a.Under the General tab:

    1. Type the name of JDBC provider, for example, myDriver.
    2. Type the implementation class:
      • For Datadirect-WebSphere Type 4 Driver, type com.ibm.websphere.jdbcx.sqlserver.SQLServerDataSource.
      • For Microsoft Type 4 Driver, type com.microsoft.jdbcx.sqlserver.SQLServerDataSource.
    b. Under the Nodes tab:
    1. Click Install New.
    2. Select a node in driver files.
    3. Type the JDBC driver file directory.
      • For Datadirect-WebSphere Type 4 Driver: type c:/WebSphere/AppServer/lib/base.jar;c:/WebSphere/AppServer/lib/ sqlserver.jar;c:/WebSphere/AppServer/lib/sqlserver.jarsutil.jar;c:/WebSphere/ AppServer/lib/spy.jar.
      • For Microsoft Type 4 Driver, type c:/WebSphere/AppServer/lib/msbase.jar;c:/WebSphere/AppServer/lib /mssqlserver.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar/msutil.jar.
      • Click OK.

  3. Complete the following steps to configure new data source under DataSource Properties:

    Under the General tab:
    a. Type the name of JDBC provider, for example, myDataSource.
    b. Type the JNDI name, for example, jdbc/myDataSource.
    c. Type the following custom properties:
    databaseName
    portNumber
    serverName
    user
    password
    For more information, refer to B. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Single Server Edition.
    d. Add selectMethod (its value is cursor) in Custom Properties.
    e. Test Connection. If a Test Connection Successfully message appears, the new data source creation is successful.
    f. Click OK.

Note: These configuration methods are applicable to ConnectJDBC 3.1 as a depository connection.

Tune the application server or client application when RMI-IIOP client hangs (Defect ASV404)

If you experience any RMI-IIOP client or enterprise application server hangs during an operation, add the following two CORBA properties to tune your application server or client application. 

com.ibm.CORBA.sendTriesCount=n  // n is an integer number from 1 to JAVA Max allowed integer number
                                // default value of n is 5
                                // n means n number of attempts 
                                // by setting this to 3, it will make maximum of 3 attempts on each request.
                                // if all n attempts are failed on that particular request, error or exception
                                // will be thrown. 

com.ibm.CORBA.sendTriesDelay=n  // n is an integer number from 0 to JAVA Max allowed integer number
                                // default value of n is 0
                                // n means n is millisecond
                                // by setting this to 1000, it will make 1 second sleep time in between
                                // each attempt

Note: By using the above two properties, you might experience some minor performance impact. However, this performance impact is inevitable because object request broker (ORB) uses these properties to work around the intermittent input or output exception thrown from the client side IBM Software Development Kit; furthermore, these properties are different from the com.ibm.CORBA.requestRetriesCount and com.ibm.CORBA.requestRetriesDelay properties. You might need to use all four of these properties to tune you client application and application server.

Enabling in-process transaction logging in WebSphere Application Server Advanced Edition (Defect 144808)

You can improve the throughput of WebSphere Application Server Advanced Edition that make heavy use of two-phase commitment transactions. Configure the application server to use in-process transaction logging rather than logging through the administrative server, which is the default. To enable in-process transaction logging, set the system property WAS_TRANSACTION_LOGSPEC for the particular application server Java virtual machine (JVM) settings, set the value of the system property to a pair of files separated by a comma. These two files are used for the server transaction logs, for example, /WebSphere/AppServer/tranlog/server1log1,/WebSphere/AppServer/tranlog/server1log2.

AIX

Informix IDS_2000 has a load libc_r.a problem on an AIX 4.3.3 platform (108882.RN)

After installing, Informix IDS_2000 has a load libc_r.a problem on an AIX 4.3.3 platform even if the software installed without problems. If you run any Informix command, such as oninit -ivy, onstat -l, or onmode, you receive error messages.

To avoid receiving error messages, do one of the following:

AIX

Upgrade Netscape browser after applying APAR IY19277 on an AIX platform (108934)

After you install WebSphere Application Server and all of its prerequisites on an AIX platform, Netscape Communicator 4.73 (or later) might not start. The following error message indicates this failure:

Could not load program /afs/torolab.ibm.com/common/progs/netscape47/netscape_aix4:
Symbol resolution failed for /usr/lib/libpthreads.a(shr.o) because:
        Symbol thread_unlock (number 121) is not exported from dependent
          module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o).
        Symbol thread_waitlock (number 122) is not exported from dependent
          module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o).

This error occurs because Netscape Communicator V4 uses a private copy of libc.a which must stay synchronized with other shared AIX libraries. If AIX updates are applied to your system, update the copy of libc.a used by Netscape Communicator.

You can download the updated version of libc.a and replace the one in the Netscape installation directory from the following URL:

ftp://aix.software.ibm.com/aix/efixes/netscape/aix433_libc/

Read and follow the instructions (in the README file) for downloading and replacing the libc.a in your existing Netscape installation.

If you run Netscape from AFS or DFS locations, you might not do it yourself because of lack of write permission to the Netscape directory. If this is the case, contact your AFS or DFS administrator.

Alternatively, there is a new version (4.76i) of Netscape available for download that corrects this problem. You can download and install this version on your local machine. The location for the download is:

ftp://aix.software.ibm.com/aix/efixes/netscape/aix43_installp/

Selecting the pass-by-reference option on the Object Request Broker panel (Defect 127745.34.1)

Section 18.3.2 of the Sun Microsystems Enterprise JavaBeans Specification, V 1.1 states: "The enterprise bean's home and remote interfaces are remote interfaces for Java RMI. The Container must ensure the semantics for passing arguments conform to Java RMI. Non-remote objects must be passed by value. Specifically, the EJB Container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same Java virtual machine (JVM). Doing so could result in the multiple beans sharing the state of a Java object, which would break the semantics of the enterprise bean."

This information concludes that the use of the pass-by-reference option for enterprise beans is a willful violation of the EJB specification. In addition, there are coding considerations that must be kept in mind if this option is chosen. Object references passed to EJB methods or EJB home methods are not copied and therefore might be subject to corruption. Consider the following example: 

Iterator iterator = collection.iterator();                            
 MyPrimaryKey pk = new MyPrimaryKey();                                           
 while (iterator.hasNext()) {                                    
 pk.id = (String) iterator.next();                             
 MyEJB myEJB = myEJBHome.findByPrimaryKey(pk);                             
 }

In this code sample, a reference to the same MyPrimaryKey object is passed into WebSphere Application Server, each time with a different ID value. If this code is run with the pass-by-reference option enabled, it causes a problem within WebSphere Application Server because multiple enterprise beans are referencing the same MyPrimaryKey object. To avoid this problem in WebSphere Application Server Version 4.0.5, when running in pass-by-reference mode, you must also set the system property com.ibm.websphere.ejbcontainer.allowPrimaryKeyMutation to true. This causes the EJB container to make a local copy of the PrimaryKey object. However, a small portion of the performance advantage of setting the pass-by-reference option is lost.

This is one example of problems that might occur as a result of using the pass-by-reference option. As a general rule, any application code that passes an object reference as a parameter to an EJB method or EJB home method must be scrutinized to determine if passing that object reference causes integrity or other problems.

An IBM Software Development Kit must be present on the machine before installing Fix Pack (Defect 139871)

When you only have a plug-in and a Web server installed on your machine, install an IBM Software Development Kit on your machine in which the fix pack is installed. When WebSphere Application Server Version 4.0 installs the plug-in, it does install the IBM Software Development Kit. The fix pack installation uses the Java code, therefore an IBM Software Development Kit must be present.

Upgrade IBM Software Development Kit if upgrading WebSphere Application Server (127427.RN)

If you select to upgrade WebSphere Application Server when you install Fix Pack 4, you must also upgrade your IBM Software Development Kit level. Select Yes to upgrade the IBM Software Development Kit level.

Interrupted installation could cause reinstallation and uninstallation to fail (Defect 125711.RN)

If you interrupt the installation of WebSphere Application Server Fix Pack 5 while the files are backing up, the backup_jar file might be corrupted, which causes the uninstallation to fail. If you continue the installation, pay particular attention to where the backup JAR files are stored. Although you can specify your own directory, the two most common default locations are in the <was_root> directory, and the directory where you are running the installation script. If you are installing the WebSphere Application Server update, the default directory is <was_root>. If you are not installing the update, the default directory is in the directory that contains the installation script. Replace the corrupted backup JAR file with the JAR file from that directory. If you need to back out or uninstall the fix pack, ensure that valid backup JAR files exist in one directory, based on the components that you wish to back out.

Note: If you run the uninstall_ptf_5.sh or uninstall_ptf_5.bat script from the <was_root> directory, the uninstallation defaults to using whatever the backup JAR files it finds there unless you direct it to look someplace else. An example of what the backup JAR files are called ihs_ptf_5_backup.jar, jdk_ptf_5_backup.jar, J2C_ptf_5_backup.jar, and was40_ae_ptf_5_backup.jar.

See the README file for detailed installation instructions.

Information about applying CSD3 to MQSeries 5.2 (Defect 116061.RN)

CSD3 should be applied to MQSeries 5.2. If the MQSeries queue manager halts while the administrative server of WebSphere Application Server is running, you can restart the MQSeries queue manager without rebooting the system. However, it could require that the administrative server to be cycled.

Setting up SQL server for use as the administrative repository (114271)

To use SQL Server as the WebSphere Application Server administrative repository, ensure that you have the WebSphere Application Server database in your SQL Server. To create the Enterprise Manager in SQL server, complete the following steps:

  1. Go to the Enterprise Manager in SQL server and create a user EJSADMIN for the WebSphere Application Server database with password EJSADMIN and database administrator privileges.
  2. Create a user EJB on this database with password EJB and administrative privileges. The default server in WebSphere Application Server uses these users.

Note: The above information also applies to the InfoCenter articles "6.6.46: Administering WebSphere administrative servers" and "6.6.14.5: Additional administrative tasks for specific databases."

Informix and remote database option selected (108664.RN)

During installation, if you select Informix as the backend database and also select the remote database option, the installation program is able to configure the Informix database with the remote database option. To manually configure Informix, set the following property in the admin.config file after the installation completes: 

com.ibm.ejs.sm.adminServer.dbifxIFXHOST=remote_host_name

Applying fix PQ51387 to use Java Naming and Directory Interface client on Version 3.5.5 or 3.5.4 (108555)

If you want to use the Java Naming and Directory Interface (JNDI) client on WebSphere Application Server Version 3.5.3 or Version 3.5.4 to access a Version 4.0.x name server, you must apply fix PQ51387 to your Version 3.5.x product. This fix is available at http://www.ibm.com/software/webservers/appserv/support.html.

Follow the instructions in the README to update the ujc.jar file and ns.jar file on WebSphere Application Server Version 3.5.x.

Installing WebSphere Application Server Advanced Edition into the same directory as WebSphere Application Server Advanced Single Server Edition (110218.RN, 110219.RN)

If the WebSphere Application Server Advanced Edition is installed and migrated into the same directory as a previous Advanced Single Server Edition installation, the Advanced Single Server Edition installation is no longer a valid installation. Do not run the uninstallation program because it uninstalls the new Advanced Edition installation.

Further, if the WebSphere Application Server Advanced Edition is installed and migrated into the same directory as a previous Advanced Single Server Edition installation, the Advanced Single Server Edition property files are lost. If you plan on manually migrating any of your property files, back up the Advanced Single Server Edition property files before installing the Advanced Edition.

Authentication fails using Lightweight Third Party Authentication with Lightweight Directory Access Protocol server cluster (Defect 119573)

If the authentication fails or is very slow, when using Lightweight Third Party Authentication (LTPA) and Lightweight Directory Access Protocol (LDAP) cluster, perform the following two configurations or choose one of them:

Note: An LDAP cluster is defined as multiple LDAP servers which appear as a single LDAP server due to the use of a network dispatcher or Internet Protocol (IP) sprayer.

Installation over network takes longer to run than using local resources (Defect 114034.RN)

Installation of a fix pack that makes use of network resources can take substantially longer to execute than one which uses local resources.

For the best speed, make sure that the following files and directories are available through local resources:

See the usage and help text for directions on how to set these values. Usage information is available for both the installation and uninstallation scripts. Use the -usage command line option to display usage information. Use the -help command line option to display comprehensive help.

Matching the WebSphere Application Server element type tag sequence (Defect 120691.RN)

Applications that ran on WebSphere Application Server prior to Version 4.0.3 did not check for the Java 2 Platform, Enterprise Edition (J2EE) tag sequence standard (they might not work or might require changes) because now there is tag sequence validation and the standard is supported by the current release.

The WebSphere Application Server element type tag sequence must match with the following requirements: name, tag class, teiclass, body content, information, and attribute*.

Applications written using the JavaServer Pages (JSP) element tag like name, tag class, teiclass, body content, information, attribute*. for WebSphere Application Server Version 4.0.3 and later need to follow the standards defined in the URL http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd.

Choose Yes to upgrade WebSphere Application Server during the fix pack installation if you have a plug-in only installation (Defect 139879)

During the installation of the fix pack, you must choose Yes to upgrade WebSphere Application Server if you have a plug-in only installation on that machine. The new plug-in files are installed when updating the WebSphere Application Server. Extra files might be installed under the <WAS_UPDATE_HOME> directory. However, they do not cause any problems.

B. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Single Server Edition.

  1. Start WebSphere Application Server and log in to the Advanced Single Server Edition administrative console.
  2. Perform the following steps to create JDBC Driver:
    1. In the navigation tree, click Resources > JDBC Drivers.
    2. Under JDBC Drivers, click New.
    3. Select the resource provider User-defined JDBC Driver from the drop-down list, and click Next.
    4. Under Properties, do the following:

        a. Type the location of the driver JAR files for the server class path.
        • For Datadirect-WebSphere Type 4 Driver on Windows platforms, use a semicolon (;) to separate the two paths. For example: D:\ConnectJDBC\lib\base.jar;D:\ConnectJDBC\lib\util.jar;D:\ConnectJDBC\lib\sqlserver.jar;D:\ConnectJDBC\spy\lib\spy.jar;
        • For Datadirect-WebSphere Type 4 Driver on UNIX platforms, use a colon (:) to separate the two paths.
        • For Microsoft Type 4 Driver on Windows platforms, use a semicolon (;) to separate the two paths. For example: D:\ConnectJDBC\lib\msbase.jar;D:\ConnectJDBC\lib\msutil.jar;D:\ConnectJDBC\lib\mssqlserver.jar
        • For Microsoft Type 4 Driver on UNIX platforms, use a colon (:) to separate the two paths.

        b. Type a name for the driver. The driver you specified is added to the WebSphere Application Server JDBC Drivers list.
        c. Type a description (optional).
        The implementation class:
        • For Datadirect-WebSphere Type 4 Driver, type com.ibm.websphere.jdbcx.sqlserver.SQLServerDataSource.
        • For Microsoft Type 4 Driver, type com.microsoft.jdbcx.sqlserver.SQLServerDataSource.

    5. Click OK.
  3. Click Save.
  4. Configure the data source for an MS SQL Server:
    1. In the navigation tree, click JDBC Drivers.
    2. Expand the category for the driver you just created, and select Data Sources.
    3. A list of data sources created with the driver (initially empty) displays on the right.
      4. Click New to create a new data source.
    4. Under Properties, do the following:

        a. Type a name for your data source. The name is used to identify your data source on the data sources list.
        b. Type a JNDI name for applications to look up your data source (for example, jdbc/myDataSource).
        c. Optionally, type a description and specify a category.
        d. Type the name of an existing MS SQL Server database to use for your data source.
        e. Type a valid user ID as the default ID for connecting to MS SQL Server.
        f. Type the default password for the chosen user ID.
        g. In the remaining fields, specify the connection pooling properties as you would for any other data source.
    5. Click Resource Properties
      • New serverName
        Use these values in the property sheet (leave the rest blank):

        Name:serverName
        Type: java.lang.String
        Value: servername

        Note: servername is the actual host name.

        Click OK on the Resource Properties: serverName panel.

      • New portNumber
        Use these values in the property sheet (leave the rest blank):

        Name: portNumber
        Type: java.lang.Integer
        Value:        port_number

        Note: port_number is the actual port number for the port number field. 1433 is the default portNumber of SQLSERVER.

        Click OK on the Resource Properties: portNumber panel.

      • New disable2Phase
        Use these values in the property sheet (leave the rest blank):

        Name: disable2Phase
        Type: java.lang.Boolean
        Value: true

        Click OK on the Resource Properties: disable2Phase panel.

    6. Click OK on the Data Sources panel to add your data source to the list.
    7. Click Save.
    8. Expand the Type 4 Driver entry you created. Select Data Sources and verify that your data source is in the list on the Data Sources panel.

C. Configure WebSphere Application Server Advanced Edition to use the SQL Server with Type 4 Driver as an administrative database.

  1. Install WebSphere Application Server Version 4.0.1 with DataDirect as database type and apply Fix Pack 5 to Version 4.0.1.
  2. Copy all of JDBC Driver JAR files to WebSphere Application Server library directory, for example, xcopy -R C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib C:\WebSphere\AppServer\lib.
  3. Check <WAS_HOME>\lib directory for the following JAR files:
  4. Update the admin.config file.

    5. Change value: com.ibm.ejs.sm.adminServer.dbportNumber = 1433 (default is "19996").

  5. Add one line at the end of the admin.config file: com.ibm.ejs.sm.adminServer.dbselectMethod=cursor.
  6. Update the initial_setup.config file:
    Change value:
  7. Start WebSphere Application Server and the administrative console.
  8. To run the sampleApp application successfully, make some changes on the Type 4 Driver data source:

D. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Edition.

  1. Start WebSphere Application Server and the administrative console.
  2. Complete the following steps to configure new JDBC provider under JDBC Provider Properties:

    a.Under the General tab:

    1. Type the name of JDBC provider, for example, myDriver.
    2. Type the implementation class:
      • For Datadirect-WebSphere Type 4 Driver, type com.ibm.websphere.jdbcx.sqlserver.SQLServerDataSource.
      • For Microsoft Type 4 Driver, type com.microsoft.jdbcx.sqlserver.SQLServerDataSource.
    b. Under the Nodes tab:
    1. Click Install New.
    2. Select a node in driver files.
    3. Type the JDBC driver file directory.
      • For Datadirect-WebSphere Type 4 Driver: type c:/WebSphere/AppServer/lib/base.jar;c:/WebSphere/AppServer/lib/ sqlserver.jar;c:/WebSphere/AppServer/lib/sqlserver.jarsutil.jar;c:/WebSphere/ AppServer/lib/spy.jar.
      • For Microsoft Type 4 Driver, type c:/WebSphere/AppServer/lib/msbase.jar;c:/WebSphere/AppServer/lib /mssqlserver.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar/msutil.jar.
      • Click OK.

  3. Complete the following steps to configure new data source under DataSource Properties:

    Under the General tab:
    a. Type the name of JDBC provider, for example, myDataSource.
    b. Type the JNDI name, for example, jdbc/myDataSource.
    c. Type the following custom properties:
    databaseName
    portNumber
    serverName
    user
    password
    For more information, refer to B. Configuring the Type 4 Driver data source for MS SQL Server for the WebSphere Application Server Advanced Single Server Edition.
    d. Add selectMethod (its value is cursor) in Custom Properties.
    e. Test Connection. If a Test Connection Successfully message appears, the new data source creation is successful.
    f. Click OK.

Note: These configuration methods are applicable to ConnectJDBC 3.1 as a depository connection.

Remove directories when the installedApps directory is a symbolic link (Defect PQ63523.RN)

Some installations use a symbolic link for the installed enterprise application directory, <WAS_ROOT>/installedApps. A directive is added to specify that during the removal of an application, symbolic links should be followed when recursively deleting files. The new directive is com.ibm.ejs.adminServer.recursiveDeleteSymLink=true.

Note: Before activating this property, make sure that these links do not point to the directories that could cause harm to your system if they were removed when you use symbolic links for your enterprise application directories.

Using WebSphere Application Server Version 4.0.4 administrative client to administer a Version 4.0.5 administrative server is the only supported interoperability configuration (Defect 148110.1)

The only supported interoperability configuration is using the WebSphere Application Server Version 4.0.4 administrative client to administer a Version 4.0.5 administrative server. Under a multinode WebSphere environment and the EAR file deployment, some effects of mixing client and server with different versions include the following:

The primary reason for this support is the incremental migration associated with the large scale customers. This incremental migration deals with the situation where a fix pack level administrative client talks to another fix pack level administrative server.

The recommended configuration remains using a WebSphere Application Server Version 4.0.5 for both the administrative client and administrative server.

Applying a new system property in the admin.config file to configure the generic servers NodeStartState (Defect PQ65491.RN)

You can apply a new system property in the admin.config file to configure the Generic Servers NodeStartState. The new property is com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = [Current|Running|Stopped].

To apply the new property, add the following text to the admin.config file:
# NodeStartState of generic servers: [Current|Running|Stopped]
com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = (NodeStartState)

NodeStartState options:
Current: Each generic server is in its last state prior to Node restarts.
Running: Each generic server is in Running state regardless of last state.
Stopped: Each generic server is in Stopped state regardless of last state.

The new property applies to generic servers as a whole. The property specified affects every generic server created on the Node. The property does not affect generic servers created on other Nodes.

Using the -outputFile option to regenerate the plugin-cfg.xml file (Defect PQ68756.RN)

You can use the same configuration option for regenerating the plug-in configuration that the command line script GenPluginCfg.[sh/bat] offers when generating the plug-in through the Web-based administrative console provided with WebSphere Application Server Advanced Single Server Edition.

The following is the list of the parameters provided by the command line utility: 

IBM WebSphere Application Server Advanced Single Server Edition, Release 4.0
Web Server Plug-in Configuration Generator
Copyright IBM Corp., 1997-2001

Required Argument Missing: -configFile
Usage: Use one of the following commands

        java com.ibm.websphere.plugincfg.tool.SEGeneratePluginCfg
            -configFile <server configuration file>
           [-outputFile  <directory to write the config file to>]
           [-nodeName <name of node>]
           [-serverName <name of server>]

The -outputFile option allows you with multiple instances of WebSphere Application Server to dictate which directory to output the plugin-cfg.xml file. This currently does not exist when regenerating the plugin-cfg.xml file through the Web-based administrative console.

To allow this behavior, WebSphere Application Server provides a new PathMapEntry that is referenced when regenerating the plug-in through the browser. See the <WAS_ROOT> /config/server-cfg.xml file for the standard installation. This change varies based upon which configuration installation you are using. The following is an example of the new entry PLUGIN_CFG_ROOT: 

<entries xmi:id='PathMapEntry_7' symbolicName='PLUGIN_CFG_ROOT' path='C:\temp' 
description='The filesystem path to write the plugin-cfg.xml'/>

HP-UX

Manually set SHLIB_PATH variable on some installations of iPlanet Web server (108778.RN)

On some installations of iPlanet Web server on an HP-UX machine, it is necessary to manually set the SHLIB_PATH variable to /usr/lib before starting the iPlanet Web server with a plug-in configured for Secure Sockets Layer (SSL). For example, in the korn shell, issue the following command before invoking the command to start the iPlanet Web server.

export SHLIB_PATH=/usr/lib UNIX

Enabling a new function to do additional monitoring of the nanny and administrative server processes (Defect 154124.RN)

If you are on a UNIX platform, as an option, you can enable the startupServer.sh script to do additional monitoring of the nanny and administrative server processes. To enable this function, add the following property to the admin.config file:

com.ibm.ejs.sm.adminServer.forceReconnect=true

Setting the property activates the additional monitoring. Setting the property to any value (not just true) also causes the administrative server to always attempt to connect to the running application servers instead of always restarting them. When this property is set to true, the startupServer.sh script does the following:

  1. Checks to see if another copy of the startupServer.sh script is running. It prints an error message and ends if another copy is already running, otherwise it continues.
  2. Checks once every five seconds to see if the nanny process is still running.
  3. If the nanny process is not running or stops running for some reasons, it checks to see if the administrative server process is running, again checking once every five seconds.
  4. If the administrative server process stops running the startupServer.sh script, restarts the nanny process. The nanny process launches the administrative server.
  5. The administrative server reconnects to each of the running application servers for any non-null setting of the property com.ibm.ejs.sm.adminServer.forceReconnect.

If this property is not set, the administrative server only tries to reconnect to running application servers when it is restarted by the nanny process, or if it is started by the adminserver.sh script.

Do not set the com.ibm.ejs.sm.adminServer.forceReconnect property if you are running multiple instances of WebSphere Application Server on a single system.

Note: This new function is not available for HP-UX 11.

UNIX

Log file does not open after running the wscp command on UNIX platforms (110363.RN)

If you installed the administrative component only, edit the following file and replace $(WASROOT) with your WebSphere Application Server home directory.

install_root/properties/sas.client.props and find the following line in the file:

com.ibm.CORBA.securityTraceOutput=$(WASROOT)/logs/sas.client.log

AIX

The files on AIX are installed with checksum errors (XPQ35815.RN)

If you install WebSphere Application Server on an AIX machine, and issue the installp command, you receive errors for some of the installed files. These errors do not affect the installation, running, or uninstallation of the product.

HP-UX

Using Sybase as a repository on an HP machine (Defect 122525.RN)

Using Sybase as a repository is not supported in WebSphere Application Server Version 4.0.1, but is supported in WebSphere Application Server Version 4.0.5. Modify several files before attempting to start WebSphere Application Server using a Sybase repository.

To work around this problem, perform the following steps:

  1. Before starting the installation of WebSphere Application Server, create the Sybase database as the repository.
  2. During installation of WebSphere Application Server Version 4.0.1, you do not have a Sybase selection to choose from during database selection. Therefore, you need to select another database, for example, DB2.

    Continue on with the installation.

  3. After installing WebSphere Application Server Version 4.0.1, install Fix Pack 5 before attempting to start the administrative server. After installing Fix Pack 5 but before trying to start the administrative server, modify the following three files in the <was_root>/bin directory: 
    admin.config 
setupCmdLine.sh
startupServer.sh.

    and one file in the <was_root>/properties directory: 

    initial_setup.config

    Following these instructions to modify the files:

    a. The admin.config file

    Go to the very end of the line that starts with com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs= and change the directory for the Java Database Connectivity (JDBC) library. Right after /opt/WebSphere/AppServer/lib/ext is the JDBC library that WebSphere Application Server uses to find the classes it needs. Specify the Sybase directory whichever directory is specified, for example, /opt/sybase12/jConnect-5_2/classes/jconn2.jar.

    For the line that starts with com.ibm.ejs.sm.adminServer.dbdataSourceClassName=, you need to specify com.sybase.jdbc2.jdbc.SybConnectionPoolDataSource. Note that this information is case sensitive. If you selected DB2 as your database, the com in the class name would be in upper case. Make sure that you change it to lower case for Sybase.

    For com.ibm.ejs.sm.adminServer.dbserverName, select the host where the database is installed.

    For com.ibm.ejs.sm.adminServer.dbportNumber, choose the port for the database. The default for Sybase is 4100.

    b. The setupCmdLine.sh file

    Change the following environment variables to: 

    DBDRIVER_JARS=/opt/sybase12/jConnect-5_2/classes/jconn2.jar
DBDRIVER_PATH=/opt/sybase12
DBTYPE=Sybase
DB_INSTANCE_HOME=/opt/sybase12

    c. The startupServer.sh file

    Add the following line to the section where the script checks to see what database type is specified.

    elif [ "${DB_TYPE}" = "Sybase"]

    then 

    {
DB_CLASSPATH=$DB_INSTANCE_HOME/jConnect-5_2/classes/jconn2.jar
}

    d. The initial_setup.config file

    In this file, there are several lines that start with <config-file>, several of which are commented out because they are database specific. Comment out the line that is specific to the database type that you installed with and uncomment the line for Sybase. The line for Sybase is similar to the following: <config-file>/opt/WebSphere/AppServer/bin/ImportSamplesConfigSybase.xml</config-file>

    The rest of the XML is similar to the following: 

    <variable>
   <name>XMLConfigDTDLocation</name>
   <value>/opt/WebSphere/AppServer/bin</value>
</variable>
<variable>
   <name>serverName</name>
   <value>Default Server</value>
</variable>
<variable>
   <name>dbPrefix</name>
   <value></value>
</variable>
<variable>
   <name>jdbcDriver</name>
   </opt/sybase12/jconnect-5_2/classes/jconn2.jar>
</variable>
<variable>
   <name>repositoryDBName</name>
   <value>WAS</value>
</variable>
<variable>
   <name>pslash</name>
   <value>$(PSLASH)</value>
</variable>
  4. Start the administrative server.

If you receive an error similar to: 

An error occurred converting UNICODE to the charset used by the server.  Error 
Message: java.io.CharConversionException: java.io.Unsupported Encoding Exception : 
hp-roman8

You need to set the charset that you want WebSphere Application Server to use. Modify the <install_root>/bin/admin.config directory and add com.ibm.ejs.sm.adminServer.dbconnectionProperties=CHARSET=utf8; CHARSET_CONVERTER_CLASS=com.sybase.jdbc2.utils.TruncationConverter; where utf8 is the character set that you want to specify. The setting should all appear on one line, not broken into two lines as shown here.

HP-UX

DB2 does not work properly unless the KC_PARAM_DEFAULT parameter is 65535 (114435, 116016.RN)

As noted in the Supporting Software database for WebSphere Application Server at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html, an HP-UX 11.11 (or 11i) system needs the patches (file sets) HWEnable11i_11.11.depot and PHKL_25368 to run DB2 properly with WebSphere Application Server. However, even with the file sets installed, the value of the msgmax kernel parameter might revert back to its original value of 8192 after a system reboot. When this happens, DB2 does not work properly. The value must be 65535.

HP-UX

Secure Sockets Layer-enabled plug-in support (Defect 105995.RN.1, 150859)

The Secure Sockets Layer (SSL) enabled plug-in is not supported on HP-UX with the Apache HTTP Server product.

Other than this combination, the SSL enabled plug-in is supported on the AIX, HP, Solaris Operating Environment, Windows NT, Windows 2000, and Linux platforms for use with the IBM HTTP Server, Apache HTTP Server, Microsoft IIS, Lotus Domino, and iPlanet Web server.

Linux

After enabling Secure Sockets Layer with Apache HTTP Server plug-in on RedHat 7.1, Apache HTTP Server does not start (105196, 105196.RN)

When running Apache HTTP Server on RedHat 7.1 Linux systems with the plug-in configured for Secure Sockets Layer (SSL), before starting Apache you must set the LD_PRELOAD environment variable to the following value:

/usr/lib/libstdc++-libc6.1-1.so.2

For example, if you are using the korn shell, you enter the following before starting Apache HTTP Server:

export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2

Linux

Set the DB2 database on a remote machine when using the Trade 2 application (132820.RN)

Due to the limitations of the Linux kernel, create the application server database on a remote database server to avoid the out of memory errors that are generated in the stderr.log file when using business applications. (For example, Trade 2 Application with DB2.) If possible, create the WebSphere Application Server administrative database on a remote database server to facilitate a better long run environment.

Perform additional configuration steps to ensure DB2 is working properly and can connect to the trade application on the WebSphere Application Server. For instructions on how to use a database remotely, refer to WebSphere Application Server Version 4.0 InfoCenter article: Configuring the database manager to use TCP/IP to connect to WebSphere remotely and article: Configuring DB2 UDB on Linux.

Linux

Installing WebSphere Application Server Advanced Edition Version 4.0.x on a German SuSE Linux 7.3 platform (Defect 153452.RL)

When you install the WebSphere Application Server Advanced Edition Version 4.0.x on the German SuSE Linux 7.3 platform following the Choose Location panel, the installation wizard displays a message "datei nicht" and the installation cannot continue.

To work through this problem, install WebSphere Application Server Advanced Edition Version 4.0.x using the English locale instead of the German one. Once the installation is completed, change the locale to the German locale by issuing the command export LC_ALL=de_DE and export LANG=de_DE.

Linux

The message broker never completes starting for the WebSphere Application Server MQSeries SuSE V7.2 on a Linux platform (Defect 116467.RN)

The message broker never completes starting for the WebSphere Application Server MQSeries SuSE V7.2 on a Linux platform. When issuing the strmqbrk -m <Queue Manager> command, it never completes. Also, the command cannot be interrupted with CRL-C. If you check the status of the message broker with the dspmqbrk command, the result is similar to: 

 "MQSeries message broker for queue manager <Queue Manager> starting."

Linux SuSE 7.2 by default does not have the group ID nobody which is required by MQSeries. If you experience the problem as described, halt all MQSeries processes and create the group ID nobody. You are able to start the message broker.

Linux

Configuring Netscape Version 4.7.6 on SuSE (104266)

If you install WebSphere Application Server Advanced Single Server Edition with SuSE Version 7.1 and Netscape Version 4.7.6, you must change the following Netscape configuration values for the tree view on the left side of the administrative console to display properly:

  1. Start your Netscape browser.
  2. Select Edit > Preferences.
  3. Select Advanced, and then select the Enable Java and Enable JavaScript check boxes.
  4. Click OK.
  5. Start the administrative console from the URL: http://your_machine_name:9090/admin.

Linux

After enabling Secure Sockets Layer with Apache HTTP Server plug-in on RedHat 7.1, Apache HTTP Server does not start (105196, 105196.RN)

When running Apache HTTP Server on RedHat 7.1 Linux systems with the plug-in configured for Secure Sockets Layer (SSL), before starting Apache you must set the LD_PRELOAD environment variable to the following value:

/usr/lib/libstdc++-libc6.1-1.so.2

For example, if you are using the korn shell, you enter the following before starting Apache HTTP Server:

export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2

Linux

Oracle 8i lacks the Java Database Connectivity 2.0 driver classes12.zip (115823, 115823.RN)

The Oracle 8i distribution does not provide the Java Database Connectivity (JDBC) 2.0 driver file classes12.zip for Linux platforms. As a workaround, download the Solaris classes12.zip file from the Oracle Web site:

  1. Go to http://otn.oracle.com/software/tech/java/sqlj_jdbc/content.html. You might need to register on the Oracle Web site before you can download from the Oracle Web site.
  2. Under Oracle JDBC Drivers and Download the drivers Solaris, click the link Oracle8i 8.1.7.1 (Patch) JDBC Drivers for use with IBM Software Development Kit 1.2.x for Solaris.
  3. Read and then accept the license terms.
  4. Under Oracle8i 8.1.7.1 JDBC Drivers for use with IBM Software Development Kit 1.2.x, click the link JDBC-Thin, 100% Java and download the driver file.

Note: You can use the Java thin driver only and any attempts to use the OCI (thick) driver result in errors. For more information on the problem, contact Oracle Technical Support.

Linux

Communication problems between Linux nodes (Defect 148581)

On some Linux installations, WebSphere Application Server Version 4.0.x might have difficulty communicating between nodes. In particular, the difficult communicating between nodes affects the ability of the administrative console to control the remote WebSphere administrative servers.

The cause is due to the way some Linux distributions configure the /etc/hosts file to map the host name to the loopback port instead of the external Internet Protocol (IP) address.

If you encounter communication problems between nodes, update the /etc/hosts file to map the host name to the proper external IP address, for example: 

127.0.0.1       localhost  
9.x.x.x  yourhostname.yourdomain    yourhostname

Linux

Updating the values of kernels and glibc when applying WebSphere Application Server Version 4.0.5 on RedHat (Defect 119386.RN)

Due to a Linux kernel defect in kernels less than 2.4.10, the floating stack support in the IBM Software Development Kit does not work correctly on an SMP machine. To apply WebSphere Application Server Version 4.0.5 on an SMP machine, the kernel needs to be >= 2.4.10 and glibc needs to be = 2.2.4. Please check with your distribution provider for kernel and glibc upgrades.

In the case of RedHat, the user can set the environment variable LD_ASSUME_KERNAL=2.2.5 by exporting LD_ASSUME_KERNEL=2.2.5. That variable enables a modification made by RedHat to disable floating stack support and allows the IBM Software Development Kit to work to default to a non-floating stack mode which will work on pre 2.4.10 kernels. Note: Setting that variable does not make the programs assume they are running on a 2.2 kernel. It merely disables the floating stack features.

Uniprocessor machines are unaffected by this kernel defect.

Linux

Using the install.sh script on SuSE SLES 8 (Defect 161398)

Before installing WebSphere Application Server Advanced Edition Single Server, Version 4.0.6 on a SuSE SLES V8 Linux platform, comment out this line in the install.sh command script: 

#export LD_ASSUME_KERNEL=2.2.5

Commenting out this line lets the installation continue without generating this error during product installation: 

/home/Build/AEs/java/jre/bin/exe/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

Commenting out the line also prevents this error from appearing when using the fix pack installer: 

error while loading shared libraries: libpthread.so.2: cannot open shared object file: No such file or directory

Solaris Operating Environment

Minimizing installation window causes failures (Defect 121011)

When installing WebSphere Application Server V4.0 , if you minimize the installation window and again maximize it, the installation option panel gets hidden behind Installation Window. This is a known problem with motif on Solaris Operating Environment and IBM Software Development Kit window tooling.

If installation window is minimized, resize it or click Alt + F3 upon restoration to view the Install Option panel again.

Solaris Operating Environment

Exception returned at startup on the Solaris Operating Environment 2.8 with Domino Web Server and the plug-in configured for Secure Sockets Layer (106012.RN)

On Solaris Operating Environment 2.8 systems running the Domino Web Server with the plug-in configured for Secure Sockets Layer (SSL), the server has an exception at startup. This results from some incompatibilities with Domino and C++ code.

Solaris Operating Environment

Installing DataDirect SequeLink server on the Solaris Operating Environment (109652)

The install.sh script from the DataDirect SequeLink Server 5.1 CD-ROM for the Solaris Operating Environment systems contains the statement which NISCAT, which could cause the script to fail for some systems.

This script assumes that this module is available on every Solaris Operating Environment system. If you run the install.sh script and it fails on this command, remove the command and the DataDirect SequeLink Server should install correctly.

Any interim fixes that you applied since the last fix pack are automatically uninstalled before the installation of the current fix pack (153003.RN)

For Fix Pack 4.0.6 and later, any interim fixes that you applied since the last fix pack are automatically uninstalled before the installation of the current fix pack. This automatic uninstall helps ensure that the files are fully tested. This functionality is needed because if an interim fix is not uninstalled before you install the fix pack, then the fix pack can overwrite some of the files in the fix. This overwrite results in code that is unstable.

Only the fixes that you applied since the last fix pack installation are uninstalled.

Here is an example of the events that occur before installing the current fix pack:

This fix pack uninstalls interim fix PQ00002 and PQ00003 because they were installed after Fix Pack 4.0.5.

Only the interim fixes that were installed after the previous fix pack are removed.

The same sequence occurs for the fix pack uninstallation as well.

Windows 2000
Windows NT

Cannot install WebSphere Application Server with iPlanet 6.0.1 (Defect 132342.RN)

You cannot completely install WebSphere Application Server Version 4.0.1 with iPlanet 6.0.1.

Using the following steps to work around this problem:

  1. Install WebSphere Application Server Version 4.0.1, selecting IBM HTTP Server as the Web server.
  2. Install Fix Pack 5 and select the option to update the iPlanet Web server configuration. Click Yes and select iPlanet 6.
  3. Start the administrative server, default server, and iPlanet 6.
  4. If you encounter an error when serving http://<hostname>/servlet/snoop, open the iPlanet administrative interface (http://hostname:8888). Select your HTTP server and check Manage. Under the Java tab, clear both boxes (Enable Java globally and Enable default class).
  5. Click Apply and restart the Web server.
  6. Regenerate the plug-in and restart the Web server.

Windows 2000
Windows NT

WebSphere Application Server installation program does not update the Windows system path with the GSK library path when IBM HTTP Server is not installed (114353.RN)

If you are installing WebSphere Application Server onto a Windows platform using the Custom installation option and choose not to install IBM HTTP Server, you must manually add the path for the GSK library to the system path. This is only necessary if you want a Web server plug-in other than the IBM HTTP Server plug-in to communicate with the application server using Secure Sockets Layer (SSL). After adding the path, reboot your system so that the plug-in is loaded into the Web server properly. The GSK is installed on the C: drive, in which case you add C:\Program Files\IBM\gsk5\lib to the system path.

Windows 2000

Cannot use /WSsamples with a Domino Web Server (Defect 131884)

If you attempt to access http://<host name>/WSsamples/index.html when using a Domino Web Server, you receive the following error message: 

Exception and or log files and location relevant to defect:
404 error in browser

To work around this problem, complete the following steps:

  1. Install Lotus Domino Administrator from Notes R5 client software.
  2. Open the server document for the server you plan to use as the Web server of WebSphere Application Server.
  3. Click Web > Create URL Mapping/Redirection.
  4. Enter the following information:
    a. Under Basic:
    What do you want to set up: URL > Directory
    b. Under Site Information:
    IP Address: the host name or IP address of your Web server
    c. Under Mapping:
    Incoming URL string: /WSsamples
    Target server directory: <install_root>/WSsamples
    d. Keep the default value for the other fields.
  5. Click Save and Close.
  6. Enter the following commands at the Domino Web Server console so that the settings take effect:
    tell http restart
    or
    tell http exit
    load http
  7. You should now be able to successfully access http://<host name>/WSsamples.

See the Domino Help files for additional information about how to configure URL redirection.

Windows 2000
Windows NT

Using iPlanet Web server requires specific Windows user ID and rights (110672)

Before installing and testing iPlanet Web server, Enterprise Edition 4.0, ensure that your machine is using the same administrative ID that WebSphere Application Server uses and that the rights of the ID user include the advanced user right "Act as part of the operating system." To check and set user IDs and user rights, go to the User Manager. (On Windows NT, select Start > Programs > Administrative Tools (Common) > User Manager.) The Windows help provides information on the User Manager.

Back to installation and configuration
Back to possible problems and suggested fixes

Uninstallation

Preserving applications before uninstalling a fix pack of WebSphere Application Server Version 4 (116929.RN)

If you install applications into the WebSphere Application Server Advanced Single Server Edition after installing a fix pack and later uninstall the fix pack, the server-cfg.xml file is restored to the configuration existing prior to the installation of the fix pack and you are able to use your applications. To preserve your applications added after the installation of the fix pack, do the following:

  1. Copy the config/server-cfg.xml file to a safe location.
  2. Uninstall the fix pack.
  3. Move the copied server-cfg.xml file back to the original location.

Remove Java virtual machine Java2 properties from the server if uninstalling WebSphere Application Server Fix Pack 5 (117124)

If you uninstall Fix Pack 5 of WebSphere Application Server Version 4 and have Java2 Security enabled, you must remove the Java virtual machine (JVM) Java2 properties from the server settings or change the JVM Java2 property Enable Java2 Security setting to false before attempting to start the application server. If you do not remove the Java2 properties or set the Java2 Security property to false, the application servers will not start. If you previously installed a fix pack and only remove the most current version, you do not need to make these changes and the Java2 Security enabled servers should start normally.

Logging in as root before uninstalling on a Linux platform (104863.RN)

If you attempt to uninstall the WebSphere Application Server on a Linux platform as a non-root user, the following error messages display:

Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.server.props
	Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.client.props

To avoid the errors, log in with the root user ID and try uninstalling the product again.

Uninstalling WebSphere Application Server does not uninstall iPlanet or Apache plug-in (104521, 104599.1)

After you uninstall WebSphere Application Server, if you cannot restart the iPlanet Web server or the Apache HTTP Server, the problem might be that the uninstall program did not remove the plug-in information from the obj.conf file.

To work around this problem for iPlanet, remove the following lines from the obj.conf file:

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="full/path/to/module"  Init fn="as_init"
 	bootstrap.properties="full/path/to/plugin/config/file"  Service fn="as_handler"

To work around this problem for Apache, remove the following lines from the httpd.conf or srm.conf file:

LoadModule app_server_http_module full/path/to/module Optional AddModule mod_app_server_http.c  
WebSpherePluginConfig full/path/to/config

Then, restart the server.

Back to uninstallation
Back to possible problems and suggested fixes

Migration

All operating systems

AIX

Linux

Solaris Operating Environment

XMLConfig returns non-zero return code (Defect 141615)

If the current system configuration contains VirtualHost entries with duplicate aliases and you are migrating to WebSphere Application Server Advanced Edition (running WASPostUpgrade manually), an error is logged by XMLConfig.

This condition causes WASPostMigration to report an error and the transport plug-in information is not generated. However, all migration configuration is imported successfully. Check to see if the duplicate alias information is indeed a problem and if so, correct it. Perform GenPluginCfg manually to update the transport information.

This error is also logged in the administration server if migration was done as part of the installation process and if the duplicate alias does not cause a problem.

Adding the dependent class path entries of the node to the class path of each application server (Defect 123015.RN)

When migrating from WebSphere Application Server Version 3.0.x to WebSphere Application Server Version 4..0.x, add the dependent class path entries of the node to each application server class path if the entries are applicable and not already included as entries on the class path of the application server.

Applying fix to enable the object request broker 131 and IBM Software Development Kit 130 or IBM Software Development Kit 122 (Defect 119565.1)

If you are passing the java.math.BigDecimal class between two different WebSphere Application Server domains and you migrate one of the domains to WebSphere Application Server Version 4.0.4 with IBM Software Development Kit 131, you might have problems. The reason is that the java.math.BigDecimal class was modified in IBM Software Development Kit.

IBM Software Development Kit 131 and the object request broker (ORB) on older versions of WebSphere Application Server might not be able to handle the differences. There are no problems passing this class between WebSphere Application Server Version 4.0.4 and WebSphere Application Server Version 3.5.6.

There are fixes for the ORB in WebSphere Application Server Version 3.5.5, WebSphere Application Server Version 4.0.1, and WebSphere Application Server Version 4.0.2 to enable the ORB to handle the differences in the java.math.BigDecimal class in IBM Software Development Kit 131 and IBM Software Development Kit 130 or IBM Software Development Kit 122. The fix for WebSphere Application Server Version 3.5.5 is PQ60335. The fix for WebSphere Application Server Version 4.0.1 is PQ60336. The fix for WebSphere Application Server Version 4.0.2 is PQ60336.

The fixes for WebSphere Application Server Version 3.5.5, Version 4.0.1 or Version 4.0.2 are also required if your own code passes a class between WebSphere Application Server Version 4.0.4 and an earlier level of WebSphere Application Server and that class has a different version on the two WebSphere Application Server domains.

Note: This applies to the IBM Software Development Kit on all operating systems except the Solaris Operating Environment.

Ignore the migration failure message and these error messages (Defect 119507.RN)

If the following error messages are found in the WASUpgrade.log file when migrating from WebSphere Application Server Version 3.5.x. Standard Edition to WebSphere Application Server Version 4.0.x.:

MIGR0206E: Unable to copy directory. The source /usr/WebSphere/AppServer/ deloyedleEJBs does not exist.

MIGR0206E: Unable to copy directory. The source /usr/WebSphere/AppServer/ deployedEJBs does not exist.

These error messages cause the WASPreUpgrade.log file to indicate that migration has failed. You can ignore the migration failure message and these error messages.

Migrating servlet classes, Java servlet pages, and Web resources from WebSphere Application Server Version 3.x to 4.0.x (Defect PQ56906)

When migrating from WebSphere Application Server Version 3.x to Version 4.0.x, the document root and class path attributes of Web applications Version 3.x are used as pointers to the files that are copied into the WAR file. Migration assumes that these paths are either fully qualified paths or symbolic links. Therefore, when the paths are relative to the working directory on the application server, the files are not copied over into the WAR file.

If migration has not been performed, modify the document root and class path attributes to reflect the fully qualified path or symbolic link using the administrative console.

Perform one of the following methods when migration is run and servlet classes, JavaServer pages (JSP), and Web resources are not moved to the WebSphere Application Server Version 4.0 environment:

Using the webModuleAdditionalClasspath option when migrating Web applications (113462.RN, 117191.RN, PQ53951.RN)

When migrating from WebSphere Application Server Version 3.x to 4.0.x, the migration tool uses the class path attribute of a Web application in 3.x as a pointer to the servlet code for the Web application. The tool normally copies all files found under each path entry into the class or lib subdirectory of the WAR file. Included in the copying are any files that multiple Web applications use that are centrally located, provided that the files are included as a class path entry of the Web application.

For example, if a Web application has the following class path entries, the tool copies all files found under the servlets, utilities and lib directories to the WAR file.

<web-application name="webApp1" action="update">
  <classpath>
      <path value="e:\WebSphere\AppServer\hosts\default_host\webApp1\servlets"/>
      <path value="e:\utilities"/>
      <path value="e:\libraries\version2\lib"/>
  </classpath>
<web-application name="webApp2" action="update">
  <classpath>
      <path value="e:\WebSphere\AppServer\hosts\default_host\webApp2\servlets"/>
      <path value="e:\utilities"/>
  </classpath>

Fix Pack 2 and later of WebSphere Application Server Version 4.0 adds a new command line parameter to the WASPostUpgrade file called -webModuleAdditionalClasspath. This parameter allows you to specify the path and file names of specific files that you do not want copied into the WAR file. Instead, the one or more files specified by the -webModuleAdditionalClasspath parameter are added to the extension of the Web module (ibm-web-ext.xmi) additionalClassPath attribute based on each Web application class path entries. In addition, you can specify directories that contain files you do not want copied into the WAR file. Instead, the directories and any JAR file found in the specified directories or any of their subdirectories are added to the additionalClassPath attribute of the Web module based on the class path entries of each Web application.

Continuing the example above, suppose there is a commonUtilities.jar file under the e:\utilities directory and files under the e:\libraries\version2\lib directory that should not be saved to the WAR files. You can invoke the WASPostUpgrade file by issuing the command below on Windows platforms. (Do the equivalent for UNIX platforms.) As to the command, c:\backup_directory is the migration backup directory and wsnodename is the adminNodeName. Note that the one-line command is shown here on two lines to improve readability.

WASPostUpgrade c:\backup_directory -adminNodeName wsnodename -webModuleAdditionalClasspath e:\utilities\commonUtilities.jar;e:\libraries\version2\lib

The commonUtilities JAR file and all files found under the lib directory (and its subdirectories) of the e:\libraries\version2\lib path are not copied to the WAR files. Also, the following entry appears in the ibm-web-ext.xmi file of the Web module for webapp1 migrated to WebSphere Application Server Version 4.0.x:

additionalClassPath="e:\utilities\commonUtilities.jar;e:\libraries\version2\lib" and the following entry appears in the ibm-web-ext.xmi file of the Web Module for webapp2 migrated to Versin 4.0.x: 

additionalClassPath="E:\utilities\commonUtilities.jar;"

Updating manually each clone when migrating a model-clone to WebSphere Application Server Version 4.0.4 (Defect 121389.RN)

Fix Pack 2 for WebSphere Application Server Version 4.0 added clone-only attributes to the list of attributes for server groups.

Refer to InfoCenter article 6.6.22.0: Server group properties to see what attributes are clone-only.

This affects which server group attributes can be updated using XMLConfig. Those attributes that are identified as clone-only are ignored if they are specified.

As a result, when migrating a model-clone to WebSphere Application Server Version 4.0.4 or later, not all server group properties are propagated to each clone.

After migration, manually update each clone to set these types of server group properties. Each clone has its standard output set to stdout.txt and standard error set to stdout.err.

Save directories before migrating (109726.1)

If you plan to migrate from WebSphere Application Server Advanced Single Server Edition to the Advanced Edition, save a copy of the following directories before starting the migration process:

\config
\installableApps
\installedApps
\properties

After the migration is successfully performed by the installation process, restore the mentioned directories back to the Advanced Edition installation directory.

Back up the sas.server.props file before migrating (110556.1, 110556.2)

The sas.server.props file contains critical information for the administrative server. Back up the sas.server.props file before migrating.

/tmp/WAS*.properties deleted during prerequisite upgrades (110046.RN)

When the pre-migration process completes, a file named WAS_MIGRATION_TEMP.properties is stored in the /tmp directory and is also stored in the migration backup directory specified during the pre-migration process. If you upgrade the operating system level on this machine, you need to copy this file from the migration backup directory to the /tmp directory. The /tmp directory is emptied during the operating system level upgrade.

Copy the admin.config.bak file before starting the administrative server (110477.RN)

The migration process for the WebSphere Application Server Advanced Edition updates the admin.config file in the WebSphere Application Server Version 4.0.x bin directory. One of the side effects of this update is that blank characters and comments are removed from the file during this processing.

After you install WebSphere Application Server, there is a copy of the admin.config file called admin.config.bak in the bin subdirectory. However, this file is erased when the administrative server is started. It is advisable to copy the admin.config.bak file to another name before the administrative server is started. Use this file as a record of the original values in the installed admin.config file.

Ignore FileNotFoundException messages when migrating (103153, 103153.RN)

When migrating from WebSphere Application Server Version 3.0.2.x to Version 4.0.x, the WASPreUpgrade program is run. The program returns java.io.FileNotFoundException messages. The file not found is content-type.properties. Ignore the exception messages.

Migrating manually if migration fails (105661.RN)

If you are migrating WebSphere Application Server from Version 3.x to Version 4.0.x while running the installation program and a severe error occurs while saving the existing Version 3.x environment, perform the following steps to migrate the Version 3.x configuration. Note: The steps are for Windows-based systems; for UNIX-based systems add .sh to the command line.

  1. Proceed by clicking Next or OK until the installation program completes.
  2. Move to the bin directory found under the directory migration_temporary_directory.
  3. Invoke the WASPreUpgrade file by issuing the following command: 
    waspreupgrade c:\backup_directory c:\current_3.x.x_WebSphere_directory node name

    where node name is the adminNodeName. Note that in some cases the waspreupgrade command might not be totally successful. To ensure that a valid configuration is saved, verify that the file c:\backup_directory\websphere_3x_backup.xml exists. If it does not, then enter the following command from the c:\current_3.x.x_WebSphere_directory directory:

    xmlconfig -export c:\backup_directory\websphere_3x_backup.xml -adminNodeName nodename
  4. After the preceding step completes, shut down the WebSphere Application Server Version 3.x.x administrative server.
  5. Run the WebSphere Application Server Version 4.0.1 installation program. Do not check the Perform Migration check box in the Previous Installation Detected panel.
  6. After the installation program runs, move to the bin directory under the Version 4.0.1 directory.
  7. Invoke the WASPostUpgrade file by issuing the following command: 
    WASPostUpgrade c:\backup-directory -adminNodeName nodename

Error message as to the Java Database Connectivity location driver when upgrading the database level (105949.RN, 109546.RN)

A problem might occur after migrating a configuration from WebSphere Application Server Version 3.x to Version 4.0.x relating to the Java Database Connectivity (JDBC) Driver configuration. The problem shows up with an error message similar to:

javax.naming.NamingException: ClassNotFoundException: COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

The problem can happen if the data store in use required a prerequisite upgrade and this upgrade is stored in a different directory location than the original data store version. The problem occurs because the JDBC configuration that is defined in the WebSphere Application Server Version 3.x configuration uses drivers from the original data store version and its related directory names. When this configuration is exported and then imported into the WebSphere Application Server Version 4.0.1, the original directory names are used instead of the new data store version.

To correct the problem on WebSphere Application Server Advanced Edition, change the JDBC Driver Server classpath entry to use the new data store directory names in the administrative console under the Resources tree.

To correct the problem on WebSphere Application Server Advanced Single Server Edition, modify the server configuration file in the configuration directory. The default file is server-cfg.xml but you can choose to use a different file. Modifications are required to Resource Provider stanzas to use the correct class path name. For example, if you are using DB2, change the following from:

<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/
db2inst1//sqllib/java/db2java.zip" resourceProvider="JDBCDriver_3"/>

to:

<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/
db2inst1//sqllib/java12/db2java.zip" resourceProvider="JDBCDriver_3"/>

The problem also might occur if you migrate and use the same directory structure. As to Windows NT, an old copy of the db2java.zip file remains in your lib directory. That copy is loaded instead of the one pointed to by the JDBC Driver Server class path. The solution is to remove the db2java.zip file in the WebSphere Application Server lib directory.

Migrating a multi-node model-clone domain (109545.RN)

When migrating a multi-node model-clone domain to WebSphere Application Server Version 4.0.x, the following error displays in the output of the XMLConfig Import when the same EAR file is migrated and installed on nodes other than the first node that is migrated:

XMC0100E: Update action is not supported on this type of object. To reinstall the application, 
use "delete" action followed by "create" action, on enterprise-application element.

Disregard this error message.

In addition, the Web and EJB module names contained in the EAR file installed on the first node that is migrated are included in the repository. If the Web and EJB module names contained in the same EAR file installed on subsequent nodes through migration do not match, the EAR file installed on the first node that contains those modules must be manually installed and expanded on the node where the names do not match. Complete the following steps: (for Windows NT or Windows 2000; do the equivalent for UNIX platforms):

  1. Copy the EAR file found in the installableApps directory of the first node to the installableApps directory on the node you want to install, and expand it.
  2. From a MSDOS command prompt, move to the bin directory under your WebSphere Application Server Version 4.0.x server root.
  3. Invoke the EARExpander.bat file by issuing the following command: 
    EARExpander -ear e:\WebSphere\AppServer\installableApps\Big3App.ear -expandDir 
  e:\WebSphere\AppServer\installedApps\Big3App.ear -operation expand -expansionFlags war

    where e:\WebSphere\AppServer\installableApps\Big3App.ear is the EAR file you want to expand and e:\WebSphere\AppServer\installedApps\Big3App.ear is the directory in which to expand the EAR file.

Regenerating the plugin-cfg.xml file in a server group environment (110233.RN)

When migrating a multi-node model-clone domain to WebSphere Application Server Version 4.0.x, you must manually update the Web server plug-in for each node after the final node is inserted into the domain. To manually trigger an update of the configuration for the WebSphere Application Server plug-in, for each node:

  1. Locate the node in the tree view.
  2. Right-click the node and then select Regen Webserver Plugin.

Migrating properties files and interceptors for WebSEAL Versions 3.6 or 3.7 (111349)

Examine the properties files trusted servers.properties and webseal.properties installed with WebSphere Application Server Version 4 with Fix Pack 4. With Fix Pack 3, all references to WebSEAL 3.6 have been changed to WebSEAL. If you have customized these property files, then add those customizations to the files that are installed with the fix pack. Do not continue to use webseal36.properties. Use the common interceptor for WebSEAL Versions 3.6 and 3.7 called webseal.

If you write your own interceptor, ensure that the class file is in the install_root\classes directory and the property files associated with your interceptor are in the install_root\properties directory. Further, ensure that the interceptor class is public and uses a constructor that has no arguments.

Note that any interceptors that support initialization must extend WebSphereBaseTrustAssociationInterceptor. Also, they must continue to implement the TrustedAssociationInterceptor. For example: 

public class WebSealTrustAssociationInterceptor
     extends WebSphereBaseTrustAssociationInterceptor
     implements TrustAssociationInterceptor

Finally, mutual Secure Sockets Layer (SSL) between WebSeal and the IBM HTTP Server is supported in WebSEAL Version 3.7. Ensure that SSL is set up correctly. WebSphere Application Server does not validate the mutual SSL setup.

Applying the parameter -documentRootLimit when migrating from WebSphere Application Server Version 3.x to Version 4.0.x (Defect 114663.RN)

When migrating from WebSphere Application Server Version 3.x to Version 4.0.x, the migration tool uses the document-root attribute of a Web application in Version 3.x as a pointer to the .html, .gif, and other files for the Web application. The tool normally copies up to 300 files found under the document-root into the WAR file. If there were more than 300 files under the document-root, the following warning message appears in the WASPostUpgrade log file: 

MIGR0250W: Document Root file limit of 300 exceeded. Not all files for Web Application 
TestWebApp copied to War File TestWebApp.war.

WebSphere Application Server Version 4 with Fix Pack 3 and later provides a new command line parameter to the WASPostUpgrade file called -documentRootLimit. You use use this parameter to specify the number of files that the migration tool copy from under the document-root into the WAR file. The value specified is a valid integer greater than -1. The documentRootLimit file would apply to all Web applications included in the websphere_3x_backup.xml file. If no value is specified, the default is 300 files.

Creation of default applications during migration (Defect 128778.RN)

Web resources and enterprise beans that were mapped but not included in a WebSphere Application Server 3.x enterprise application were mapped into one default Java 2 Platform, Enterprise Edition (J2EE) application called DefaultApplication during migration.

In Fix Pack 4 and later, a separate default J2EE application is created for each application server where there are Web resources and enterprise beans installed but not included in an enterprise application. If the Web resources and enterprise beans are installed on application servers that are included in a model, a separate default J2EE application is created for each model and all Web resources and enterprise beans installed on application servers that are included in the model are mapped to that default application.

The name of the default applications is application server name"_MigratedApp or "model name"_MigratedApp.

AIX

Migrating to WebSphere Application Server Version 4.0.x on an AIX 4.3.2.0 platform (110827)

WebSphere Application Server 4.0.x cannot run on an AIX 4.3.2 platform. Upgrade to AIX Version 4.3.3 before migrating to WebSphere Application Server Version 4.0.x.

Linux

Migrating from WebSphere Application Server Version 3.02 on a Linux platform (110099.RN)

When migrating from WebSphere Application Server Version 3.02 on a Linux platform, an error might occur during pre-migration if JAVA_HOME is not defined in the WebSphere 3.02 setupCmdLine.sh file in the bin directory and the JAVA_HOME value cannot be correctly derived in the WebSphere Application Server 3.02 XMLConfig.sh file in the bin directory. To complete the migration, set the JAVA_HOME setting to a valid value. Modify the JAVA_HOME setting in the WebSphere Application Server Version 3.02 setupCmdLine.sh file to point to a valid IBM Software Development Kit 1.1.x directory to correct the problem and rerun the migration process again.

Linux

Security initialization error when migrating from WebSphere Application Server Version 3.5.3 to Version 4.0.x on a Linux platform (110018)

The format of the systems management database has changed significantly between WebSphere Application Server Version 3.x and WebSphere Application Server Version 4.0.x. If the database name that is used for Version 4.0.x is the same as was used for Version 3.x,then the database must be removed and recreated during the migration process at the same time that prerequisites are updated. It is recommended that you use the default database name of was40.

Solaris Operating Environment

Migration not possible with GUI unsupported on the Solaris 2.6 Operating Environment (110057.RN)

If you want to migrate from a previous version of WebSphere Application Server on the Solaris 2.6 Operating Environment, you must install all patches required by the IBM Software Development Kit 1.3 product to run the pre-migration process. These patches are listed in the README.sparc file that comes with the IBM Software Development Kit 1.3 product.

Solaris Operating Environment

Migration consideration on the non-English Solaris Operating Environment(109062.RN)

When you migrate from a previous version of WebSphere Application Server on the non-English Solaris Operating Environment, the installation program detects the proper installation location of the previous installation when attempting to migrate a Solaris, non-English, native-package that was installed to a location other than the default /opt location.

MIGR0250W error message incorrectly displays the file limit to be copied to the WAR file (PQ70811)

When you run the WASPostUpgrade script to migrate to WebSphere Application Server Version 4.0.6, the WASPostUpgrade log contains the error message MIGR0250W which incorrectly displays the file limit to be copied to the WAR file, for example: 

MIGR0250W: Document root file limit of 300 exceeded. Not all files for the Web Application 
TestWebApp copied to WAR file TestWebApp.war.

By default, up to 300 files can be copied to the WAR file. If there are more than 300 files, the MIGR0250W message is logged. If the -documentRootLimit parameter is configured to 1000, up to 1000 files can be copied to the WAR file. If there are more than 1000 files to be copied to the WAR file, the MIGR0250W message is logged, but still indicates that the number of files exceeds the limit of 300. This error message is incorrect because the actual number of files that can be copied is between 300 to 1000, depending on what the value configured for the -documentRootLimit parameter.

The number 300 is a hardcoded value. The number of files that can be copied is set by the -documentRootLimit parameter or 300 if the parameter is not configured.

Currently, there is no solution for the problem.

Back to migration
Back to possible problems and suggested fixes

Starting application server components

Application server does not start, preventing access to administrative console (105983)

The application server process for WebSphere Application Server Advanced Single Server Edition does not start, preventing access to the administrative console. As a result, you cannot use the administrative console to correct any configuration problems that might be preventing the server from starting.

To fix this situation:

  1. Check the error logs to determine why the application server does not start. This situation can occur when you modify the process definition for the application server. WebSphere Application Server provides a separate server configuration file that is configured solely for running the administrative console. Start this application server by entering the command: startServer -configFile ../config/admin-server-cfg.xml
  2. Connect to the administrative console using port 9091 from your browser (note that this is a different port from the one assigned in the default server configuration file): 
    http://localhost:9091/admin
  3. From the administrative console, open the server configuration file that is preventing the application server from starting. Correct the configuration and save the changes.

Alternatively, you can attempt to manually edit the offending server configuration file. You should always make a backup copy before making any manual changes.

Stopping the administrative server to prevent port 9000 error (109500)

WebSphere Application Server fails to start if certain ports are in use. When the bootstrap port is in use, you might see the following error when starting WebSphere Application Server. This error is similar to the "Port 9000 in use error" when starting WebSphere Application Server.

009.765.6005c5b F Nameserver Failed to start the Bootstrap server
	org.omg.CORBA.INTERNAL: minor code: 8 completed: No

To fix the problem on the Advanced Edition, change the bootstrap port (the default is 900) in the admin.config file, using the property name:

com.ibm.ejs.sm.adminServer.bootstrapPort="901"

If this property does not exist in the file admin.config, add it. For more information, see the WebSphere Application Server Version 4.0 InfoCenter article "6.6.46.0: Administrative server configuration file properties."

To fix the problem on the Advanced Single Server Edition, edit the server configuration file (the default is install_root/config/server-cfg.xml) and change the bootstrapPort value for orbSettings. For example, change

<orbSettings xmi:ed="ORBConfig_1" enable="true" bootstrapHost="localhost" bootstrapPort="900">

to

<orbSettings xmi:ed="ORBConfig_1" enable="true" bootstrapHost="localhost" bootstrapPort="901">

Administrative server does not start because the DB2 environment is not set up correctly (110569)

If you cannot start the administrative server because of a Java Database Connectivity (JDBC) problem, the possible reason is that the DB2 environment was not set up correctly. To set up the DB2 environment:

  1. Become a DB2 user.
  2. Run DB2_HOME/sqllib/java12/usejdbc2
  3. Run DB2_HOME/sqllib/db2profile

After creating the administrative repository, the administrative server fails to initialize and returns NumberFormatExceptions when started (111582.RN)

After you create the administrative repository database, allow the administrative server to initialize completely before setting the following properties to false:

The properties are in the logging.properties file in the WebSphere/AppServer/properties directory. Use the properties to control various aspects of event logging. If the properties are both set to false before the administrative server starts for the first time after a database is created, the administrative server might return NumberFormatExceptions and fail to initialize.

Administrative server does not start because AIX environment variable EXTSHM turned off (110634)

If the WebSphere Application Server Advanced Edition is installed on an AIX system with a local DB2 server and the following commands (as described in the InfoCenter) were executed previously to configure DB2, the administrative server should start successfully.

Set the EXTSHM environment variable by entering the following commands:
       $ EXTSHM=ON
       $ export EXTSHM
       $ db2set DB2ENVLIST=EXTSHM

Later, when the administrative server is stopped or the system is shut down, DB2 will stop as well. However, when you next back up the system and start DB2, the administrative server might fail with the following error when you try to start it:

Could not initialize persistent storage for serious events.
	Got exception COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N
	A database agent could not be started to service a request, or was terminated as a result of
	a database system shutdown or a force command. SQLSTATE=55032

To recover from this problem, enter the above commands that set the EXTSHM environment variable and restart the server.

To prevent the environment variable from being turned off accidentally again, add these three lines of commands to the db2profile file (assuming the db2profile file is sourced using .profile) to ensure the variable is always valid.

Customize startupTime property (Defect PQ62188.RN)

Naming service messages are being issued after the nanny service process starts, but before the administrative server starts the Name Services. Although you can ignore these messages, a new admin.config property is added to specify how long to wait on startup before error messages are produced. The directive is com.ibm.ejs.sm.adminServer.startupTime=<time in seconds>.

Back to starting application server components
Back to possible problems and suggested fixes

Administrative console and command line tools

All operating systems

UNIX

Icon identifies server group properties propagated to all clones (103550.2, 103550.3.RN, 116778.RN)

WebSphere Application Server Version 4 with Fix Pack 3 added an icon to the right of attributes propagated to all clones on server group property sheets.
The icon is:

Note that the Remove push button is not available to clone system properties on the Java virtual machine (JVM) Setting panel. The only way to remove the properties is to delete the appropriate name-value pair and then click Apply.

Access Log Analyzer help using the default Internet browser of the operating system on Windows platforms and any Internet browser, such as Netscape Navigator, on UNIX platforms (112719)

For Windows platforms, you can only access HTML help for the Log Analyzer using the default Internet browser of the operating system, even though in the Preferences dialog of the tool there are options that seemingly allow you to select either Netscape or Internet Explorer and set the location of the browser to display HTML help files.

For UNIX platforms, you can access HTML help for the Log Analyzer using any Internet browser, such as Netscape Navigator, by explicitly setting the location of the browser executable in the tool Preferences dialog. The option that seemingly allows you to select either Netscape or Internet Explorer as the browser to display HTML help files is not used.

To specify the browser on UNIX platforms:

  1. In the Log Analyzer tool, click File > Preferences.
  2. In the Analyzer Preferences dialog, select Help entry under General folder.
  3. Set the path to the Internet browser executable in the Browser Location field.

The Log Analyzer displays informational message during startup (Defect 127745.32)

Upon starting the Log Analyzer for the first time or after the preferences files of the Log Analyzer have been deleted, you see the following informational message in the shell window of the Log Analyzer: 

Cannot open input stream for waslogbrsys

You can disregard the message since it does not affect the execution of the Log Analyzer.

EARExpander no longer collapses utility JAR or .zip files (Defect PQ61441)

EARExpander no longer collapses utility JAR or .zip files starting at WebSphere Application Server Version 4.0.2 and later.

To work around this problem, you can do one of the following:

UNIX

Accessing help on a UNIX platform (Defect 110186.1)

If you receive the following message after requesting help on a UNIX platform, your locale might be set to the default C locale.

ADGU2030E: The browser could not start with the command: 
	netscape   /opt/WebSphere/AppServer/web/InfoCenter/was/06060200.html.  
	Received return code 255. Verify that you can run the browser from a command
	line and that access control is disabled.

Do one of the following to work around this error:

To see a list of the valid locales for your machine, run locale -a

To set the locale, run export LANG=locale, where locale is a valid locale. For example, to set United States English, run export LANG=en_US.iso88591. Set the locale permanently in the profile of the user.

This problem is common on HP-UX and the Solaris Operating Environment but might occur on AIX if the locale is not set properly.

If you receive the ADGU2030E message with a return code of 1, verify that access control is disabled. To turn off access control, run xhost +

Reenter the data source password (Defect PQ67211)

Reenter the password value of the data source if you are at WebSphere Application Server Version 4.0.5 and you back up to a previous version.

The default URL provider appears on only one node in the cluster (Defect PQ67800)

The default URL provider appears in the WebSphere Application Server administrative client and an XML export of the client on only one node in the cluster. When you click Install New > the other node > Unused, the default URL provider adds a semicolon at the end of the string. However, you cannot see this semicolon at the end of the string.

Currently, there is no workaround for the problem.

Back to administrative console (GUI) and command line tools
Back to possible problems and suggested fixes

Application server

All operating systems

Solaris Operating Environment

Application classloaders changes (Defect 120343.RN)

The following changes are available for application classloaders. These changes are transparent to most applications.

Application servers that have a module visibility setting of MODULE can hang during startup or run time

Application servers that have a module visibility setting of module can hang during startup or run time. Restarting the application server might circumvent the problem. To avoid the problem completely, change to use a Module visibility setting of Application, Server, CompCompatibility or the Java 2 Platform, Enterprise Edition (J2EE).

Corrections to classloader (Defect 142420)

The following document states the corrections to classloader:

  1. Change all references to /QIBM/ProdData/WebASAdv4/ to /WebSphere/AppServer/.
  2. Statement: The application extensions classloader loads classes in the /QIBM/UserData/WebASAdv4/instance/lib/app subdirectory, where instance is the name of your WebSphere Application Server instance, should be changed to [note: instance is removed :] The application extensions classloader loads classes in the /WebSphere/AppServer/lib/app subdirectory.
  3. Remove entire section on Java execution modes as this is AS/400 specific.

Customize Dr. Admin ports for the application servers (Defect PQ63146.RN)

You can choose to assign a static TCP IP port to Dr. Admin thread for the application server by adding -DdiagThreadPort= command line argument to the application server Java virtual machine.

wscp tool fails to deploy WAR application remotely (Defect PQ65109)

If you receive the following error messages, the wscp tool cannot deploy the WAR application remotely. To deploy the application, move the application WAR file to the target or remote application server machine (instead of the local client machine) and invoke the wscp client from that machine.

"WSCP0086E Exception installing EnterpriseApp"
"WSCP0106E Could not get RemoteArchiveInfo..."

Selecting the Java Message Service resources during the WAR file installation (Defect 147469.RL)

During the WAR file installation, selecting the Java Message Service (JMS) resources that are defined under the Resource Provider.

URI names omitted and a "/*" added instead after applying Fix Pack 4 (Defect PQ68237)

After applying WebSphere Application Server Version 4.0.4, the plug-in configuration file (plugin-cfg.xml) is changed. This change results in some URI names being omitted and a "/*" is placed in the URI group instead. For example:

Prior to Version 4.0.4, the FileServingEnabler through the Application Assembly Tool (AAT) has no effect when requesting static resources through the Web server plug-in. The original plug-in regeneration code ignores the FileServingEnabler flag for the context root of a slash "/" and does not add the servlet mapping of a "/*".

You might not realize that it was enabled even if you enable FileServing for the context root of a "/".

The reason for this change is as follows:

  1. When you skip the Web server and request a URL through the internal HTTP transport ports, the internal transport does not check the rules in the plugin-cfg.xml file when matching requests.
  2. It is not easy to configure the WebSphere Application Server to handle all Web content because WebSphere Application Server ignores the FileEnablingServlet (SimpleFileServlet) for a Web application with the context root of a "/".

However, this is the case only for the context root of a "/". All other Web applications add the rule context root if FileServing is enabled. Or, the Web applications list out each individual URI mapping if FileServing is not enabled. This makes the URI mapping rules consistent for all context roots instead of having a special case for the default context root of a "/".

The reason for not listing each URI mapping for a particular context root when FileServingEnabled is to reduce the search path. When the plug-ins already know if a request starts with the /contextRoot/, then it is forwarded to WebSphere Application Server to handle the request. If the FileServing is not enabled, each servlet mapping needs to be added to the file plugin-cfg.xml to ensure that only those matches are handled by WebSphere Application Server.

If you have a Web application with the context root of a "/" with FileServingEnabled, the Web server no longer requests service and makes WebSphere Application Server the handler of all requests if the virtual host mappings are matched.

You can test this using following steps:

  1. Open the files /config/plugin-cfg.xml and WEB-INF/ibm-web-ext.xmi from one of the installed Web modules.
  2. Add false for the value of FileServingEnabled in the ibm-web-ext.xmi file.
  3. Save the file and regenerate the plug-in. All URI appear. For example 
    contextRoot/*.jsp
contextRoot/j_security_check
  4. Change the value of FileServingEnabled to true.
  5. Save the file and regenerate the plug-in. All URI are changed to a single contextRoot/* for that context root.

ExceptionUtil X CNTR0020E occurs when issuing the wscp command and the enterprise application is not found in the repository (Defect PQ72194)

Scripts are run for a deployment process and to check if the application already exists. If the application exists, the application server is stopped and removed. This should not cause the following administrative exceptions: 

ExceptionUtil X CNTR0020E: Non-application exception occurred while processing method findRepositoryObjectByName on bean.

BeanId(admin#repository.jar#ClientAccess, null):
java.rmi.RemoteException: ; nested exception is:
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException:
javax.ejb.ObjectNotFoundException

The ObjectNotFoundException is expected since the enterprise application is not found in the repository when you issue the following wscp command to display the attributes of the enterprise application in the repository:

EnterpriseApp show /EnterpriseApp: dumpApp/ -asInteger

The wscp ClientRepository calls ClientAccessBean.findRepositoryObjectByName() to get the enterprise application object that is not found in repository, enterprise application object being searched by the application name. The wscp throws the following error message: 

WSCP0061E: Object not found : /EnterpriseApp:dumpApp/

The administrative server also throws the ObjectNotFoundException and Non-application exception while processing method findRepositoryObjectByName.

To avoid receiving these exceptions, you should issue the command with some existent applications.

Solaris Operating Environment

Passing an appropriate maximum permanent heap size value to Java virtual machine to avoid an application server crash (Defect 131470.RN)

On the Solaris Operating Environment, an application server might crash while under stress with a "java.lang.OutOfMemoryError", which is visible in the stderr.log file of the application server.

To prevent this error, pass an appropriate maximum permanent heap size value to the Java virtual machine (JVM), as the default is too low. The current suggested value is 64 MB.

Perform the following steps to make this change in the administrative console:

  1. Click application server.
  2. Click JVM Settings.
  3. Click Advanced JVM Settings.
  4. Enter -XX:MaxPermSize=64m in Command line arguments.
  5. Click OK.
  6. Click Apply.

Solaris Operating Environment

Performance problem when processing Java Database Connectivity ResultSets on the Solaris Operating Environment (Defect 144271.RN)

When running an application in a WebSphere Application Server on the Solaris Operating Environment, and the application processes large ResultSets, slower performance could be observed when running the same code in a standalone application.

To work around this problem, add the Sun JDK 1.3 HotSpot -client option to the application server Java virtual machine (JVM) configuration.

See the article 9.1: Tuning Guide > Sun JDK 1.3 HotSpot -server warmup in the InfoCenter of IBM WebSphere Application Server Version 4.0 Advanced Edition for more information on using -server versus -client option.

This problem is caused by a bug in the JVM. 

Bug ID   Synopsis   								Date 
4490353   Server VM much slower than Client VM in JDK 1.3.1 and 1.4.0-beta   6 Mar 2002

This bug is fixed in Sun JDK 1.3.1_04-b02. Contact support to get this version. If you have used the workaround, remove it to go back to the default setting for the application server.

Back to application server
Back to possible problems and suggested fixes

Application Assembly Tool (AAT)

Class loading errors returned when using the Application Assembly Tool (115729)

The framework in the Application Assembly Tool (AAT) used for editing and verifying the Java 2 Platform, Enterprise Edition (J2EE) archives uses custom class loaders for Java reflection within the archive. In some situations, the class loader behavior in the AAT is not consistent with the behavior in the run time. For example, you might receive validation errors when a class cannot be reflected. Or, you might encounter reflection problems or linkage errors when saving the archive.

These class loading errors result from one of two problems:

To avoid the class loading errors, correct these two problems.

Drag option is not working in the Application Assembly Tool (105643)

When you do the following in the Application Assembly Tool:

  1. Select File > Open and open a WAR file.
  2. Select File > New > Application.
  3. Select the top node from the WAR file window and try to drag this to the Web module node in the new application window.

You cannot drag the WAR file. To work around this problem, import the file (Ejb .jar/Web Module .war/Ejb client .jar) from the new application window tree node.

OutOfMemory error displays when using the Application Assembly Tool on an AIX platform (109667)

When starting the Application Assembly Tool of the WebSphere Application Server Advanced Edition by entering assembly.sh on an AIX platform, a java.lang.OutOfMemoryError exception might be returned. To resolve this problem, try adding the -mx192m option to the Java command line in the assembly.sh file. The resulting Java command line should resemble:

$JAVA_HOME/jre/bin/java \
-Xmx192m  \
-Dcom.ibm.itp.location=$WAS_HOME/bin \
-Dserver.root=$WAS_HOME \
-Dws.ext.dirs=$WAS_EXT_DIRS \
-classpath $WAS_CLASSPATH com.ibm.ws.bootstrap.WSLauncher \
com.ibm.ejs.assembly.gui.AssemblyTool

Help files are viewable only from a locally installed browser (Defect 143100)

If you access any of the WebSphere Application Server tools from a remote machine (for example, the Application Assembly Tool), note that the remote browser cannot display the help files remotely. You can only view the help files from a locally installed browser. Close all the Netscape sessions on the remote machine and click Help, to start a new Netscape session. You can then view the Help text.

A new feature is added to allow a resource (JavaServer Pages and static) to be shared across the Web application archives (Defect PQ65763.RN)

To allow a resource (JavaServer Pages (JSP) and static) to be shared across the Web application archives, WebSphere Application Server has created servlet initialization parameters for both the FileServingEnabler and JSP processor allowing the developer to specify a comma-delimited list of directories, the JAR files, or both as search paths if the requested resource cannot be located in the public document tree of the Web application archive.

You can enable this new feature through the Application Assembly Tool (AAT) as follows:

  1. Open an enterprise application archive (EAR) in the AAT.
  2. Click Web Modules > Web Module > Assembly Property Extensions.
  3. Right-click JSP Attributes or File Serving Attributes (depending upon which you choose to use).
  4. Click New.
  5. Enter one of the following options:

    Note: Value accepts a comma separated list that can mix both option 1 and option 2.

The following is a sample ibm-web-ext.xmi file demonstrating how this feature is enabled for an application that is deployed.

parameter name = extendedDocumentRoot
parameter value = Web application archive relative or absolute path to resource 

<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" 
xmlns:webapplication="webapplication.xmi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmi:id="WebAppExtension_2" reloadInterval="5" reloadingEnabled="true" defaultErrorPage="error.jsp" 
additionalClassPath="" fileServingEnabled="true" directoryBrowsingEnabled="true" serveServletsByClassnameEnabled="true">
  <webApp href="WEB-INF/web.xml#WebApp_ID"/>>
  <jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true"/>
  <jspAttributes xmi:id="JSPAttribute_2" name="largefile" value="false"/>
  <jspAttributes xmi:id="JSPAttribute_3"  name="extendedDocumentRoot" value="testcase.jar,my-test.jar,my-test.war/WEB-INF/lib/war_level.jar"/>
  <fileServingAttributes xmi:id="FileServingAttribute_1" name="extendedDocumentRoot" value="testcase.jar,my-test.jar,my-test.war/WEB-INF/lib/war_level.jar"/>
</webappext:WebAppExtension>

The new feature has the following limitations:

  1. If the JSP file is located inside a JAR file, the timestamp of the JAR file is used for isOutDated checks for recompile purposes.
  2. For static resources, the search for static resources is done after searching the public document tree but before the Welcome File search list is parsed and handled.
  3. Welcome File and Directory Browsing are not part of the new feature.

Back to Application Assembly Tool (AAT)
Back to possible problems and suggested fixes

Enterprise beans

Read the problems and fixes that apply to the type of entity bean used:

All entity beans

Update the implementation class for an enterprise bean (Defect PQ60263)

Dynamic reloading to update class for an enterprise bean is not available in WebSphere Application Server Version 4.0.4. If you want to update the implementation class for an enterprise bean, perform the following steps:

  1. Stop the module, the application, or both.
  2. Update the class file.
  3. Start the module, the application, or both.

Changes made to Connection Pooling (Defect 120566)

A significant performance improvement was introduced in WebSphere Application Server Version 4.0.2, which led to a change in the semantics for prepared statement cache in WebSphere Connection Pooling (Defect PQ53331 and 115405). But the improvement has changed the meaning of " Prepared Statement cache size" (Statement cache size).

In previous versions, this value signified the total maximum number of prepared statements that would be cached in the data source or Pool. In this and later fix packs, the value still represents the number of prepared statements per datasource, but the number is now divided by the number of connections, giving you a number of prepared statements per connection. If the number of prepared statements is less than the number of connections, a minimum of one per connection is allocated. For example, given 100 prepared statements, and 50 connections, you will have two per connection, and given 10 prepared statements and 50 connections, you will have one per connection. You might want to adjust the statement cache size. The default statement cache remains 100, and depending upon your connection pool size, this might be reasonable. For larger pool sizes, the statement cache size might need to be increased.

In WebSphere Application Server Version 4.0.x, set the statement cache size from the Connection Pooling tab of the Data Source, it has its own filed, named Statement cache size.

Oracle fails when using Repeatable Read or serializable isolation levels (Defect 138167.RN)

If the isolation level on the enterprise beans is set to Repeatable Read (RR), which is not supported on Oracle, WebSphere Application Server upgrades the isolation level to Serializable as a safe option. However, Oracle has a restriction that XA cannot run with serializable. The following error message appear in the Oracle traces: 

joxasStart(): Got a 'C' error:24776
jojniStart(): err = 24776

WebSphere Application Server throws a StaleConnectionException exception.

To avoid getting this error message, do not use the RR or Serializable isolation levels on any of the bean methods when using XA.

Entity beans with CMP

Cannot compile EJBModules containing CMP-based entity beans that use primitive primary keys (109864.1.RN)

When compiling an EJBModule that has CMP-based entity beans which use primitive primary keys, you might get an error message similar to the following:

Compiling content of ejbModule/com/ibm/ejb/cb/samples/big3/tier2
  (12 problems found) Copying all resources on the class path
  (12 problems found) Build done
  Java build completed
  Invoking Validation on /Big3BRB.jar.
ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSCMPClaimHomeBean.java(62): 
                   The constructor java.lang.Integer() is undefined
...
ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSJDBCPersisterCMPPolicyBean.java(197): 
                   The constructor java.lang.Integer() is undefined
Shutting down workbench.
Execution Halted: Compilation Errors Reported
12 Errors, 0 Warnings, 0 Informational Messages

Compilation halted because the deployment descriptor specified used a primitive object key (java.lang.Integer) but did not specify a key field to which the deployment descriptor should map. It was left as a compound key. Therefore, the deployment tool did not know which field to use as the key and returned the error messages.

As to the generated deployment descriptor in the above example, the <prim-key-class> element was set to java.lang.Integer but there was no <primkey-field> element specifying which <cmp-field> element should map to the primary key.

The solution is to use the Application Assembly Tool to specify which key field (other than compound key) should be used or to manually edit the file ejb-jar.xml and add the <primkey-field> elements.

FinderException occurs because of incorrect finder logic in an EJB server (109868.RN)

A javax.ejb.FinderException occurs when a finder method is called for an entity bean with CMP and the finder is defined incorrectly. This failure occurs when the finder returns more than one EJB object (returns either a java.util.Enumeration or a java.util.Collection) and the finder logic is encapsulated in a string constant named findMethodNameQueryString. The failure occurs because the SQL select statement encapsulated by the Java string constant is incorrect. Either the encapsulated SQL select statement does not include a complete list column names for each of the CMP fields, or the list column names does not appear in the order required to successfully hydrate the entity bean. The following is an example of the error that occurs when the encapsulated SQL select statement does not include all required column names:

ERROR: javax.ejb.FinderException: com.ibm.ejs.persistence.EnumeratorException
original exception: com.ibm.ejs.container.ContainerInternalError:;
nested exception is: COM.ibm.db2.jdbc.DB2Exception:
[IBM][JDBCDriver] CLI0610E Invalid column number. SQLSTATE=S1002

Note: Encapsulating the logic in a string constant named findMethodNameQueryString has been deprecated. What follows describes how to correctly create the finder logic in a EJB server so that the failure and similar failures do not occur.

Creating finder logic in the EJB server

For the EJB server environment, the following finder logic is required for each finder method (other than the findByPrimaryKey method) contained in the home interface of an entity bean with CMP:

As an example, suppose the AccountHome home interface defines the following finder method:

Enumeration findLargeAccounts(float amount) throws RemoteException,
FinderException;

You must also create the AccountBeanFinderHelper interface as follows:

public interface AccountBeanFinderHelper
{
String findLargeAccountsWhereClause
= "balance > ?";
}

You can use the Application Assembly Tool to define the finder logic as well. For each CMP entity bean, select your entity bean and Method Extensions choice in the tree view of the Application Assembly Tool and set the Finder descriptor for each finder method. Using the Full select radio button is not recommended because it can easily result in the javax.ejb.FinderException being thrown when the required list and order of column names is not used. Use the Where clause radio button to obtain the correct list of column names and order.

Back to enterprise beans
Back to possible problems and suggested fixes

Security

All operating systems

UNIX

Administrative server does not start due to corruption of the sas.server.props file (110546)

Corruption of the sas.server.props file might cause the administrative server to fail to start. The sas.server.props file contains critical information for the administrative server. Back up the sas.server.props file regularly.

Set the default filter in Lightweight Directory Access Protocol registry properties of Domino 5.09a LDAP security (Defect 137724.RN)

If you install Domino 5.09a Lightweight Directory Access Protocol (LDAP) security, set the default filter in LDAP registry properties to be objectclass=Person instead of objectclass=dominoPerson. Select the directory type to be the Domino 4.6 from pull-down menu of the Authentication section of the security center folder.

The existing servers cannot reconnect to the restarted server when security is enabled (Defect 139008)

In the multi-server scenario with security is enabled, when one or more servers restart for any reason, the existing servers cannot reconnect to the restarted server correctly.

The remote method invoked on the restarted server fails and the existing server appears to be in a hung state.

The reason for this behavior is that when the server restarts, it reassigns a new port to itself; however, the existing server cannot detect the new port. The existing server still tries to connect to the last known port of the restarted server, which causes the connection to time-out.

For the Workload Management (WLM) failover to function correctly between multiple nodes with security enabled, you need to assign fixed ports to the administrative server and all application servers on each node in the domain. The server starts on the same hard coded ports every time. Perform the following steps to work around:

  1. Add the following to the admin.config file on each administrative server in the domain: 
    com.ibm.CORBA.ListenerPort=2000
com.ibm.CORBA.SSLPort=2001
com.ibm.CORBA.LSDPort=9000
com.ibm.CORBA.LSDSSLPort=9001
  2. For each of the application servers in the domain, add a different port number for the Listener port and Secure Sockets Layer (SSL) port. The ports assigned must all be unique within each node. For example, for one of the application servers, add the following admin.config files to the Java virtual machine (JVM) settings: 
    com.ibm.CORBA.ListenerPort=3000
com.ibm.CORBA.SSLPort=3001

Note: These configuration is not required if security is not enabled.

UNIX

Domino server 5.0.9a Secure Sockets Layer connections can fail (Defect 135077.RN)

Domino server 5.0.9a Secure Sockets Layer (SSL) connections could fail after an indeterminate amount of time. The problem can occur on all UNIX platforms.

At some point the Domino server decides that a valid SSL certificate is not valid and does not allow all subsequent secure connections. This occurs when the Domino Web Server is under stress and is caused by a time conversion routine that is not thread safe. Messages similar to the following appear in the Domino server console output at the first sign of failure: 

07/18/2002 03:22:27 PM  HTTP server: Certificate begin date is after current date

07/18/2002 03:22:27 PM  HTTP server: Security administration system error

07/18/2002 03:22:27 PM  HTTP server: SSL session not started for 9.42.73.160

To fix this problem, contact the Domino server customer support and refer to SPR SUI5BALNA.

Authorization failure accessing a protected URI using Requestdispatcher.forward() from an unprotected URI (155475.RN)

You receive an authorization failure (HTTP response code 403) when using RequestDispatcher.forward( ) to forward from an unprotected servlet or JavaServer Page (JSP) to a protected one. Section 12.2 of the servlet 2.3 specification states that the security model does not apply when using a RequestDispatcher.

To resolve this problem, the URI which invokes RequestDispatcher.forward( ) has to be protected. This prepares the application for migration to WebSphere Application Server Version 5.

If this is not possible, then setting the following property on each application server yields a challenge when forwarding from an unprotected URI to a protected one:

com.ibm.ws.security.RequestDispatcherChallenge=true

Code implementing this property is contained in any security cumulative fix dated 1/06/2003 or more recent.

Back to security
Back to possible problems and suggested fixes

Managing workload

Solaris Operating Environment

Unable to propagate a Java virtual machine system property from a server group (Defect PQ63409)

If you are running WebSphere Application Server on a cluster of two Sun Solaris machines, you are unable to propagate a Java virtual machine (JVM) system property from the server group to the clones. For WebSphere Application Server Version 4 with Fix Pack 2 and later fix packs, the system properties has changed to a clone-only attributes. The system properties are not propagated to the clones, but you can add or modify the properties in the clone attributes.

Back to managing workload
Back to possible problems and suggested fixes

Naming

Add name server retry logic to retry naming operations that fail as a result of a stale database connection (PQ67535.RN.1)

When you stop and restart the database server used for the administrative repository, the name server operations against the database fails. The failure causes the overall naming operation to fail. You must retry the naming operation.

To prevent the overall naming operation from failing, retry logic is added to the name server so that database operations resulting in the unexpected exceptions are retried, avoiding the need for retry logic in naming client code.

Two new properties are introduced to control the number of retries and the delay (in milliseconds) between retries. These new properties are: 

com.ibm.websphere.naming.db.retrycount 
com.ibm.websphere.naming.db.retrydelay

By default, the values for these properties are set to: 

com.ibm.websphere.naming.db.retrycount=2 
com.ibm.websphere.naming.db.retrydelay=2000

Back to Naming
Back to possible problems and suggested fixes

Web servers

All operating systems

Linux

Solaris Operating Environment

Linux

Running with Extended Application Programming Interface Compiled Apache on SuSE 7.0 SLES for Z/Linux (Defect 135929, PQ62563)

When running WebSphere Application Server with Apache (1.3.19-40) that is provided with SuSE SLES 7.0 (Linux for Z/OS), use the non-EAPI compiled WebSphere Application Server plug-in, even though this particular Apache version is Extended Application Programming Interface (EAPI) compiled.

When configuring the Apache httpd.conf file, change the following line: 

LoadModule app_server_http_module opt/WebSphere/AppServer/mod_app_server_http_eapi.so

to 

LoadModule app_server_http_module opt/WebSphere/AppServer/mod_app_server_http.so

When you start Apache with the non-EAPI module, the following warning appears: 

[warn] Loaded DSO /opt/WebSphere/AppServer/bin/mod_app_server_httpd.so uses plain Apache 1.3 API,
 this module might crash under EAPI! (please recompile it with DEAPI)

In this situation, you can ignore the warning.

Linux

Unable to create certificate request with IBM HTTP Server (Defect 138035.RN)

If you are on a Linux/390 machine, running command line IKEYMAN (IKEYCMD), you might receive the following error message: 

java.util.MissingResourceException: Can't find resource for bundle
java.util.PropertyResourceBunde. key GSKKM_<some option>.

To work around this error, add
-Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikuser.properties to the command.

For example, java -Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikmuser.properties com.ibm.gsk.ikeyman.ikeycmd <arguments>.

IBM HTTP Server does not start when Secure Sockets Layer is used and the WebSphere Application Server is running (103882)

IBM HTTP Server might hang during initialization when it is configured for the Secure Sockets Layer (SSL) and the WebSphere administrative server is running.

To solve this problem, try any of the following workarounds:

The gskikm.jar file and IBM HTTP Server IKEYMAN conflict workaround (108144.RN)

If you install IBM HTTP Server with IBM Software Development Kit 1.3.0 and WebSphere Application Server and attempt to define a key using the IBM HTTP Server IKEYMAN Hardware Crypto Menu options, the resulting window might be difficult to see and navigate. Use a workaround for the appropriate platform to correct this problem:

AIX:

  1. Copy the /usr/opt/ibm/gskkm/bin/gsk5ikm directory into a different directory.
  2. Modify the new copy of gsk5ikm, replace this line at the bottom of the file: 
    $JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT

    with this one-line statement (shown here on two lines to improve readability):

    $JAVA_EXECUTABLE -Djava.ext.dirs=/usr/opt/ibm/gskkm/classes/ikmuser.properties
   	$IKEYMAN_TEMP_JAVA_INPUT
  3. Include the /usr/WebSphere/AppServer/java/bin directory in your PATH environment variable.
  4. Execute the new copy of gsk5ikm.

Linux platforms:

  1. Copy the /usr/local/ibm/gsk5/bin/gsk5ikm directory into a different directory.
  2. Modify the new copy of gsk5ikm, replacing the following line at the bottom of the file: 
    $JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT

    with this one-line statement (shown here on two lines to improve readability):

    $JAVA_EXECUTABLE -Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikmuser.properties
$IKEYMAN_TEMP_JAVA_INPUT
  3. Include the /opt/WebSphere/AppServer/java/bin directory in your PATH environment variable.
  4. Execute the new copy of gsk5ikm.

iPlanet Web server 4.1 does not serve WebSphere Application Server servlets on the Solaris Operating Environment (104613)

When running the WebSphere Application Server administrative server, a server error is returned when you try to run a servlet such as the sample servlet snoop. To enable the iPlanet plug-in to send the servlet to WebSphere Application Server, turn off the iPlanet servlet support:

  1. Start the iPlanet console.
  2. For the server that needs to be altered, click Manage.
  3. Go on the Servlet tab and, for the Activate Servlet Engine option, select No.
  4. Click OK.
  5. Click Save and Apply and the Web server restarts.

Log of Domino plug-in configuration failure could be incorrect on the UNIX platforms (109968.RN)

On the UNIX platforms, the log of Domino plug-in configuration failures might include a false negative when Domino configuration code is run. If the Domino Web Server Application Program Interface (DSAPI) plug-in does not load, then use the manual Domino configuration instructions to troubleshoot the configuration. If the plug-in appears to load properly (that is, it is viewable in the Domino console startup messages), you can disregard the log error.

Solaris Operating Environment

Using the libdomino6_http.so plug-in file when you are using the Domino 6 Web server (Defect 162288.RN, 166464)

The Domino 6 Web server does not load modules linked with the GSK4 library. To solve this problem, you must have a separate plug-in for the Domino 6 Web server using the GSK5 library. The plug-in file is libdomino6_http.so. The Domino 5.0.x Web server should continue to use the libdomino5_http.so plug-in file.

Back to Web servers
Back to possible problems and suggested fixes

Working with HTTP servers

All operating systems

AIX

Use SessionReaperInterval to set the interval of the Invalidation Thread in the Session Manager (Defect PQ54352.doc)

PropertySessionReaperInterval is now a new system property. It can be used to set the sleep interval of the Invalidation Thread in the Session Manager.

The instructions for applying the system property are as follows:

  1. Open Command line arguments of Application Server instance.
  2. Specify system property as -DSessionReaperInterval=interval(in sec).
  3. Apply the changes.
  4. Restart the Server instance.

An example of the instructions:

  1. From the Administrative Console, select Default Server.
  2. From the Command line arguments, specify the property as -DSessionReaperInterval=600.
  3. Specify SessionReaperInterval <= 0, if you do not want to have a invalidation thread running in a server instance.

Submit the Directory Logging Form can be submitted by using the enter key (Defect 129747.RN)

You can submit the Directory Logging form under the Logs section in the IBM Administration Server, using the Enter key when using Netscape 4.78 on Linux Red Hat 7.2 and Netscape 4.7 on Solaris 8. The Directory Logging form accepts invalid data for the text field Cookie domain to include in the header field, which sets the CookieDomain directive in the configuration file. The IBM HTTP Server gives an error during restart. To avoid entering an invalid value for the CookieDomain directive, use Submit in the form to submit the data.

HTTP server port is configurable through wscp (Defect PQ59624.RN)

The default HTTP server port is 9080. Each additional application server created gets the next incremented number, for example, 9081. It is important to configure the port number when there are multiple WebSphere Application Server instances installed on one physical node. Each instance is assigned the starting port number for the HTTP transport port. The wscp command is wscp> Node modify /Node:myNode1/ -attribute {{LastUsedPort 9100}} where myNode1 is the node on which WebSphere Application Server is installed and 9100 is the port number at which to start incrementing.

A truncated text message displays during the uninstallation of IBM HTTP Server Version 2.0 (Defect 154958.RN)

During the uninstallation of IBM HTTP Server Version 2.0, a pop-up window with a truncated message displays. The text message is similar to the following: 

/opt/IBMIHS/conf/httpd.conf.sample exists on this system and it had been modified 
since installation.
Do you want to remove this file?

IBM HTTP Server Version 2.0 is now available on all supported platforms

IBM HTTP Server Version 2.0 is now available on all supported platforms. Based on the new Apache 2.0 Web server, this version of IBM HTTP Server includes an Apache 2.0 foundation (Version 2.0.42), IBM-added InstallShield MultiPlatforms installation, Secure Sockets Layer (SSL), and Lightweight Directory Access Protocol (LDAP). IBM HTTP Server Version 2.0 is fully supported by IBM when deployed with WebSphere Application Server Version 4.0.5. Download IBM HTTP Server Version 2.0 can be from http://www-3.ibm.com/software/webservers/httpservers/.

Installing IBM HTTP Server Version 2.0:

Go to the directory when you unpack the downloaded file and issue:
java -jar setup.jar

If you want to install IBM HTTP Server Version 2.0 on UNIX without using an XWindows GUI: 

java -jar setup.jar -silent

java -jar setup.jar -console

Setting up IBM HTTP Server Version 2.0 with WebSphere Application Server Version 4.0.5

To use IBM HTTP Server Version 2.0 with WebSphere Application Server Version 4.0.5, locate the IBM HTTP Server 2.0 httpd.conf file (in the conf directory under the server root) and add the following directives to allow the HTTP Transport plug-in to work correctly with IBM HTTP Server Version 2.0: 

LoadModule  was_ap20_module  /full/path/to/module 
WebSpherePluginConfig   /full/path/to/config

When WebSphere Application Server Version 4.0.5 is installed on the same machine as IBM HTTP Server Version 2.0:
Paths to module are:
Windows NT and Windows 2000: C:\<WASROOT>\bin
Linux: <WASROOT>/bin
Linux 390: <WASROOT>/bin
Solaris Operating Environment: <WASROOT>/bin
AIX: <WASROOT>/bin
HP: <WASROOT>/bin
Paths to the WebSphere plug-in configuration file (plugin-cfg.xml) are:
Windows NT and Windows 2000: C:\<WASROOT>\config
Linux: <WASROOT>/config
Linux 390: <WASROOT>/config
Solaris Operating Environment: <WASROOT>/config
AIX: <WASROOT>/config
HP: <WASROOT>/config

Installing WebSphere Application Server Version 4.0.5 on a different machine from IBM HTTP Server Version 2.0 (remote configuration):

If IBM HTTP Server Version 2.0 is installed on a machine without WebSphere Application Server Version 4.0.5, you need to get the 2.0-based WebSphere Application Server plug-in from a machine with WebSphere Application Server Version 4.0.5 installed. The WebSphere Application Server Version 4.0.5 Installer installs the 2.0-based WebSphere Application Server plug-in in the bin directory of the WebSphere Application Server server root (this is where all the modules reside). The file name for the 2.0-based WebSphere Application Server plug-in is mod_was_ap20_http.dll (for Windows platforms) or mod_was_ap20_http.so (for UNIX or Linux platforms). The 2.0-based WebSphere Application Server plug-in needs to be copied to the machine where IBM HTTP Server Version 2.0 is installed. It is suggested that you put the 2.0-based WebSphere Application Server Plug-in into the same directories where the IBM HTTP Server modules are:

Windows NT and Windows 2000: C:\Program Files\IBM HTTP Server 2.0\modules
Linux: /opt/IBMIHS/modules
Linux 390: /opt/IBMIHS/modules
Solaris Operating Environment: /opt/IBMIHS/modules
AIX: /usr/IBMIHS/modules HP: /opt/IBMIHS/modules

For Windows platforms, you must also copy the plugin_common.dll file (the 32-bit common plug-in libraries) to the machine where IBM HTTP Server Version 2.0 is installed. Put the file in the same directory as the IBM HTTP Server modules:

Windows platforms: C:\Program Files\IBM HTTP Server 2.0\modules\plugin_common.dll

You must also copy the WebSphere Application Server plugin-cfg.xml file corresponding to the target WebSphere Application Server Version 4.0.5 server to the machine where IBM HTTP Server Version 2.0 is installed. It is suggested that you put the WebSphere Application Server Version 4.0.5 plugin-cfg.xml file in the same directories where the IBM HTTP Server configuration files reside. Here are the suggested paths to the WebSphere Application Server plugin-cfg.xml configuration file:

Windows NT and Windows 2000: C:\Program Files\IBM HTTP Server 2.0\conf
Linux: /opt/IBMIHS/conf
Linux 390: /opt/IBMIHS/conf
Solaris Operating Environment: /opt/IBMIHS/conf
AIX: /usr/IBMIHS/conf HP: opt/IBMIHS/conf

Once you have copied the plugin-cfg.xml file to the IBM HTTP Server Version 2.0 machine, you must edit the plugin-cfg.xml to point to valid paths on the IBM HTTP Server Version 2.0 machine. For example: 

<Log LogLevel="Error" Name="/opt/WebSphere/AppServer/logs/http_plugin.log"/>

The path /opt/WebSphere/AppServer/logs/http_plugin.log must be a valid path on the IBM HTTP Server 2.0 machine.

If SSL is set up on WebSphere Application Server Version 4.0.5, you must copy the plugin-key.kdb and plugin-key.sth files from the WebSphere Application Server Version 4.0.5 machine to the IBM HTTP Server Version 2.0 machine and edit the plugin-cfg.xml file to point to the appropriate paths on the IBM HTTP Server Version 2.0 machine. For example: 

<Property name="keyring" value="/opt/WebSphere/AppServer/etc/plugin-key.kdb"/>
<Property name="stashfile" value="/opt/WebSphere/AppServer/etc/plugin-key.sth"/>
The path /opt/WebSphere/AppServer/etc/plugin-key.kdb and /opt/WebSphere/AppServer/etc/plugin-key.sth must be valid paths on the IBM HTTP Server 2.0 machine.

AIX

Error message is thrown when you attempt to start IBM HTTP Server 2.0.42.1 on AIX 5.2.0 (Defect 161821.RN)

You can receive the following error message when attempting to start IBM HTTP Server 2.0.42.1 on AIX 5.2.0: 

[crit] (78) A remote host did not respond within the timeout period.: 
alloc_listner: failed to set up sockaddr fo ::
Syntax error on line 130 of /usr/IBMIHS/conf/httpd.conf
Listen setup failed.

The /etc/netsvc.conf file can cause the error message. The default version of this file has all of its lines commented out. If your hosts line is uncommented and looks like hosts = local = auth , bind, it might be causing a problem.

Take one of the following options to solve the problem:

The requests with post data greater than 64K causes the Domino 6.0.1 Web server to crash (Defect 166278.RN)

The requests with post data greater than 64K causes the Domino 6.0.1 Web server to crash. Lotus has identified this as a bug and the Lotus SPR number is DMEA5MRKJH. You need to open an incident report with Lotus to receive a hotfix for this issue.

Back to working with HTTP servers
Back to possible problems and suggested fixes

Data access

Read the problems and fixes that apply to your database:

Connect JDBC driver

The new ConnectJDBC 3.1 driver provides a performance enhancement (Defect 148029)

When using the new Data Direct ConnectJDBC 3.1 JDBC driver supported with this release, the selectMethod=cursor configuration parameter is no longer required. The ConnectJDBC 3.x drivers have added support for transactional operations using the selectMethod=direct mode. In most cases, selectMethod=direct provides better performance than the selectMethod=cursor mode required with the ConnectJDBC 2.2 driver.

DB2

Information about the support for the universal Java Database Connectivity drivers of DB2 Version 8.1 (Defect 162216)

DB2 Version 8.1 has added the support for a new universal Java Database Connectivity (JDBC) type 4 driver (class name com.ibm.db2.jcc.DB2ConnectionPoolDataSource). This is in addition to the existing type 2 and type 3 drivers available in the previous releases of DB2. See the following link for any information on the differences between the legacy JDBC drivers and the universal drivers:

http://www-3.ibm.com/software/data/db2/udb/ad/v8/client/db2a1305.htm

WebSphere Application Server, Version 4.0.6 adds the support for the universal driver in type 4 mode only. You must set the driverType property to 4 to use this driver. The required properties for the driver are serverName, portNumber, driverType, and databaseName. In order to ensure the correct translation of StaleConnectionExceptions, a minimum of DB2 8.1 FP 2 must be used.

The universal driver provides the support for an optimization that allows the JDBC driver to defer prepares of prepared statements until the execution time. This allows the prepare and execute to be piggybacked as a single request to the server, thereby reducing network delays. However, a side effect of this optimization is an SQL0301N exception attempting to execute prepared statements which uses the setBinaryStream() or setBlob() methods. Applications which use setBinaryStream() or setBlob() with the universal driver must disable the deferred prepares by setting the property deferPrepares to false.

Because the WebSphere Application Server administrative server uses the setBinaryStream() and setBlob() methods on prepared statements, it is required to set the deferPrepares property to false in the <WAS_HOME>/bin/admin.config file when you use the universal JDBC driver. The admin.config file should contain the following properties: 

com.ibm.ejs.sm.adminServer.dbdataSourceClassName=com.ibm.db2.jcc.DB2ConnectionPoolDataSource
com.ibm.ejs.sm.adminServer.dbserverName=<serverName>
com.ibm.ejs.sm.adminServer.dbportNumber=<portNumber>
com.ibm.ejs.sm.adminServer.dbdriverType=4
com.ibm.ejs.sm.adminServer.dbdeferPrepares=false
com.ibm.ejs.sm.adminServer.dbdatabaseName=<databaseName>
com.ibm.ejs.sm.adminServer.dbuser=<user>
com.ibm.ejs.sm.adminServer.dbpassword=<password>
com.ibm.ejs.sm.adminServer.dbdisable2Phase=true

DB2 net driver unsupported for remote access (109131)

The net driver for accessing DB2 remotely is not supported in this version of WebSphere Application Server. If you are using DB2 remotely, do not modify the dbServerName and dbPortNumber fields in the admin.config file. The use of the DB2 client installation and DB2 aliases is supported in order to access DB2 remotely.

"NoSuchFieldError: batchReturn" in DB2 troubleshooting (108903.RN)

When you run DB2 on any UNIX platform, you might see the following error message:

java.lang.NoSuchFieldError: batchReturn

This error is caused because of a mismatch of the db2java.zip files. To work around this problem, ensure that the db2java.zip file in the Java12 directory is before the db2java.zip in the Java directory in your class path. A common problem is to install a Java Database Connectivity (JDBC) driver using ~db2inst1/sqllib/java/db2java.zip, while you should have specified ~db2inst1/sqllib/java12/db2java.zip.

IBM Toolbox for Java (AS/400 Toolbox for Java) requires Modification level 4 and a fix pack (110573)

To use the IBM Toolbox for Java (also known as the AS/400 Toolbox for Java) Java Database Connectivity (JDBC) driver with WebSphere Application Server Version 4.0.x, you must use the most current version of the IBM Toolbox for Java Modification level 4 (5722JC1 or JTOpen). If you have installed the licensed product 5722JC1, you must also apply 5722JC1 Fix Pack SI02195. After applying the Fix Pack, replace the Toolbox JAR file (jt400.jar) on the workstation systems on which you are running WebSphere Application Server Version 4.0.x with the updated version from your iSeries system.

System hangs when running WebSphere Application Server on the Solaris 8 Operating Environment with DB2 ()

When running WebSphere Application Server on the Solaris 8 Operating Environment with a DB2 UDB database as the repository, your system might develop a hang condition. The hang condition occurs because of networking problems on the Solaris Operating Environment. To fix the condition, do the following:

  1. Install the latest recommended patch cluster from sunsolve.sun.com.
  2. If the patch cluster does not contain patch 109472-07, apply this patch from sunsolve.sun.com.
  3. Download and install WebSphere fix PQ51500.

Depending on your specific system, you might need one, two, or all three of these solutions.

Informix

Identifying row locking in online transaction processing applications (Defect 119115)

The table syntax created by WebSphere Application Server during deployment for Informix Database Server are created with the default locking mechanism for Informix. The default is page locking. For online transaction processing (OLTP) applications, the user should identify which specific tables need row locking and change them manually.

Exceptions thrown in a WebSphere Application Server configuration using workload management and Informix Version 7.31 (115430.RN)

If your WebSphere Application Server configuration is WLM-enabled, uses Informix Version 7.31, and has an application installed using a server group, severity 1 exceptions are thrown when you do either of the following:

Messages for the exceptions are shown in the administrative console messages area and detailed information on the exceptions are given in the tracefile and the activity.log files. The messages resemble the following:

Ignore these exceptions. Your server clones and application run successfully.

Oracle

Surrounding a query with () causes the Ora-01009 error or an empty result set (113709.RN)

If you are using the Oracle thin driver and the OCI driver, surrounding a query with parentheses ("()") results in the error "ORA-01009: missing mandatory parameter" and an empty result set (no data). This is an Oracle error (917674) and was fixed in the 817.2 fixset. To avoid the problem, either install Oracle fixset 817.2 or avoid surrounding queries with parentheses.

Setting connection pooling variables on the Solaris Operating Environment or Linux platforms(105924)

If you are using connection pooling with Oracle on the Solaris Operating Environment or Linux platforms, it is recommended that you set the maximum number of files allowed open per user to at least 2048. You can do this using the ulimit command. Enter ulimit -n 2048 in the session where you run the application server.

It is also recommended on the Linux system that the Java virtual machine (JVM) initial heap size and maximum heap size set to be 256 megabytes and 512 megabytes, respectively. Using the administrative interface, select Nodes > node_name > Application Servers > server_name > Process Definition > JVM Settings. In the Initial Heap Size field, enter 256 and in the Maximum Heap Size field enter 512. Save the configuration and restart the application server to have the settings take effect.

OracleXAException occurs on Oracle 8i and 9i (Defect 152397.RN.ASV40)

During the testing of WebSphere Application Server, Oracle has a problem when using two different physical XA connections open to the same Oracle instance. The problem causes the following exception:

On Oracle 9i: XAER_RMERR resource error -3

On oracle 8i: ="Io exception: End of TNS data channel", SQLState=null, vendorCode=17002)

An Oracle bug has been opened (2511780) to solve this problem. Contact Oracle or IBM support for status on the Oracle bug.

Sybase

Java Database Connectivity limitations with Sybase Server 12.0 (109324)

With Sybase as the administrative repository, the following DatabaseMetaData methods are not implemented as of the last Sybase EBF and will throw UnimplementedOperationExceptions.

getSchemaName()
getTableName()
getCatalogName()

When you install and use Sybase, be sure that you apply the latest EBF and search the accompanying Cover.ROLL.EBF# document that lists what patches and enhancements are a part of EBF# (where EBF# is the number of the latest fix available). In particular, look for the following EBF IDs:

1074408-11 CR255096
1074408-12 CR255094
1074408-13 CR255097

Sybase EBF 9422 required for Test Connection(117161.RN)

During the creation of a data source, you can click Test Connection to determine if the data source is set up correctly before proceeding. When the data source is for Sybase, clicking Test Connection might return a JZ0C0 error indicating that the connection was already closed. If this problem occurs, you must install Sybase EBF 9422 or later. Note that, even if you encounter a JZ0C0 error, the administrative and application servers should work properly on EBFs prior to 9422.

Using the correct Oracle version to avoid performance degradations for the administrative repository (Defect PQ70364)

When starting up the administrative console or performing XMLConfig administrative tasks, the duration ranges from 10 to 30 minutes. The reason for this is that when the administrative server makes a call to retrieve the repository data used to fill the administrative console tree or for an XMLConfig export, the server waits 30 seconds for a response from the remote 64-bit Oracle 9 database server.

To workaround the problem in the administrative repository or to avoid performance problems with your application, either use 32-bit Oracle 9i R1 or Oracle 9i R2 (64-bit or 32-bit).

Back to Data access
Back to Possible Problems and Suggested Fixes

Java programming

Adding a .hotspot_compiler option to avoid cloned application servers crashing or restarting (Defect 122626)

When trying to run a Java client program in a ServerGroup environment with multiple application server clones on the the same machine you might see the following errors:

Client Window: 

- Java.rmi.MarshallException: CORBA
Comm_Failure 1 Maybe: 
- org.omg.CORBA.COMM_FAILURE: minor
code: 1 completed: maybe
- at com.ibm.CORBA.iiop.IIOPConnection
.purge_calls
- at com.ibm.CORBA.iiop.StandardReaderThread.run

This set of errors occur for each cloned application server that fails.

Client Log: 

- WWLM0019: Method getNextClone found
no usable proxies in the list.

You see one of these messages for each subsequent client request made after the clones fail.

WebSphere Application Server trace file: You see messages saying that all the clones have been restarted.

Within the $WAS_HOME/bin directory, you see a core file was generated, and a hs_err_pidxxxx.log file is created for each failing cloned application server.

To work around, create a file in the $WAS_HOME/bin directory with the name .hotspot_compiler and add the following string to that file: exclude com/ibm/ws/wlm/util/RIHelper removeServiceContext.

Setting the class loader for an application consisting of client and server side components (Defect 123414)

If an application consisting of client and server side components is deployed in an application server sharing the same Java virtual machine (JVM), then the class loader that loads the client side components need to be the same as the one that loads the server side components. Otherwise, you might see an org.omg.CORBA.BAD_PARAM orb error with message of: 

"Servant is not of the expected type"

To avoid this error, the class loader needs to be shared between the client and server side components. One way this can be achieved is by setting the property com.ibm.ws.classloader.classSharing=true. More information on related topic of class loader visibility and sharing can be found in InfoCenter.

Specify two additional properties when specifying Java virtual machine property com.ibm.ws.classloader.classSharing=false (Defect 139717.RN)

If you specify Java virtual machine (JVM) property com.ibm.ws.classloader.classSharing=false, you need to specify two additional JVM properties.

Complete the following steps to add the properties:

  1. Select the application server that sets the property com.ibm.ws.classloader.classSharing=false.
  2. Click JVM.
  3. Click Advance JVM Settings.
  4. Add -Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util -Dcom.ibm.CORBA.notLocal=true in command line arguments.

After completing the above steps, setting -Dcom.ibm.CORBA.notLocal=true performance is affected. notLocal means although client and server can be deployed in the same application server, they are treated as remote to one another. Setting notLocal to true, is no different than deploying a client application (JSP file or servlet) in one application server and deploying a server application (an enterprise bean) into a different application server.

Generic Java Message Service provider does not support two phase commit WebSphere transactions (Defect PQ67210.RN)

In WebSphere Application Server Version 4.0, two phase commitment transactions are only supported through the Java Message Service (JMS) wrappers for the MQSeries JMS provider. Generic JMS providers are supported through an external Java Naming and Directory Interface (JNDI) lookup, but they are not wrapped and cannot participate in a 2PC transaction.

This fix supplies a standalone generic JMS resource binding utility, whose purpose is to bind a WebSphere wrapped JMS resource which has an indirect reference to the actual generic provider resource. The wrapped JMS resource can then be used within the application server, and because it is now wrapped it will be able to participate within two-phase WebSphere transactions. The WebSphere JMS run time is enabled to support these resources and recover them in the case of a failover.

The syntax to the generic JMS resource binder is: 

<install_root>\java\bin\java -cp <install_root>\lib\resources.jar;<naming_jars>; 
com.ibm.ejs.jms.generic.GenericJMSBinder <WASICFactory> <WASNameSpaceURL> <InternalJndiName> 
<ExternalICFactory> <ExternalProviderURL> <ExternalJndiName> <QCF/TCF>

A memory leak observed during stress testing WebSphere Application Server on the SuSE Linux390 platforms (Defect PQ69054.RN)

A memory leak observed during stress testing WebSphere Application Server on SuSE 7.0 Linux 390. The memory leak quickly used the available Java virtual machine (JVM) heap storage and system memory, causing a java.lang.OutOfMemory error display on the application server and the application server to restart.

This problem is identified in the Object Request Broker component of the IBM Software Development Kit shipped with WebSphere Application Server.

To work around this problem, apply fix PQ69054 which is available on all platforms.

Back to Java programming
Back to possible problems and suggested fixes

Working with sessions

A new admin.config directive is added (Defect PQ62586)

You can specify the directory where passivated session beans can be stored as a new admin.config directive. Stateful session beans are being passivated to the <install_root>/bin directory, which you can customize. The new directive is com.ibm.ejs.sm.adminServer.containerStatefulSessionBeanPassivationDir=<directory name>.

Session persistence fails on DB2/390 (Defect 164349.RN)

When using session persistence with DB2 8.1 client (including fix packs) connecting to a DB2/390 V7 server, you might receive the following error written in the std_err log when trying to start the application server using persistent sessions: 

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2] SQL0440N  No authorized routine 
named "SQLCOLUMNS" of type "" having compatible arguments was found.  SQLSTATE=42884

If you receive this error, have your DB2/390 administrator apply DB2 Fix Pack UQ72083. If you have any questions regarding the DB2 Fix Pack, contact DB2 Support.

Back to working with sessions
Back to possible problems and suggested fixes

Interoperability

Implementing a compatibility mode between WebSphere Application Server Version 3.5.6, Version 4.0.4, and WebSphere Application Server zSeries 4.0.x (Defect 113380.3, Defect 113380.6)

Pass-by-value calls failed due to serialization exceptions in the following scenarios:

To work around this problem, deploy a new system property -Dcom.ibm.websphere.container.portable to implement a compatibility mode between WebSphere Application Server Version 3.5.6, WebSphere Application Server Version 4.0.3, and WebSphere Application Server zSeries 4.0.x. In addition, additional checking occur regarding the use of Enumerations and Collections returned by finder methods. Refer to Defect 110799.RN for more details.

Do not enable this property unless your application has an interoperability problem with one of the above scenarios.

Do not enable this property on a WebSphere Application Server Version 4.0.4 with C++ clients to that server.

Do not enable this property on a WebSphere Application Server Version 3.5.6 or WebSphere Application Server V4.0.4, unless all your clients to that server are WebSphere Application Server Version 3.5.6 and later for WebSphere Application Server Version 3.5.x, or WebSphere Application Server Version 4.0.4 and later for WebSphere Application Server Version 4.0.x.

Check the WebSphere Application Server for zSeries documentation to identify the correct installation procedures for that environment. Failure to do so results in exceptions being thrown due to serialization errors.

Once the property com.ibm.websphere.container.portable=true has been set on a WebSphere Application Server Version 3.5.6, the following restrictions still apply:

  1. Handles to entity beans obtained from WebSphere Application Server Version 3.5.6 will not work with WebSphere Application Server Version 4.0.4 and above clients, because handles for entity beans are only valid for the naming domain for the server that created them.
  2. EJBMetaData cannot be obtained from a WebSphere Application Server Version 3.5.6 Home from a WebSphere Application Server Version 4.0.4 or later client.
  3. EJBMetaData and Handles for entity beans obtained from WebSphere Application Server Version 3.5.6 should not be persisted (for example, stored to a file) by a WebSphere Application Server Version 3.5.6 client, unless the client is part of the same naming domain which created the Handle to the entity bean or the EJBMetaData.

These fixes are designed to be put on in a rolling wave fashion. Before turning on the com.ibm.websphere.container.portable property, make sure that all clients to this server are at WebSphere Application Server Version 3.5.6 or WebSphere Application Server Version 4.0.4.

In doing so, you can first update your client machines, and then update your server. Finally, when your configuration is set, you can enable the property and the new function, thus avoiding a shutdown of the entire network to do the upgrade.

To set the property:

On WebSphere Application Server Version 3.5.6:

  1. Stop the application server.
  2. Add -Dcom.ibm.websphere.container.portable=true in the command line arguments box.
  3. Click Apply.
  4. Restart the server.

On WebSphere Application Server Version 4.0.4:

  1. Stop the application server.
  2. Add the system property com.ibm.websphere.container.portable and provide the value true under the servers JVM Settings.
  3. Click Apply.
  4. Restart the server.

A final reminder, unless you are having a interoperability problem with the above conditions, do not turn on this property for your servers.

WebSphere Application Server Enumerations and Collections cannot be used outside the transaction (Defect 110799.RN)

WebSphere Application Server Enumerations and Collections cannot be used outside the transaction they were created in. Once you have enabled the property com.ibm.websphere.container.portable, additional checking occurs, to determine if two transactions attempt to access the same Enumeration or Collection instance.

In the unlikely event this occurs, an EnumeratorException is thrown.

In addition, once the transaction ends, a lazy collection or enumeration is disconnected from the server. In the event that the enumeration or collection attempts to access additional elements, by contacting the server after the transaction has ended, a com.ibm.ejs.container.finder.CollectionCannotBeFurtherAccessedException is thrown.

Back to interoperability
Back to possible problems and suggested fixes

National Language Version Issues/Limitations

Read the problems and fixes that apply to your language:

All languages

Some data files and echo statements are not translated (109412)

Data files that contain the information for the default and sample configurations are not translated in this release. For example, objects such as Default Server and Sample DB Driver will have English names and descriptions even in non-English locales.

The echo statements from batch files and shell scripts (for example, ejbdeploy and adminclient) also are not translated.

Application client available in English only (109769.RN)

This release of WebSphere Application Server provides the English (en_US) installation of the application client (Java 2 Platform, Enterprise Edition (J2EE) client and Java thin client) only.

Install EnterpriseApp page is corrupted on AIX (103245, 104865)

On AIX and for Korean and other languages, some WebSphere Application Server pages could be corrupted. To fix the page display, clear the Auto-select in the View > Encoding menu option of Microsoft Internet Explorer browsers or the View > Character Set option of Netscape browsers.

Double-byte character set (DBCS) languages

True type font and input method needed for WebSphere Application Server Advanced Edition for Linux on zSeries (116080.RN, 116213.RN)

Before installing WebSphere Application Server Advanced Edition for Linux on zSeries (390) onto a Linux for z390 distribution, ensure that True type font and Input method are available on your distribution for your double-byte character set (DBCS) locale.

If you have CD-ROMs for the WebSphere Application Server Version 4.0.1 and Version 4.0.2 for Linux on zSeries releases, you can access the administrative client remotely by doing the following:

  1. Install WebSphere Application Server Version 4.0.2 for Linux on zSeries in the single-byte character set (SBCS) locale.
  2. Start the administrative server of the Linux on zSeries product.
  3. Install WebSphere Application Server Version 4.0.1 on an AIX, Solaris Operating Environment, or Windows NT operating system.
  4. Access the administrative client remotely by running the command 
    adminclient host_name_of_Linux_on_zSeries_machine

Note that the Turbo Linux 6.5 for z390 distribution does not support DBCS.

Must have appropriate TTF files installed for national language versions (109281.RN)

If you are using one of the supported double-byte character set (DBCS) locales, one of the following file sets is required:

AIX:

X11.fnt.ucs.ttf (for ja_JP or Ja_JP)
X11.fnt.ucs.ttf_CN (for zh_CN or Zh_CN)
X11.fnt.ucs.ttf_KR (for ko_KR)
X11.fnt.ucs.ttf_TW (for zh_TW or Zh_TW)

Solaris Operating Environment:

SUNWjxcft, SUNWjxmft (for ja)
	SUNWkcoft (for ko)
	SUNWgttf  (for zh_GBK)
	SUNW5ttf  (for zh_TW.BIG5)
German

Update to advanced properties for Lightweight Directory Access Protocol support help file (PQ68073)

The German version of the advanced properties for Lightweight Directory Access Protocol (LDAP) support help file is back level. To access the latest level, see the InfoCenter article 6.6.18.0.9: Advanced properties for LDAP support. To correct the file level accessible from the product interface, replace the version of the help file located in product_installation_root/web/InfoCenter/was/060618009.html. For example, C:\WebSphere\AppServer on the Windows NT platforms.

Japanese

Japanese characters handled incorrectly on AIX (108861)

If you are running WebSphere Application Server on an AIX machine, true type fonts (TTFs) must be installed for the characters to display properly. These fonts are not installed automatically with AIX default installation.

Non-Latin characters in class names

Renaming the non-Latin characters in class names (Defect 121780.RN)

Using non-Latin characters in class names results in an org.omg.CORBA.NO_IMPLEMENT error.

When server side enterprise beans contain non-Latin characters in class names and a client tries to invoke a remote method requiring a class with class name having non-Latin characters to be loaded, the client program receives the error: 

java.rmi.ServerException: RemoteException occured in server thread; nested exception is: 
   java.rmi.RemoteException: org.omg.CORBA.NO_IMPLENT: Unable to locate value class <DBCS class 
   name>

To work around this problem, rename the classes to make sure that there are no Latin characters in the class name. Regenerate and re-deploy the application.

Simplified Chinese

Modify the converter.properties file for Chinese Solaris Advanced Single Server Edition (109497)

If you are installing WebSphere Application Server Advanced Single Server Edition on the Solaris Operating Environment (Simplified Chinese Only), change the GB2312 key in the converter.properties file from Cp1386 to GBK to avoid corruption on the administrative console. The converter.properties file is located in the following directory: WebSphere/AppServer/properties.

Traditional Chinese

Traditional Chinese characters display improperly on UNIX (109349, 109349.RN, 109794)

When installing on UNIX, certain traditional Chinese characters are not displayed properly due to a IBM Software Development Kit 1.3 product limitation. Some characters are displayed wrong or are unreadable.

Back to national language version issues/limitations
Back to possible problems and suggested fixes

Prerequisite products restrictions

Information about Xalan Version 2.2 (Defect PQ68660.RN)

Xalan Version 2.2 is shipped with WebSphere Application Server Version 4.0.3, Version 4.0.4, and Version 4.0.5. Xalan Version 2.2 performance is slower than Version 2.1, and it uses 3 to 5 times more memory than Version 2.1. Refer to fix PQ68660 for more information.

Back to Prerequisite products restrictions
Back to possible problems and suggested fixes

InfoCenter

Correction to InfoCenter article 6.6.13.0: Properties of tranports (PQ74464)

The following information in the InfoCenter article 6.6.13.0: Properties of transports is not true:

The value of this property, after it is specified for the first transport, will be applied globally to all other HTTP transports in this administrative domain.

Back to InfoCenter
Back to possible problems and suggested fixes