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

Last updated: 09/30/2002

This document contains the Release Notes for the WebSphere Application Server Advanced Single Server Edition Version 4.0 FixPak 4 (4.0.4) and Advanced Edition Version 4.0 FixPak 4 (4.0.4). Please note that WebSphere Application Server Release FixPak 4.0.4 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.4

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.4

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


Installing Version 4.0.4

Complete installation instructions for Version 4.0.4 are included in the README file shipped with the FixPak install code. Please read the README file before installing Version 4.0.4. Note that FixPaks are cumulative and contain all updates and fixes shipped in previous FixPaks.

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


Documentation for Version 4.0.4

The documentation for Version 4.0.4 supplements the Version 4.0 WebSphere Application Server InfoCenter, which is at http://www.ibm.com/software/webservers/appserv/infocenter.html. Topics covered in the Version 4.0.4 documentation include:

Note that, for this release, the InfoCenter has not been updated. The Version 4.0 InfoCenter remains the most current version. The documentation provided with this release adds to or corrects portions of the Version 4.0 InfoCenter.


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

Windows2000

Windows NT

Regenerate plug-in configuration after installing WebSphere Application Server FixPaks (Defect PQ61587)

After you install a WebSphere Application Server FixPak, you need to regenerate the plug-in configuration. Before you begin, ensure that your hardware and supporting software requirements meet prerequisites for the FixPak. 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 FixPak using the instructions in the README file that accompanies the FixPak downloadable files.

To regenerate the configuration, complete the following steps:

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

When you have a plug-in and a Web server only installed on your machine, an IBM Software Development Kit must be installed on your machine in which the FixPak will be installed. When WebSphere Application Server Version 4.0 installs the plug-in, it will not install the IBM Software Development Kit. The FixPak install uses Java, 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 FixPak 4, you must also upgrade your IBM Software Development Kit level. Select Yes to upgrade the IBM Software Development Kit level.

Installing an alternate IBM Software Development Kit (Defect 120897)

If you want to use an IBM Software Development Kit other than the one provided with the WebSphere Application Server product, select custom install on the installation panel. On the Choose Application Server Components window, ensure that IBM JDK 1.3.0 is not selected and then click Other JDK. Select the JDK that you want to use from the list. It is very important that you deselect the JDK box, otherwise the JDK provided with the product is installed.

If you want to use an alternate IBM Software Development Kit when applying FixPak 4, specify the IBM Software Development Kit to use during installation of the FixPak or set the system environment variable, JDK_UPDATE_HOME, to point to the directory of the IBM Software Development Kit to update.

Interrupted install may cause reinstall and uninstall to fail (Defect 125711.RN)

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

Note that if you run the uninstall_ptf_4.sh or uninstall_ptf_4.bat from the <was_root> directory, the uninstall will default to using whatever backup .jar files it finds there unless you direct it to look someplace else. An example of what the backup .jar files are called are ihs_ptf_4_backup.jar, jdk_ptf_4_backup.jar, J2C_ptf_4_backup.jar, and was40_ae_ptf_4_backup.jar.

See the README file for detail installation instructions.

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 may require that the administrative server be cycled.

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

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

Note that an LDAP cluster is defined as multiple LDAP servers which appear to be a single LDAP server due to the use of a network dispatcher or IP sprayer.

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

Installation of a FixPak 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 install and uninstall 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 J2EE tag sequence standard (they may not work or may 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 Java server page (JSP) element tag like name, tag class, teiclass, body content, information, attribute*. for WebSPhere Application Server Version 4.0.3 and above need to follow the standards defined in the URL http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd.

Installing the Advanced Edition into the same directory as the 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 uninstall program, because it will uninstall 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 will be lost. If you plan on manually migrating any of your property files, you should back up the Advanced Single Server Edition property files before installing the Advanced Edition.

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 that 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."

Apply e-fix PQ51387 in order 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 e-fix PQ51387 to your Version 3.5.x product. This e-fix is available at http://www.ibm.com/software/webservers/appserv/support.html.

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

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 will not be 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

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

During the installation of the FixPak, you must choose Yes to upgrade the 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 will not cause any problems.

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

The WebSphere Application Server J2EE Application Client runtime (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 runtime 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 runtime 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 runtime 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 may 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 the WebSphere Application Server.

Compatibility library must be installed 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. This 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 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. Configuring the Data Source for 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.
    5. Under Properties, do the following:

        a. Type a name for your data source. The name will be 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 to use 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.
    6. Click Resource Properties
      • New serverName
        Use these values in the property sheet (the rest can be left blank):

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

        Note: servername is the actual hostname.

        Click OK on the Resource Properties: serverName panel.

      • New portNumber
        Use these values in the property sheet (the rest can be left 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 (the rest can be left blank):

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

        Click OK on the Resource Properties: disable2Phase panel.

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

C. Configuring WebSphere Application Server Advanced Edition in order to use SQL Server with Type 4 Driver as administrative database.

The following document describes how to configure WebSphere Application Server Advanced Edition in order to use SQL Server with Type 4 Driver as administrative database.

  1. Install WebSphere Application Server Version 4.0.1 with DataDirect as database type then apply FixPak 4 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").

  6. Add one line at the end of the admin.config file: com.ibm.ejs.sm.adminServer.dbselectMethod=cursor.
  7. Update the initial_setup.config file:
    Change value:
  8. Start WebSphere Application Server and the administrative console.
  9. In order to run sampleApp application successfully, you must do 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 General:

    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 Nodes:
    1. Click Install New.
    2. Select a node in driver files.
    3. Type the JDBC driver files's 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 General:
    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 "Test Connection Successfully" shows up, creating new datasource is successful.
    f. Click OK.

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 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/output exception thrown from the client side IBM Software Development Kit; furthermore, these properties are different from com.ibm.CORBA.requestRetriesCount and com.ibm.CORBA.requestRetriesDelay. You might need to use all four of these properties to tune you client application and/or application server.

Enable in-process transaction logging in the WebSphere Application Server, Advanced Edition (Defect 144808)

You can improve the throughput of WebSphere Application Server, Advanced Edition servers that make heavy use of two-phase commit 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 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.

UNIX

Informix and setting the DBHome property on UNIX

When you are installing WebSphere Application Server, using either the install program or a silent install using a response file, you are instructed to enter the path of the directory containing the database software for DBHome. This value does not work if you have chosen Informix as your administrative database. Enter the path of the directory containing the Informix Type 4 JDBC driver for DBHome field, rather than the path to the directory containing the database software.

UNIX

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

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

WebSphere_installation_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 will receive errors for some of the installed files. These errors do not affect the installation, running and uninstallation of the product.

AIX

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

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

To work around this error condition, do one of the following:

AIX

Netscape browser needs upgrading after APAR IY19277 is applied on AIX (108934)

After you install WebSphere Application Server and all of its prerequisites on AIX, Netscape Communicator 4.73 (or older) may not start. The following error message will indicate 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, you may need to 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 may not be able to do it yourself because of lack of write permission to the Netscape directory. If this is the case, contact your AFS/DFS administrator.

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

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

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 (filesets) HWEnable11i_11.11.depot and PHKL_25368 to run DB2 properly with WebSphere Application Server. However, even with the filesets 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

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

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

export SHLIB_PATH=/usr/lib

HP-UX

IBM HTTP Server did not correctly install on HP-UX due to low space on /usr (109630)

If your /usr partition is full, and you cannot find the IBM HTTP Server config file when installing Websphere Application Server with IBM HTTP Server and the IBM HTTP Server plug-in, there might have been a problem installing IBM HTTP Server. Check /tmp/install.log. If you see a failure with the install_ihs_128.sh script, please check /var/adm/sw/swagent.log for errors. In that file, you will find a detailed error of what went wrong. IBM HTTP Server installs a 4 kilobyte file in /usr. Due to the way HP handles their partitions, you might have one megabyte of space left in /usr, and the IBM HTTP Server installation will still fail. If swagent.log says you are out of room in /usr while trying to install IBM HTTP Server, you will need to extend the /usr file system by the amount defined in /var/adm/sw/swagent.log. Once that is done, start the WebSphere Application Server installation again, and select IBM HTTP Server, and the IBM HTTP Server plug-in to install.

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.4. Several files need to be modified 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, the Sybase database to be used as the repository should already be created.
  2. During installation of WebSphere Application Server Version 4.0.1 you will not have a Sybase selection to choose from during database selection, therefore, you need to select another database, for example DB2. For the database name, specify the database that you created for WebSphere Application Server. For the database home, choose the directory where Sybase was installed, for example, /opt/sybase12. For user ID and password, choose a database administration user ID and password for the database that you are using. Continue on with the installation.
  3. After installing WebSphere Application Server Version 4.0.1, install FixPak 4 before attempting to start the administrative server. After installing FixPak 4 but before trying to start the administrative server, modify three files in the <was_root>/bin directory. The three files are:
    admin.config 
    setupCmdLine.sh
    startupServer.sh.

    Refer to following instructions to modify the three files:

    a. admin.config

    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 JDBC library. Right after /opt/WebSphere/AppServer/lib/ext is the JDBC library that WebSphere Application Server will use to find the classes it needs. Whichever directory is specified there needs to specify the Sybase directory, such as /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. setupCmdLine.sh

    The following environment variables need to be changed to:

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

    c. startupServer.sh

    The following "else if clause" needs to be added to the section where the script checks to see what database type has been specified.

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

    then

    {
    DB_CLASSPATH=$DB_INSTANCE_HOME/jConnect-5_2/classes/jconn2.jar
    }
    
  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 <was_root>/bin/admin.config and add com.ibm.ejs.sm.adminServer.dbconnectionProperties=CHARSET=utf8;SELECT_OPENS_CURSOR=true where utf8 is the charset that you want to specify.

To the above setting, specify CHARSET_CONVERTER_CLASS=com.sybase.jdbc2.utils.TruncationConverter.

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, the application server database must be created 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, WebSphere Application Server administrative database should be created on a remote database server to facilitate better longrun 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.

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 always:

 "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 should then be 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 in order 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 check 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 SSL 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 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 that you can use the Java thin driver only and any attempts to use the OCI (thick) driver will result in errors. For more information on the problem, contact Oracle Technical Support.

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

Due to a Linux kernel defect in kernels less that 2.4.10, the floating stack support in the IBM Software Development Kit does not work correctly on SMP machines. To apply WebSphere Application Server Version 4.0.4 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 export LD_ASSUME_KERNEL=2.2.5 That variable enables a modification made by RedHat to disable floating stack support and thus allowing the IBM Software Development Kit to work to default to a non-floating stack mode which will work on pre 2.4.10 kernels. Please note that 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.

Solaris

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 install option panel gets hidden behind the Installation Window. This is a known problem with motif in Solaris and IBM Software Development Kit window tooling.

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

Solaris

Exception returned at startup on Solaris 2.8 with Domino Web server and the plug-in configured for SSL (106012.RN)

On Solaris 2.8 systems running the Domino Web server with the plug-in configured for SSL, the server will have an exception at startup. This results from some incompatibilities with Domino and C++ code.

Solaris

Installing DataDirect Sequelink server on Solaris (109652)

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

This script assumes that this module is available on every Solaris 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.

Windows 2000
Windows NT

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

You cannot install WebSphere Application Server Version 4.0.1 full install 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 FixPak 4 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 click Manage. Under the Java tab, uncheck 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

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

If you attempt to access http://<hostname>/WSsamples/index.html when using a Domino Web server, you will 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 setup: URL > Directory
    b. Under Site Information:
    IP Address: your Web server's hostname or IP address
    c. Under Mapping:
    Incoming URL string: /WSsamples
    Target server directory: <WAS_HOME>/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://<hostname>/WSsamples.

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

Windows 2000
Windows NT

WebSphere 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 SSL. After adding the path, reboot your system so the plug-in will load into the Web server properly. Typically, 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
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 will use and that the ID's user rights 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.

UNIX
Windows NT
Windows2000

Set FORCEJ2C=true on silent installs to install the J2C updates (Defect 141771.RN)

When installing the Connector Architecture (J2C), the installer checks for the existence of the j2c.jar in the JDK_UPDATE_HOME/java/lib directory when it should check in the WAS_UPDATE_HOME/lib directory. The interactive installation of FixPak 4 will still install the J2C update, however the logs that are displayed will be wrong. The installer will display that it could not find the j2c.jar file but then it will ask you if you want to install the Connection Architecture for WebSphere Application Server. If you choose Yes then the J2C will be installed properly under the WAS_UPDATE_HOME/lib directory. On silent installs, you must set the FORCEJ2C system variable to true or use the -Connector command line option in order to install the J2C update.

The syntax for the command line should be:

Back to Installation and configuration
Back to Possible Problems and Suggested Fixes


Uninstallation

Preserving applications before uninstalling FixPak 3 (116929.RN)

If you install applications into the WebSphere Application Server Advanced Single Server Edition after installing Version 4.0 FixPak 4 and later uninstall FixPak 4, the server-cfg.xml file will be restored to the configuration existing prior to the installation of FixPak 4 and you will not be able to use your applications. To preserve your applications added after the installation of FixPak 4, do the following:

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

Remove Java Virtual Machine Java2 properties from the server if you uninstall FixPak 4 (117124)

If you uninstall FixPak 4 of WebSphere Application Server Version 4.0 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 FixPak 2 or FixPak 3 and only removed FixPak 4, then you do not need to make these changes and the Java2 security enabled servers should start normally.

Log in as root before uninstalling on Linux (104863.RN)

If you attempt to uninstall the WebSphere Application Server on a Linux machine 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 may 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

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 Advanced Edition (running WASPostUpgrade manually), an error is logged by XMLConfig.

This condition causes WASPostMigration to report an error and the transport plugin information will not be generated. However, all migration configuration has been imported successfully. Check to see if the duplicate alias information is indeed a problem and if so, correct it. Perform GenPluginCfg by hand 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 node's dependent class path entries to each application server's class path (Defect 123015.RN)

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

Applying e-fix to enable the Object Request Broker (ORB) 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 may 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 e-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 be able 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 e-fix for WebSphere Application Server Version 3.5.5 is PQ60335. The e-fix for WebSphere Application Server Version 4.0.1 is PQ60336. The e-fix for WebSphere Application Server Version 4.0.2 is PQ60336.

The e-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 that this applies to the IBM Software Development Kit on all operating systems except Solaris.

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

If the following error messages are found in the WASUpgrade.log 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 will 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 (JSPs), 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 classpath 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 being copied over into the WAR file.

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

Perform either of the following methods when migration has been run and servlet classes, Java servlet pages (JSPs) , 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 classpath 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 .war file's class or lib subdirectory. Included in the copying are any files that multiple Web applications use that are centrally located, provided that the files are included as a classpath path entry of the Web application.

For example, if a Web application has the following classpath 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>

FixPak 2 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 Web Module's extension (ibm-web-ext.xmi) additionalClassPath attribute based on each Web application's classpath 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 Web Module's additionalClassPath attribute based on each Web application's classpath entries.

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 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)

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

Please 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 will be ignored if they are specified.

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

After migration, you will need to manually update each clone to set these types of server group properties. Each clone will have their 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 install process, restore the above mentioned directories back to the Advanced Edition install directory.

Back up sas.server.props 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 /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 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. This file can then be used as a record of the original values in the installed admin.config file.

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

When migrating from 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 Release 3.x to Release 4.0.x while running the installation program and a severe error occurs while saving the existing Release 3.x environment, perform the steps below to migrate the Release 3.x configuration. Note that 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 migration_temporary_directory.
  3. Invoke the WASPreUpgrade file by issuing the following command:
    waspreupgrade c:\backup_directory c:\current_3.x.x_WebSphere_directory nodename

    where nodename is the adminNodeName. Note that in some cases the waspreupgrade command may not be totally successful. To ensure that a valid configuration has been 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:

    xmlconfig -export c:\backup_directory\websphere_3x_backup.xml -adminNodeName nodename
  4. After the preceding step completes, shut down the WebSphere 3.x.x Administrative Server.
  5. Run the WebSphere 4.0.1 Application Server 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 4.0.1 WebSphere directory.
  7. Invoke the WASPostUpgrade file by issuing the command following.
    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 may occur after migrating a configuration from Release 3.x to Release 4.0.x relating to the JDBC Driver configuration. The problem shows up with an error message similar to--

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

This 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 Release 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 Release 4.0.1, the original directory names are used instead of the new data store version.

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

To correct the problem on the Advanced Single Server Edition, modify the server configuration file in the config 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 may occur if you migrate and use the same directory structure. As to Windows NT, an old copy of db2java.zip 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 in the WebSphere lib directory.

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

When migrating a multi-node model-clone domain to WebSphere Application Server 4.0.x, the following error will be displayed 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 will be 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 steps such as the following (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 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.

Duplicate entries error resulting from migrating multiple ports (110185.RN)

An error might occur if multiple ports are migrated for the same application server. Ports with duplicate entries might result. Use the administrative console to modify the port values in the Web Services settings.

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

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

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

NoResourceException error returned after completing migration (105675.RN)

If the following error is seen after completing migration, the server-cfg.xml file will not match up with the EAR file directories included in the installedApps directory:

Exception - No resource for object: com.ibm.ejs.models.base.config.applicationserver.impl.WebModuleRefImpl    
(uri: ChainTest.war)  com.ibm.xmi.base.NoResourceException com.ibm.websphere.migration.exceptions.
WASUpgradeInternalErrorException: MIGR0228E: Unable to save configuration files.

To correct this problem, manually delete any EAR directory found under the installed application directory that is not listed as an installedApp in the server-cfg.xml file.

To run WASPostUpgrade more than once after migration has completed successfully and EAR files have been installed in the installedApps directory including a DefaultApplication.ear, the DefaultApplication.ear must be uninstalled before invoking WASPostUpgrade. No other .ear files must be uninstalled.

To uninstall the DefaultApplication.ear, do the following:

  1. Start the administrative console and expand the tree on the left side of the console to locate Nodes -> localhost -> Enterprise Applications.

    The term localhost might be localhost or the host name of the machine on which the product is running.

  2. Click Enterprise Applications.
  3. Select DefaultApplication by clicking the check box to the left of it.
  4. Click Uninstall displayed above the list of installed applications.
  5. Click Uninstall again, as you do not want to export the application before uninstalling it.
  6. Follow the instructions on the resulting task wizard for uninstalling the DefaultApplication.
  7. Verify that the DefaultApplication has been removed from the list of applications located at Nodes -> localhost -> Enterprise Applications.
  8. Stop the server.
  9. Manually delete the DefaultApplication.ear directory found under the installedApps directory.
  10. Invoke WASPostUpgrade from the command line.

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

Examine the properties files trustedservers.properties and webseal.properties installed with WebSphere Version 4.0 FixPak 4. With FixPak 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 FixPak. 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 WebSphere_installation_root\classes directory and the property files associated with your interceptor are in the WebSphere_installation_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 SSL between WebSeal and HTTP server is supported in WebSeal Version 3.7. Ensure that SSL is set up correctly. WebSphere does not validate the mutual SSL setup.

Applying 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.0 with FixPak 3 and above provides a new command line parameter to the WASPostUpgrade file called -documentRootLimit. This parameter allows you to specify the number of files that the migration tool will copy from under the document-root into the WAR file. The value specified should be a valid integer greater than -1. The documentRootLimit would apply to all Web applications included in the websphere_3x_backup.xml file. If no value is specified, the default will be 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 J2EE application called DefaultApplication during migration.

In FixPak 4, 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 4.0.x on AIX 4.3.2.0 (110827)

Websphere Application Server 4.0.x will not run on AIX 4.3.2. Upgrade to AIX version 4.3.3 before migrating to WebSphere Application Server 4.0.x.

Linux

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

When migrating from version 3.02 on Linux, an error may 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 3.02 XMLConfig.sh file in the bin directory. To complete the migration, JAVA_HOME must be set to a valid value. Modify the JAVA_HOME setting in the WebSphere 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 3.5.3 to 4.0.x on Linux (110018)

The format of the Systems Management database has changed significantly between release 3.x and release 4.0.x. If the database name that will be used for release 4.0.x is the same as was used for release 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

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

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

Solaris

Migration consideration on non-English Sun Solaris machines (109062.RN)

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

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 the Advanced Single Server Edition will 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 will 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 before making any manual changes.

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

WebSphere Application Server will fail to start if certain ports are in use. When the bootstrap port is in use, you may see the error below 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 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 WebSphere_installation_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 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 of the administrative repository, the administrative server fails to initialize and returns NumberFormatExceptions when started (111582.RN)

After you create the administrative repository database, you should 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. You 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 will 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 commands below (as described in the InfoCenter) were executed previously to configure DB2, the administrative server should start successfully when first started.

4. 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 accidently again, add the above three lines of commands to the db2profile (assuming the db2profile is sourced using .profile) to ensure the variable is always valid.

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)

FixPak 3 for WebSphere Application Server Version 4.0 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 JVM Setting panel. The only way to remove the properties is to delete the appropriate name-value pair and then select Apply.

Log Analyzer help must be accessed using the operating system's default Internet browser 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 Log Analyzer using the operating system's default Internet browser, even though in the tool's Preferences dialog 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 Log Analyzer using any Internet browser, such as Netscape Navigator, by explicitly setting the location of the browser's executable in the tool's 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, select File > Preferences.
  2. In Analyzer Preferences dialog, select Help entry under General folder.
  3. Set the path to the Internet browser's executable in the Browser Location field.

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

EARExpander no longer collapses utility JAR or Zip files starting at Version 4.0.2 and above.

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

UNIX

Accessing help on UNIX platforms (Defect 110186.1)

If you receive the following message after requesting help on a UNIX platform, your locale may 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.

There are two work arounds for this problem. You can either set your locale in the shell where your administrative console is launched, or you can launch a Netscape browser window before accessing help.

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. The locale can be set permanently in the user's profile.

This problem is common on HP-UX and Solaris but may 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 +

Back to Administrative console (GUI) and command line tools
Back to Possible Problems and Suggested Fixes


Application server

All operating systems

Solaris

Application classloaders changes (Defect 120343.RN)

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

Application servers that have a Module visibility setting of MODULE can hang during startup or runtime

Application servers that have a module visibility setting of MODULE can hang during startup or runtime. Restarting the application server may circumvent the problem. To avoid the problem completely, change to use a Module visibility setting of APPLICATION, SERVER, COMPATIBILITY, or J2EE.

Corrections to classloader (Defect 142420)

The following document states the corrections to classloader:

  1. All references to /QIBM/ProdData/WebASAdv4/ should be changed 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 customize Dr. Admin ports for the application servers by adding -DdiagThreadPort=xxxx command line argument to the application server Java Virtual Machine.

Solaris

Passing an appropriate maximum permanent heap size value to Java Virtual Machine in order to avoid an application server crash (Defect 131470.RN)

On Sun Solaris platforms, an application server may crash while under stress with a "java.lang.OutOfMemoryError", which is visible in the application server's stderr.log file.

To prevent this error, an appropriate maximum permanent heap size value must be passed 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 tab.
  3. Click Advanced JVM Settings.
  4. Enter -XX:MaxPermSize=64m in Command line arguments.
  5. Click OK.
  6. Click Apply.

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 AAT used for editing and verifying J2EE archives uses custom class loaders for Java reflection within the archive. In some situations, the class loader behavior in 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.

Typically, these class loading errors result from one of two problems:

To avoid the class loading errors, correct the above 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 webModule 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 new application window tree node.

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

When starting the Application Assembly Tool of the WebSphere Advanced Edition by entering assembly.sh on AIX, a java.lang.OutOfMemoryError exception may 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 then click Help, to start a new Netscape session. You can then view the Help text.

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 and/or the application.
  2. Update the class file.
  3. Start the module and/or the application.

Changes made to Connection Pooling (Defect 120566)

A significant performance improvement was introduced in WebSphere Application Server Version 4.02, 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 FixPaks, 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 1 per connection is allocated. For example given 100 Prepared Statements, and 50 connections, you will have 2 per connection, and given 10 Prepared Statements and 50 connections, you will have 1 per connection. You may 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 V4.0, the statement cache size can be set from the Connection Pooling tab of the DataSource, 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 will upgrade the isolation level to Serializable as a safe option. However, Oracle has a restriction that XA cannot run with serializable. The following error message will appear in the Oracle traces:

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

WebSphere Application Server will throw 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 resembling the following:

Compiling content of ejbModule/com/ibm/ejb/cb/samples/big3/tier2
  (12 problems found) Copying all resources on the classpath
  (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 deploy 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 ejb-jar.xml and add the <primkey-field> elements.

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

A javax.ejb.FinderException can occur 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 that 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 above 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 Application Assembly Tool's tree view 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

Adding additional default Signer Certificates when upgrading to GSKIT release 4.0-3.116 (Defect 129095)

When upgrading to GSKIT release 4.0-3.116, the following additional default Signer Certificates will be added to the IKEYMAN database if one is newly created:

Verisign Class 1 CA Individual Subscriber-Persona Not Validated
Verisign Class 2 CA Individual Subscriber-Persona Not Validated
Verisign Class 3 CA Individual Subscriber-Persona Not Validated

If you have a valid certificate that is in the same category as one of the above default certificates, then you need to remove the default certificate before you try to install your certificate.

Using ./startupServer.sh to start the administrative server (Defect 119945.RN)

If you use WebSphere Application Server Advanced Edition and enable global security on an HP platform, start the administrative server using the ./startupServer.sh script (not the ./adminserver.sh script). In some cases, using the ./adminserver.sh script causes the administrative console to hang.

Assigning a large number of users or groups to a role might fail (103028.RN_1)

Assigning a large number of users or groups (greater than 5000) to a role might fail (in the Security Center).

When possible, assign roles to groups. There typically are fewer groups than users. Also, this will improve performance during server startup and during the authorization check.

Changes made to sas.server.props may be overwritten at run time (103028.RN_3)

SSL settings are managed by the administrative console. Any editing changes made to the following properties in sas.server.props will be overwritten at run time.

Security involving multi-nodes need similar time zones (108811.RN)

After you enable security, you cannot access enterprise java beans (EJBs) spread across other nodes. The error throws authorization failed exceptions and CORBA TRANSACTION_ROLLBACK exceptions. To work around this problem, ensure all the nodes involved are in the same time zone.

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

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

Native libraries for cryptographic devices must be re-extracted (Defect 121813.RN)

If you have been using Cryptographic Devices on WebSphere Application Server FixPak 4.0.3, you must redo the steps described in $WAS_HOME/java/docs/jsse/readme.jsse.ibm.html in order to update the native libraries to the latest level after installing FixPak 4.0.4. This process is required due to an update to the JSSE level included with this FixPak.

Specifying fully qualified domain name when using Lightweight Third Party Authentication for authentication (Defect 122469)

When using Lightweight Third Party Authentication (LTPA) for authentication, the cookies are set with a domain name and a URL without fully qualified host name will not receive this cookie. Hence, the form based login will take you back to the login screen. Make sure to specify the domain name as http://server.ibm.com in the URL.

Connecting WebSphere Application Server to a local Active Directory over Secure Sockets Layer (Defect 138353)

When trying to update WebSphere Application Server to use the Secure Sockets Layer (SSL) port (usually 636), you will get authentication errors in the administrative console after clicking Apply to update security configurations in the security center.

These errors occur because of a known Microsoft problem that prevents WebSphere Application Server from connecting over SSL with Active Directory when Active Directory is remote. Refer to Microsoft article Q320711: Accessing Active Directory with Lightweight Directory Access Protocol (LDAP) by Using Sun JNDI Calls May Not Work.

Alternatively, WebSphere Application Server can connect if it is running on the same machine as Active Directory.

To connect WebSphere Application Server to a local Active Directory over SSL, follow these steps:

Preliminary steps:

  1. Follow the steps in Microsoft article Q247078: How To: Enable Secure Socket Layer (SSL) Communication over LDAP for Windows 2000 Domain Controllers.
  2. Search Active Directory from the same machine that Active Directory is installed using Find People task in the Windows Address Book. You should be able to successfully search either on Port 389 or Port 636. If you cannot perform a successful search, see the following Microsoft articles

WebSphere Application Server steps:

  1. Create a user in Active Directory called "AdminUser". This user is a member of Administrative and Domain Administrator groups.
  2. Shut down and log off the Active Directory machine. Restart and log in as "AdminUser".
  3. On the Active Directory machine:
    a. Install DB2 7.2, FixPak 7
    b. Install WebSphere Application Server Version 4.0.1
    c. Install WebSphere Application Server Version 4.0.4
  4. Export the certificate created for the domain controller with the Windows Export Wizard. Export in Binary-64 format.
  5. Open the IKEYMAN utility from the WebSphere Application Server menu.
  6. Open WebSphere Application Server dummy trust file from /WebSphere/AppServer/etc. The password is WebAS.
  7. Add the certificate to the Signer Certificates area.
  8. Save and close the file.
  9. Configure WebSphere Application Server to connect to Active Directory LDAP over port 389:
    a. Set the LDAP server to listen on Port 389 in Address Book.
    b. Enable Security under the Security Center general tab.
    c. Also under the Security Center general tab, click on default SSL configuration. Security level should be Medium.
    d. Set the Authentication mechanism to LTPA in the Authentication Mechanism tab.
    e. Set up your LDAP settings. Use "AdminUser" as both Security Center ID and Bind Distinguished name. For Active Directory, a Bind Distinguished name is necessary.
    f. Set the host name of the LDAP server.
    g. Set the base distinguished name of the LDAP directory.
    h. Do not select the SSL button yet.
    i. Click Finish and make sure the settings are updated.
    j. Test by stopping the administrative console and the administrative server. Make sure that when you restart the administrative server and administrative console, you are prompted and that you can access the console with the AdminUser" ID.
  10. Configure WebSphere Application Server to connect to Active Directory LDAP over port 636:
    a. Set the LDAP server to listen on Port 636 in Address Book.
    b. On the Authentication tab of the security center, set the port to 636.
    c. Click SSL.
    d. Click Enable SSL.
    e. Select Use Global SSL default configuration.
    f. Click Apply.
    g. Test by restarting the administrative server and administrative console. You should be prompted, and the 636 port will show in the Realm field of the login prompt.

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 LDAP security, set the default filter in Lightweight Directory Access Protocol (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 will fail and the existing server will appear 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 will still try to connect to the last known port of the restarted server, which will cause 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 will start 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 that the above configuration is not required if security is not enabled.

Authentication fails when user ID belongs to DBCS group name (Defect PQ61912, 139393)

When using WebSphere Application Server with login IDs containing at least one DBCS character, a property must be added to both the administrative server and the application server.

To add the property to the administrative server, edit file <was_root>/bin/admin.config and add line com.ibm.CORBA.ORBCharEncoding=UTF8

Complete the following steps to add the property to the application server:

  1. Select the application server you want to update.
  2. Select JVM Settings and then click Advanced JVM Settings.
  3. Add -Dcom.ibm.CORBA.ORBCharEncoding=UTF8 to the Command Line Arguments text field.

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

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

Other than these two combinations, the SSL enabled plug-in is otherwise supported on the AIX, HP, Solaris, Windows NT, Windows 2000, and Linux platforms for use with IBM HTTP Server, Apache HTTP Server, Microsoft IIS, Lotus Domino, and iPlanet Web Server.

UNIX

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

Domino server 5.0.9a Secure Sockets Layer connections may 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 will not allow all subsequent secure connections. This occurs when the Domino 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.

Back to Security
Back to Possible Problems and Suggested Fixes


Managing workload

Solaris

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 FixPak 4.0.2 and later FixPaks, the system properties has changed to a clone-only attributes. The system properties will not be propagated to the clones, but you can add or modify the properties in the clone attributes.


Web servers

All operating systems

Linux

Linux

Running with Extended Application Programming Interface (EAPI) 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.so

to

LoadModule app_server_http_module opt/WebSphere/AppServer/mod_app_server_http_eapi.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 may 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 SSL is used and the WebSphere Application Server is running (103882)

IBM HTTP Server might hang during initialization when it is configured for SSL and the Websphere administrative server is running.

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

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

If you install IBM HTTP Server with the WebSphere Java 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 in. Use a workaround for the appropriate platform to correct this problem:

AIX:

  1. Copy /usr/opt/ibm/gskkm/bin/gsk5ikm 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 /usr/WebSphere/AppServer/java/bin in your PATH environment variable.
  4. Execute the new copy of gsk5ikm.

Linux platforms:

  1. Copy /usr/local/ibm/gsk5/bin/gsk5ikm 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 /opt/WebSphere/AppServer/java/bin in your PATH environment variable.
  4. Execute the new copy of gsk5ikm.

iPlanet Web Server 4.1 does not serve WebSphere servlets on Solaris (104613)

When running the WebSphere 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 will restart.

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

On 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.

Add alias directive in httpd.confi of Apache Extended Application Programming Interface (EAPI) (Defect 140661.RN)

If using Apache Extended Application Programming Interface (EAPI) Web server, and you have trouble viewing the Samples Gallery, perform the following workaround.

  1. Edit httpd.conf under /apache_1.3.19_eapi/conf/ directory , and add alias /WSsamples "e:/WebSphere/AppServer/WSsamples" directive at the end of httpd.conf.
  2. Restart Apache EAPI Web server.
  3. Now you can serve http://<hostname>/WSsamples successfully.

Back to Web servers
Back to Possible Problems and Suggested Fixes


Working with HTTP servers

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 don't 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 will accept 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 will give an error during restart. To avoid entering an invalid value for the CookieDomain directive, use the Submit button in the form to submit the data.

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:

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 may see the following error message:

java.lang.NoSuchFieldError: batchReturn

This error is caused because of a mismatch of 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 classpath. 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 FixPak (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 FixPak SI02195. After applying the FixPak, 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 Solaris 8 with DB2 (110336.RN)

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

  1. Install the lastest 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 e-fix PQ51500.

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

db2390.sql script does not define an index for EJSADMIN.LOCK_TABLE (Defect 140436.RN)

The updated db2390.sql script provided with WebSphere Application Server Version 4.0.4 is incomplete. It does not create an index for EJSADMIN.LOCK_TABLE. The following needs to be added to the script in order for the administrative server to start properly when using DB2/390 as the repository.

CREATE TYPE 2 UNIQUE INDEX EJSADMIN.LOCK_IX ON 
EJSADMIN.LOCK_TABLE 
( NAME );
Informix

Identifying row locking in on-line transaction processing (OLTP) 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 on-line 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 (WLM) 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 activity.log files. The messages resemble the following:

Ignore these exceptions. Your server clones and application will 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 Solaris or Linux (105924, 105924)

If you are using connection pooling with Oracle on Sun Solaris or Linux, 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. Simply enter ulimit -n 2048 in the session where you will be running the application server.

It is also recommended on the Linux system that the JVM initial heap size and maximum heap size be set to 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.

Sybase

Specifying settings when using Sybase (Defect 119886.RN)

Modify the data source property to connectionProperties when using Sybase. Also specify the settings as SELECT_OPENS_CURSOR=true

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 e-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 button (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.

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 may 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 will occur for each cloned application server that fails.

Client Log:

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

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

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

Within the $WAS_HOME/bin directory, you will 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 classloader 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 same JVM, then the classloader that loads the client side components need to be the same as the one that loads the server side components. Otherwise, you may 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 classloader 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 will be 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/servlet) in one application server and deploying a server application (EJB) into a different application server.

Back to Java programming
Back to Possible Problems and Suggested Fixes


Working with sessions

Session sharing across Web applications is not supported on z/OS platform (Defect 150000.RN)

This FixPak introduces support for sharing HTTP session data among Web applications that are packaged in the same J2EE application. This feature is a value-add extension provided by WebSphere Application Server to the behavior that is prescribed by the servlet v2.2 specification. Currently, the feature is exclusive to WebSphere Application Server for multi-platforms. It is not currently supported on WebSphere Application Server for z/OS. Applications that take advantage of this extended feature will not be able to deployed to WebSphere Application Server for z/OS.

Accessing an HTTP session (Defect PQ47998.RN)

The release of persistent HTTP Session support in WebSphere Application Server 3.0 introduced HTTP Session transactions because the plug-in lacked an HTTP Session affinity mechanism. A transaction results from the use of a select and lock methodology when accessing the database from any WebSphere instance. As a result, only one servlet instance of execution can access an HTTP session at a time for the life of the service() method of the servlet.

This implementation had performance drawbacks, for example, most default database installations could not handle the high degree of locking. It also had stability issues, for example, any servlet hangs would lock up individual sessions, or the entire database. This implementation proved to be unusable with the introduction of the servlet 2.2 API and concurrent access requirements for HTTP session.

To solve this problem, HTTP Session affinity was added to the plug-in and the Select for Update option was removed.

You now have the option to turn on the locking behavior again. By default, locking still does not occur.

Now that all requests of a particular HTTP session route to a particular Java Virtual Machine (JVM), standard Java locking mechanisms, within a single JVM, can be utilized. These mechanisms synchronize servlet execution based on access to the HTTP session.

Three Java system properties exist to manage this behavior. Set these properties with the Java -D<system property=value> parameter on the command line option of an application server:

Using Java Transaction API for persisting sessions (Defect PQ49889)

The Java Transaction API (JTA)-enabled data source for the Session Persistence database is not supported.

No additional advantages exist for using JTA for persisting sessions.

Adding a system property to ensure session object is latest (Defect PQ50400.DOC)

A new system property has been added to ensure that the session object in cache is in sync with the session object persisted to the database. This is in addition to the cache ID mechanism used for the same purpose.

To apply this property follow these steps :

  1. From the administrative console, click Command Line Arguments for the Application Server, and then specify -DverifyDatabaseCopy=true. By default this property is set to false.
  2. Restart the application server.

Using a new system property in a multi-JVM environment (Defect PQ55940.doc)

Session ID can be shared across WebSphere Application Server in a multi-JVM environment without session persistence configured by using a new system property HttpSessionIdReuse.

Follow the instructions to apply the system property :

  1. Specify the property using administrative console.
    a. Expand Nodes under WebSphere Administrative Domain.
    b. Expand Application Servers.
    c. Expand Default Server.
    d. Expand Process Definition.
    e. Select JVM Settings, and then click on System Properties from the right panel under Advanced Settings.
    f. Click New button. Specify Name as HttpSessionIdReuse and Value as true. Click OK.
    g. Save the configuration changes.
  2. Stop the server.
  3. Start the server.

Provide session sharing across Web modules in an enterprise application (Defect 134211.doc)

WebSphere Application Server provides a new feature which you can use to extend the scope of the session to an enterprise application. For example, a session can be shared across all the Web modules in an enterprise application. This feature is provided as an IBM extension.

The steps to activate the feature are as follows:

  1. Create a file called sessionshare.xml file under the WebSphere-Root/properties directory.
  2. Add the following tags in the sessionshare.xml file :
    <sessionsharing>
      <EnterpriseAppnames> (Add Enterprise Application Display Names separated by commas) 
      </EnterpriseAppnames>
    </sessionsharing>
    
  3. Restart the application server. The Session Manager will read the sessionshare.xml file by default and enable the session sharing feature for the enterprise applications listed there.

Note that nothing additional needs to be done to enable this feature other than adding sessionshare.xml file and listing the names of the enterprise applications in it.

To use this service, all the Web modules in the enterprise application needs to be installed on the same server. Web modules in the enterprise application cannot be split by servers. For example, with an enterprise application containing two Web modules, you cannot use this service when one Web module is installed one server and the second Web module is installed on a different server. In such a split installation, applications might be able to share the session data across Web modules using persistent sessions, but session data integrity will be lost when concurrent access to a session is made in different Web modules. This will also severely restrict usage of some of SessionManger features like TIME_BASED_WRITES for write frequency.

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 will occur regarding the use of Enumerations and Collections returned by finder methods. Please 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 higher for WebSphere Application Server Version 3.5.x, or WebSphere Application Server Version 4.0.4 and higher 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 will result 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 above 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 will be able to 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 will be thrown.

In addition, once the transaction ends, a lazy collection or enumeration will be 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 will be 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.

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 (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 may be corrupted. To fix the page display, uncheck 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 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, 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 DBCS locales, one of the following filesets 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:

SUNWjxcft, SUNWjxmft (for ja)
	SUNWkcoft (for ko)
	SUNWgttf  (for zh_GBK)
	SUNW5ttf  (for zh_TW.BIG5)
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 in order 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 converter.properties for Chinese Solaris Advanced Single Server Edition (109497)

If you are installing WebSphere Application Server Advanced Single Server Edition on a Sun Solaris machine (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 will not be displayed properly due to a IBM Software Development Kit 1.3 product limitation. Some characters will be displayed wrong or will be unreadable.

Back to National Language Version Issues/Limitations
Back to Possible Problems and Suggested Fixes


InfoCenter

Update InfoCenter article 6.6.18.1a.7: Configuring SSL in WebSphere Application Server (Defect 117931)

New PMI client documentation in InfoCenter article 9.02 (Defect 121511)

Amendment to enable Java 2 security (Defect 125926)

Adding the new entries in InfoCenter article 6.6.46.0: Administrative server configuration file properties (Defect PQ58365)

Please manually modify the admin.config file by adding the following entries in InfoCenter article 6.6.46.0:

com.ibm.CORBA.requestTimeout=200

Value 200=3.2 minutes that is the time ORB will wait for a Reply to a Request.

com.ibm.CORBA.locaterequestTimeout=200

Value 200=3.2 minutes that is the time ORB will wait for the Location Service Demon (LSD) to send a Reply to a Locate Request that was sent by the ORB.

Note that if your network is subject to extreme latency, specify a large value to prevent timeouts. If you specify a value that is too small, timeouts may occur before a response is received.

Be very careful when you specify this property: it has no recommended value. Set it only if you suspect that you are experiencing problems with timeouts in the administrative server.

Update to Lightweight Directory Access Protocol server information in InfoCenter article 6.6.18.1.4a.4.1 (Defect 120011)

The following statement is additional documentation regarding Lightweight Directory Access Protocol (LDAP) server which will be documented in InfoCenter article 6.6.18.1.4a.4.1.

WebSphere Application Server only supports the configuration of one LDAP server. Any LDAP server failover mechanism has to be implemented outside of WebSphere Application Server and must be transparent to WebSphere Application Server.

Clarification about InfoCenter article 6.6.0.2.2.3: Authenticating to the administrative server (Defect 120014)

The following information is clarification about InfoCenter article 6.6.0.2.2.3: Authenticating to the administrative server.

Add the following line to your .wscprc file:
com.ibm.CORBA.ConfigURL=URL of properties file

An example URL is:

Windows Platform:
file:///C:/WebSphere/AppServer/properties/sas.wscp.props.

UNIX Platform:
file:///usr/WebSphere/AppServer/properties/sas.wscp.properties

Alternatively, you can add the following option to the Java command line (preceding the application class name):
-Dcom.ibm.CORBA.ConfigURL=URL of properties file

Additional information about InfoCenter article 5.1.4: The WebSphere delegation model (Defect 107449)

The following information has been added to InfoCenter article 5.1.4: The WebSphere delegation model:

When using VisualAge for Java (VAJ) to create enterprise beans the default value for the run-as model is system-identity. This might cause problems during authorization if client identity is assumed to be the default.

Correction to InfoCenter article 6.6.45.0.1: Modifications to Web server configuration files during product installation (Defect 122088)

InfoCenter article 6.6.45.0.1 states incorrectly what changes are made to iPlanet configuration in obj.conf when WebSphere Application Server Version 4.0.x iPLanet plug-in is installed.

The correct information is:

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="<WAS root>/bin/ns41_http.dll(.so)"
Init fn="as_init" bootstrap.properties="=<WAS root>/config/plugin-cfg.xml"
Service root=<iPlanet root>/docs fn="as_handler"

Correction to InfoCenter article 6.6.24.0: Administering application client modules (overview) (Defect PQ57752)

Single .class files are not supported within the files section at the .ear level in WebSphere Application Server Version 4.0.3. The tool that picks up these parameters and generates deployment code, EJBDeploy, does not have the ability to use loose class files.

The content of this section should be as follows:

For each enterprise beans .jar file in the .ear file, all the dependent classes must be in .jar files contained within the .ear file. The manifest file or a particular .jar must identify the .jars which contain the dependent classes. It does this using the class-path as described in article 6.6.24.0.

If the dependent classes are not in .jars already included in the .ear and are loose class files, they must be packaged into a .jar which must be included in the .ear. The enterprise beans .jar that needs these classes must identify this .jar in its class path.

Correction to InfoCenter article: Installing WebSphere Application Server 4.0 -- Typical installation option (Defect 120135)

When searching for Linux installation in the InfoCenter using the search page, the first entry is " Installing WebSphere Application Server 4.0 -- Typical Installation option." In step 6, it contains the following command:
# mount -t isso9660 -r /dev/cdrom /cdrom

The correct command is:
# mount -t iso9660 -r /dev/cdrom /cdrom

Correction to InfoCenter article: Download search-enabled InfoCenter as a .jar file and install locally (Defect 120137)

On the InfoCenter page, under "Download search-enabled InfoCenter as a .jar file and install locally:", click on download instructions. It takes you to an InfoCenter page which contains a table. The third column of the table contains links to details. The current value of the link is:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/dl

The correct value should be:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/info_center_zip.html#dl

Correction to InfoCenter article 6.6.a.1: Running the product servers and consoles as non-root (Defect 118068)

When WebSphere Application Server global security is enabled, the instructions for application server running as non-root should be as follows:

  1. Determine the non-root user that you would like the application server to "run as."
  2. Make sure the non-root user has read and write privileges on <WAS root>/properties/sas.server.props file.
  3. Make sure the non-root user has read and write privileges on <WAS root>/etc/secbootstrap file.
  4. Ensure that the application server is stopped.
  5. Delete the application server's temporary files and directories in the <WAS root>/temp directory. Ensure the user has read and write privileges on the <WAS root> /temp directory.
  6. Start the WebSphere Administrative console under the root ID.
  7. In the Java administrative console tree view, locate and click the application server to display its properties.
  8. In the Advanced properties, modify the User ID and Group ID to be the user and group for the application server to "run as."
  9. In the General properties, modify the standard output and standard error log paths to refer to directories to which the "run as" identity has access.
  10. Start the application server, using the new ID.

Warning: ensure that the administrative server "run as" ID has full access and privileges over the non-root ID that you gave to the application server.

Correction to InfoCenter article 8.9: Thread dumps (Defect 122270.RN)

In InfoCenter article 8.9: Thread dumps, the Java thread dumps for WebSphere Application Server administrative client running on an HP-UX system should go to <WAS root>/logs/adminclient_audit_messages.log, not the window that starts the administrative client as it described in the InfoCenter documentation.

Correction to InfoCenter article 5.2.: Implementing the CustomRegistry interface (Defect PQ55941)

CustomRegistry and System Management

When the administrative client (or xmlConfig) is used to set up security or modify users and groups to roles, the WebSphere Application Server System Management (SM) code calls the CustomRegistry implementation to retrieve data. During this time, the WebSphere Application Server administration repository is locked until the data is retrieved from the CustomRegistry. This implies that during the data retrieval any other System Management calls to the administrative repository depends on the performance of the CustomRegistry implementation

CustomRegistry implementation using a data source

When using a data source in the CustomRegistry implementation, the following property needs to be set in the admin.config to avoid the 1PC(one phase) committing problem.

com.ibm.websphere.security.customuserregistry.datasource=true

This property should only be set when the CustomRegistry is using a data source. If the registry is changed to use LocalOS or LDAP or a CustomRegistry that does not use a data source this property should be set to false or removed completely from the admin.config file. If this is not done, the server may encounter a deadlock condition during initialization.

When using this property, it is very important that the CustomRegistry implementation not make calls to WebSphere Application Server System Management (SM) for example through WSCP or xmlConfig. These calls may result in a database deadlock or other unpredictable results.

Stateful and entity beans in InfoCenter article 4.8.1.2.2.1 and 4.8.2.1 are not supported in WebSphere Application Server Version 4.0 FixPak 3 (Defect 119731)

In InfoCenter article 4.8.2.1: SOAP deployment descriptors in WebSphere Application Server, the following stateful and entity beans providers are not supported in WebSphere Application Server Version 4.0 FixPak 3:

com.ibm.soap.providers.WASStatefulEJBProvider 	stateful session bean 
com.ibm.soap.providers.WASEntityEJBProvider 	entity bean 

In InfoCenter article 4.8.1.2.2.1: Accessing enterprise beans through SOAP, the stateful and entity beans are not supported in WebSphere Application Server Version 4.0 FixPak 3.

InfoCenter article 4.8.4: Securing SOAP services are not complete (Defect 119021)

Configuration instructions for basic authentication with SOAP are not complete in InfoCenter article 4.8.4. The current steps for enabling basic authentication for SOAP services in WebSphere Application Server Version 4.x should be as follows:

  1. Create the .ear file that contains the components that you would like to expose as services (the security stuff will be added later).
  2. Run the SoapEarEnabler, providing the .ear file from the previous step. Use a "non-secure" SOAP server if you don't want digital structure support.
  3. Open the modified .ear in the Application Assembly Tool (AAT) and add the security settings to the soap.war (or soap-sec.war). The SOAP runtime is exposed as a servlet so what is really being secured are the servlets themselves.
  4. Deploy the .ear file.

Correction to "Generating deployment code for EJB enterprise beans" (105688)

In the "Command arguments" section of the InfoCenter article 6.6.0.15.1: Generating EJB deployment code from the command line, the list of valid databases under -dbvendor includes DB2UDBWIN_V71 (DB2 for Windows, V7.1. The Application Assembly Tool no longer has this option but, instead, has the option DB2UDBWIN_V72 "(DB2 for Windows, v7.2)".

PDF versions of the InfoCenter cannot be opened on the Advanced Single Server Edition (110846)

On the Advanced Single Server Edition, you might not be able to open PDF versions of the documentation if you accessed help through the administrative console. As a workaround, point your Web browser to the index.html page of the InfoCenter, which is located in the subdirectory main_WebSphere_directory/web/InfoCenter and has the URL main_WebSphere_directory/web/InfoCenter/index.html.

To correct the problem, do not install the InfoCenter .jar files into the same directory as the WebSphere Application Server product. Install into a separate directory. The following steps describe how to download and install the full WebSphere Application Server InfoCenter from a self-extracting .jar file.

  1. Download the InfoCenter file to a directory from which the java command is recognized.
  2. After the download completes, rename the file from:
    InfoCenter_name.jar.zip

    to:

    InfoCenter_name.jar

    In other words, remove the .zip from the end of the file. Web browsers often treat .jar files as corrupted so .zip is added to the end of the file to avoid this problem.

  3. Open a command window and enter a java command to install the InfoCenter:
  4. Accept the licensing terms.
  5. When prompted to specify the WebSphere installation directory, specify an existing, empty directory. Disregard the suggestion to install the InfoCenter under the product directory structure. The installation program executes, reporting status to the screen.
  6. After the installation program completes, it writes an InfoCenterInstall.log file in the WebSphere_installation_root/logs directory. You can use this file to verify which files have been installed and to review the messages displayed in the command window.
  7. Access the InfoCenter using a Web browser to open the index.html file in the InfoCenter directory.

InfoCenter Contents is missing a link to the migration article "3.7: Interoperability with Version 3.5.x" (111738)

In the Version 4.0 Advanced Edition InfoCenter, expanding the Contents choices Application Server AE and then Migration does not show a link to article "3.7: Interoperability with Version 3.5.x." To view the article, click on Table of Contents under Migration and click on the link "3.7: Interoperability with Version 3.5.x" at the bottom of the Table of Contents page.

Application Assembly Tool documentation should not reference the Full Select feature for Entity EJB finders (110292, 110319)

The Full Select feature for Entity EJB finders has been removed from the Application Assembly Tool. Information on the Application Assembly Tool should no longer document the feature.

Correction to "Assembly properties for Web modules" (115734)

The Version 4.0 InfoCenter article "6.6.8.0.aa: Assembly properties for Web modules" contains inaccuracies. The descriptions for classpath and additional classpath should be as follows:

Classpath
Specifies the full class path for the Web application. Specify the values relative to the root of the .ear file and separate the values with spaces. You should not use absolute values that reference files or directories on the hard drive. Consider the following example directory structure in which the file myapp.ear contains a Web module named mywebapp.war. Classes reside in class1.jar and class2.zip.
myapp.ear/mywebapp.war
myapp.ear/class1.jar
myapp.ear/class2.zip

Specify class1.jar class2.zip as the value of the Classpath property. Note that loading of .class files from the .ear file is not supported, as it is not J2EE portable.

Additional classpath
Specifies an additional class path used to reference resources outside of those specified in the archive. Specify the values relative to the root of the .ear file and separate the values with semicolons. You typically use this attribute as a mechanism for extending the classpath of a .war file without actually modifying the MANIFEST file of the file. In general, it is better to use the Class-Path: attribute of the MANIFEST file for assembly tasks. You should not use absolute values that reference files or directories on the hard drive. Consider the following WAR example directory structure in which the file myapp.ear contains a Web module named mywebapp.war. Additional classes reside in class1.jar and class2.zip.
myapp.ear/mywebapp.war
myapp.ear/class1.jar
myapp.ear/class2.zip

Specify class1.jar;class2.zip as the value of the additional classpath property. Note that loading of .class files from the .ear file is not supported, as it is not J2EE portable.

InfoCenter is missing information on configuring SessionManager with DB2 OS390 (113170)

The Version 4.0 InfoCenter is missing information on configuring SessionManager with DB2 OS390 as the persistent store. The information is available in the Version 3.5 InfoCenter in the article "1.2.3.2.3: Switching server databases to DB2/390." Note that only the section "Setting up the HttpSession database in DB2/390" applies to sessions.

Correction to "Assembly properties for MIME filters" (113166)

The InfoCenter article "6.6.8.0.14: Assembly properties for MIME filters" describes MIME Filter - Target incorrectly as "Specifies the target virtual host for the servlets." Instead, the description should state "Specifies the target servlet name to which the filter output will be routed."

Correction to "Additional administrative tasks for specific databases" (115760)

The InfoCenter article "6.6.14.5: Additional administrative tasks for specific databases" has incorrect bean values for the Oracle 8.1.7 two phase commit support. The correct bean values are REQUIRED, BEAN_METHOD, and _READ_COMMITTED and not TX_REQUIRED, TX_BEAN_MANAGED and TRANSACTION_READ_COMMITTED.

Correction to InfoCenter article 6.6.3.0: Application server properties (116775)

The InfoCenter article "6.6.3.0: Application server properties" incorrectly states that the default module visibility for the Advanced Single Server Edition is COMPATIBILITY. It should state that the default module visibility is APPLICATION.

Links incorrectly go to a page written in Spanish (106377)

The hyperlinks to DER_DBG_TAB and DER_DBG_TABGRID at the bottom of the article "Setting environment variables for the Debugger" in information in English on the Distributed Debugger incorrectly go to a Spanish page.

Correction to "Securing cloned applications" (110745)

The statement that "each server group and clone must be secured individually" in the InfoCenter article "6.6.18.1.2: Securing cloned applications" is incorrect. To secure a cloned application, you secure an enterprise application, put that secured application into a server group, and then make clones of the server group.

Correction to "Configuring SSL in WebSphere Application Server" (117136)

The InfoCenter Version 4.0 article "6.6.18.1a.7: Configuring SSL in WebSphere Application Server" provides the following incorrect SSL example for configuring a plug-in:

<Property name="keyring" value="product_installation_root\myKeys\plug-inKeys.kdb">
<Property name="stashfile" value="product_installation_root\myKeys\plug-inKeys.sth">

The example should be as follows:

<Property name="keyring" value="product_installation_root\myKeys\plug-inKeys.kdb"/> 
<Property name="stashfile" value="product_installation_root\myKeys\plug-inKeys.sth"/>

The example elements need a forward slash (/) at the end of each element to terminate them.

Local version of InfoCenter missing information in Troubleshooting section (Defect 124102)

If you download and install the InfoCenter .jar file from the product Web site or if you try to access these files from the Integrated InfoCenter, the Troubleshooting section may contain blank files.

The files are available from the Web site:

Article 8.7 Using application level facilities

Article 8.7.1 ORB-related minor codes

Article 8.8 Using internal tools

Correction to WebSphere Application Server Version 4.0 InfoCenter (Defect PQ59737)

There is a section "Configuring a single instance of IBM HTTP Server (IHS) with Websphere Application Server Version 3.5.x and 4.0.x" in WebSphere Application Server Version 4.0 InfoCenter.

You will find the following information:

UNIX

LoadModule ibm_app_server_http_module/opt/WebSphere/AppServer40
/bin/mod_
AddModule mod_app_server_http.c
Alias /WSsamples "/opt/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig /opt/WebSphere/AppServer40/
configplugin-cfg.xml

There should be a slash (/) between "config" and "plugin-cfg.xml"

Correction to configuring WebSphere Application Server security to use client certificate in InfoCenter (Defect 124815)

InfoCenter provides incomplete information about configuring WebSphere Application Server security to use client certificate. Please refer to Chapter 11 of the Redbooks http://www.redbooks.ibm.com/, "IBM WebSphere Version 4.0 Advanced Edition Security" (SG24-6520-00) for complete and correct example of this procedure.

Correction to InfoCenter article 7.2.4.2: Modifying server groups and clones (Defect PQ56722)

The InfoCenter article 7.2.4.2: Modifying server groups and clones states incorrect information about removing objects from the model. The statement in InfoCenter is: Other server group changes (such as adding or removing enterprise beans from an application server) are picked up by the clones when they are restarted.

This statement is incorrect because objects can not be removed from the model without first being removed from all clones. The propagation only works with modifications and additions not deletions. To make this work as expected, remove objects from the clone and then remove from the model.


InfoCenter may contain broken links (Defect 128444)

Because the WebSphere Application Server 4.0 InfoCenter is not updated for FixPaks, you may occasionally see document links that are no longer valid. Please ignore these links. Documentation for FixPaks is provided in the Release Notes and the TechNotes database.

Correction to configuring WebSphere Application Server security to use client certificate in InfoCenter (Defect 124815)

The InfoCenter provides incomplete information about configuring WebSphere Application Server security to use client certificate. Please refer to Chapter 11 of the Redbooks http://www.redbooks.ibm.com/, "IBM WebSphere Version 4.0 Advanced Edition Security" (SG24-6520-00) for complete and correct example of this procedure.

Correction to "Installing Oracle 8i Release 3 (8.1.7)" for HP-UX (110141)

Step 2 in instructions in the InfoCenter on "Installing Oracle 8i Release 3 (8.1.7)" for HP-UX should not reference the SHMMIN parameter. There is no such configurable parameter in HP-UX 11.0.

Correction to "Mounting a CD-ROM on HP-UX" (110139, 116616)

Instructions in the InfoCenter on "Mounting a CD-ROM in HP-UX" should be changed to the following:

Using the following Description Definition Language to use DB2 on OS390 as session persistence database (Defect 127607)

To use DB2 on OS390 as session persistence database, use the following Description Definition Language (DDL). You may want to modify this based on your environment.

CREATE DATABASE SESSDB
  STOGROUP SYSDEFLT
  CCSID EBCDIC;
  
CREATE TABLESPACE SESSTS IN SESSDB
  USING STOGROUP SYSDEFLT
  PRIQTY 512
  SECQTY 1024
  BUFFERPOOL BP32K;
  
CREATE TABLE NULL.SESSIONS  (
  ID               VARCHAR(95) NOT NULL ,
  PROPID           VARCHAR(95) NOT NULL ,
  APPNAME          VARCHAR(64) ,
  LISTENERCNT      SMALLINT ,
  LASTACCESS       DECIMAL(19,0),
  CREATIONTIME     DECIMAL(19,0),
  MAXINACTIVETIME  INTEGER ,
  USERNAME         VARCHAR(256) ,
  SMALL            VARCHAR(3122)  FOR BIT DATA ,
  MEDIUM           VARCHAR(28869) FOR BIT DATA,
  LARGE            BLOB(2097152),
  SESSROW          ROWID NOT NULL GENERATED ALWAYS
  )
  IN SESSDB.SESSTS;

CREATE UNIQUE INDEX NULL.SESS_INDEX ON NULL.SESSIONS
      (ID      ASC,
       PROPID  ASC,
       APPNAME ASC);
	   
CREATE LOB TABLESPACE LOBOBJTS IN SESSDB
    BUFFERPOOL BP32K
    USING STOGROUP SYSDEFLT
    PRIQTY 512
    SECQTY 1024
    LOCKSIZE LOB;
	
CREATE AUX TABLE NULL.SESSIONSAUX
    IN SESSDB.LOBOBJTS
    STORES NULL.SESSIONS
    COLUMN LARGE;
	
CREATE INDEX NULL.SESSION_IX ON NULL.SESSIONSAUX;

In DB2/390, set the RRULOCK parameter to YES.

Correction to InfoCenter article 6.6.a.1: Running the product servers and consoles as non-root (Defect PQ61277)

The following information will be added to the section of "Running application servers as non-root" in InfoCenter article 6.6.a.1: Running the product servers and consoles as non-root:

Remove any temporary files that were created by previous executions of the application server when it was "run as" the previous user ID.

Change the ownership of these specific files and directories to the user and group that you want the administrative server to "run as."

	product_installation_root/properties/* 
	product_installation_root/config/* 
	product_installation_root/temp/* 
	product_installation_root/logs/activity.log
	

Make sure that the user has read privileges for properties and installedApps directories.

Make sure that the user has read/write privileges for logs and temporary directories.

Correction to InfoCenter article 5.7.7: Disabling security on specific application servers (Defect 134405)

InfoCenter article 5.7.7: Disabling security on specific application servers provides incorrect information. Please refer to section 21.1.6 of the IBM WebSphere Version 4.0 Advanced Book Handbook: Securing only the administrative server (IBM Redbook SG24-6176-00).

Correction to InfoCenter article 6.6.3.3: Administering application servers with the Web console (Defect 109291)

In Version 4.0 for Advanced Edition Single Server InfoCenter, article 6.6.3.3: Administering application servers with the Web console provides the following information: "Use the Web console to edit the configurations of application servers. You cannot use this console to start and stop application servers."

This statement is incorrect. Advanced Edition Single Server now allows application servers to be started and stopped directly from the console.

Correction to InfoCenter article 6.6.45.0.1: Modifications to Web server configuration files during product installation (Defect PQ60101)

InfoCenter article 6.6.45.0.1: Modifications to Web server configuration files during product installation has two errors under the sub-title: Netscape or iPlanet (obj.conf) for the HTTP plug-in:

	Init fn="load-modules" funcs="as_init, as_handler, as_term"
	shlib="C:/WebSphere/AppServer/bin/ns41_http.dll"
	Init fn="init_exit" bootstrap.properties="C:/WebSphere/AppServer/config/plugin-cfg.xml"
	Service fn ="as_handler"l
	
  1. There should be no spaces between funcs="as_init, as_handler, as_term"
  2. The correct format is Init fn="as_init" bootstrap.properties="C:/WebSphere/AppServer/config/plugin-cfg.xml" instead of Init fn="init_exit" bootstrap.properties="C:/WebSphere/AppServer/config/plugin-cfg.xml"

Missing message from the 8.2 Messages file (Defect PQ62319)

The following message is missing from the 8.2 Messages file in the WebSphere Application Server InfoCenter:

SRVE0146E: Failed to Start Transport

Explanation: A configured transport-port is in use by another application.

User Response: Ensure that no other applications are using this port and then restart the server. If another application is using this port, change the transport-port in WebSphere Application Server to another value, or change the other application to use a different port.

Correct values for silent installation (PQ61586)

Please update the values for silent installation as following:

Correction to "Installing DB2 UDB 7.2" and "Configuring DB2 UDB 7.2" on UNIX (110232)

The instructions in the InfoCenter on "Installing DB2 UDB 7.2" and "Configuring DB2 UDB 7.2" state that the directory used for DB2 UDB is /opt/IBMdb2/V7.2 for Solaris and /usr/lpp/db2_07_02 for AIX. The AIX installation might, in fact, use the directory /usr/lpp/db2_07_01. Similarly, the Solaris installation might use the directory /opt/IBMdb2/V7.1, which is the correct directory for installation on Solaris.

Correction to InfoCenter article: Configuring DB2 Universal Database (UDB) 7.1 for use with WebSphere Application Server (Defect 136310)

Please ignore the following bullet in InfoCenter article: Configuring DB2 Universal Database (UDB) 7.1 for use with WebSphere Application Server:

And add additional information on how to use the EXTSHM for this section:

Administrative server will not start because AIX environment variable EXTSHM is turned off

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

4. 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 accidentaly again, add the above three lines of commands to the db2profile (assuming the db2profile is sourced using .profile) to ensure the variable is always valid.

Correction to InfoCenter article 6.6.3.0: Application server properties (PQ54257)

The first release of WebSphere Application Server Advanced Single Server Edition Version 4.0 had an Execution State field in the console that you could set. This field has since been removed, though the InfoCenter still references it in the article: 6.6.3.0: Application server properties and in the installation information for the Advanced Single Server Edition on UNIX platforms.

Though you can still set the execution state value by modifying the XML file, there is no longer a field in the console that you can modify to change the field's value. In fact, there is no need to change the value because it controls the initial state of the application server, which must be running for the console to be operational.

Correction to InfoCenter article 8.8: Using internal tools (Defect 118724)

In InfoCenter article 8.8: Using internal tools, the correct links for WebSphere Problem Determination Tools, Jdbctest.java, JavaTM Name Tree Browser, and JavaTM Socket Level Trace should be WebSphere Application Server Support Page.

Perform the following steps to get the detail information of those tools on that Web page:

  1. Click All e-fixes, fixpaks, and tools.
  2. Click Type under Support software.
  3. Select DIAGNOSTIC TOOL.

Correction to InfoCenter article 0.16.4: How requests map to virtual aliases (Defect PQ62682)

InfoCenter article 0.16.4: How requests map to virtual aliases incorrectly states that URL mappings are case insensitive. Please be aware that all URL mappings are case-sensitive.

Correction to InfoCenter article: Installing the Advanced Edition using DataDirect SequeLink with Oracle 8i in a Custom installation on Windows (Defect 111288)

In InfoCenter article: Installing the Advanced Edition using DataDirect SequeLink with Oracle 8i in a Custom installation on Windows, please replace the two bullets under steps for installation with following information:

Installing Oracle 8i:

Configuring an Oracle 8i database

To use an Oracle database with WebSphere Application Server, you must configure the database:

  1. Add the following line to the initialization file: open_cursors = 220

    On Windows NT or 2000, the initialization file is typically located at \Oracle\Ora81\database\Initxxx.ora, where xxx is your SID (example, orcl).

  2. Using a Services panel, stop and restart the Oracle services OracleServiceORCL and OracleOraHome81TNSListener.
  3. Define a WebSphere administration ID with database authority by creating the Oracle user EJSADMIN using the commands below. For the values needed in the first command, enter system as the ID and manager as the default password. As to the second command, EJSADMIN_password is the password for EJSADMIN.
    sqlplus system/manager
    create user EJSADMIN identified by EJSADMIN_password;
    grant connect,resource,dba to EJSADMIN;
    quit

    If you are using EJB functionality or will use the WebSphere Application Server samples, define an ID for use in deploying entity beans. As to the second command, EJB_password is the password for EJB.

    sqlplus system/manager
    create user EJB identified by EJB_password;
    grant connect,resource,dba to EJB;
    quit

    If you are using the Advanced Edition and do not want EJSADMIN to have dba authority, do not enter the commands above but, instead, complete the following two steps.

    1. Enter the commands:
      sqlplus system/manager
      create user EJSADMIN identified by EJSADMIN_password quota 100M on SYSTEM;
      grant connect,resource to EJSADMIN;
      create user EJB identified by EJB_password quota 100M on USERS;
      grant connect,resource to EJB;
      quit
    2. After you start the WebSphereAdministrativee Console, edit the data source for the HitCount bean (select Recources, JDBC Providers, Sample DB Driver, DataSources, and SampleDataSource) so the User ID and Password are set to EJB (or the User ID you chose to use for EJBs) and then click Apply.

  4. Test access to the new database using the EJSADMIN user ID: sqlplus ejsadmin/ejsadmin

    After a message displays indicating a successful connection, enter exit

  5. If you choose to use the supplied EJB sample HitCount, you need to define the table that will serve as the persistent data store:
    SQLPLUS EJB/EJB
    CREATE TABLE INC (PRIMARYKEY VARCHAR(250) NOT NULL, THEVALUE INTEGER) ;
    ALTER TABLE INC ADD CONTRAINT INCPK PRIMARY KEY (PRIMARYKEY) ;  

Testing the installation:

Change all occurences of IBM WS AdminServer to IBM WS AdminServer 4.0 in this section.

Correction to InfoCenter article 6.6.0.2.2.2.2: Basic syntax (Defect 110196)

InfoCenter article 6.6.0.2.2.2.2: Basic syntax incorrectly states the following information:

The syntax for the wscp command is as follows: wscp [ -h ] [ -c command ] [ -f Tcl_file_name] [ -p properties_file_name] [ -x extension_class] [ [ -- ] options ] [-node node_name]

The correct statement is as follows:

The syntax for the wscp command is: wscp [ -h ] [ -c command ] [ -f Tcl_file_name] [ -p properties_file_name] [ -x extension_class] [ [ -- ] options ]

Updates for InfoCenter article 6.6.49: Administering National Language Support (Defect PQ61392, PQ61392.doc)

The following table, which lists the locales supported for the different platforms on WebSphere Application Server Version 4.0, has been updated.

Languages Windows AIX Solaris HP-UX Linux Red Hat V7.1 Linux Red Hat V7.2 Linux SuSE Linux SuSE SLES

Linux/390 SuSE

Simplified Chinese X X X            
Traditional Chinese X X X            
Japanese X X X   X X X    
Korean X X X     X      
Brazilian Portuguese X X X            
French X X X X X X X    
German X X X X X X X X X
Italian X X X X X X X    
Spanish X X X X X X X    

System levels for platforms :

Windows:

AIX:

Solaris

HP-UX:

LINUX/INTEL:

LINUX/390:

Correction to InfoCenter article 6.6.29.4: Updating Location Server Daemon configurations with the Web console (Defect PQ62941)

The following is additional information for InfoCenter article 6.6.29.4: Updating Location Server Daemon configurations with the Web console:

5. (Optional) To have the configuration take effect:

It does not work to just check the Enable box and restart the WebSphere Application Server, because a change to the "mode" parameter needs to be changed from NONE to PROVIDER to allow remote access the WebSphere Application Server.

In the server-cfg.xml, change the line

<locationServiceDaemon xmi:id="LocationServiceDaemon_1"       
enable="true" hostname="localhost" port="9000" mode="NONE"/>   

to

<locationServiceDaemon xmi:id="LocationServiceDaemon_1"      
enable="true" hostname="localhost" port="9000" mode="PROVIDER"/>

Correction to InfoCenter article 6.6.0.2.2.4.8: Creating an enterprise application (Defect PQ63229)

The following is the correct text for InfoCenter article 6.6.0.2.2.4.8: Creating an enterprise application > Administering modules.

Administering modules

The resources that compose an enterprise application are grouped according to function into modules. Enterprise applications can contain three types of modules:

The wscp Module operations allow you to deploy modules independently from enterprise applications. Application client and EJB modules are installed from Java archive (JAR) files; Web modules are installed from Web archive (WAR) files. When you install a module, wscp actually generates a simple EAR file with the specified JAR or WAR file as its only module. It then installs the EAR file. You can optionally assign such things as security roles, specify JNDI mappings, and specify data sources for enterprise beans.

The wscp Module install operation installs an enterprise application module. The syntax of this operation is:

Module install nodeName module_name -moduleappservers 
	  {module_URI appServName} -appName ApplicationName [-modvirtualhosts 
	  {module_URIvirtual_host_name}][other options]         
	

where:

To view a complete list of enterprise application attributes, use the EnterpriseApp attributes command. See Querying (displaying) attributes for more information on displaying object attributes.

The following command example shows how to install a Web module. The module type and active module type are web; the relative URI of the WAR file containing the module is storefront.war; the context root is /WebApp.

wscp> Module install /Node:DS1/ C:/storefront.war -contextroot /WebApp

Correction to InfoCenter article 6.6.18.1a.7: Configuring SSL in WebSphere Application Server (Defect 141671)

Correction to InfoCenter article 6.6.18.1a.7: Configuring SSL in WebSphere Application Server > Configuring SSL for the application server's HTTPS transport.

7. Import the plug-in's certificate.

The classpath field entries must be separated by spaces (Defect 142473)

All of the classpath filed entries must be separated by spaces instead of semicolons or any other character.

Displaying the Version 4.0.2 Release Notes (Defect 136364.RN)

There is a zip file in the WebSphere Application Server Version 4.0.2 Release Note files. The file's name is /usr/WebSphere/en/InfoCenter/wasa_content/relnotes402.zip. The release notes are actually contained in the relnotes402.html file within the zip file. This will cause your browser to attempt to download the file rather than displaying its contents when its link is selected.

To work around this problem unzip the archive file then perform one of the following methods.

Correction to InfoCenter article 6.6.8.0.14: Assembly properties for MIME filters (Defect 112624)

InfoCenter article 6.6.8.0.14: Assembly properties for MIME filters currently states "Specifies the target virtual host for the servlets." This is incorrect. The article should state: "Specifies the name of the target servlet or JSP file."

Blanks eliminated between some words in Migrguide.pdf document (Defect 144087)

The PDF migration guide has some words where the blanks are eliminated.

The reference link is:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/was/pdf/nav_Migrguide.pdf

Please ignore those formatting errors.

Back to InfoCenter
Back to Possible Problems and Suggested Fixes