Release Notes for IBM WebSphere Application Server, Version 3.5 with FixPak 7

• Avoiding FixPak installation errors
• After installing the FixPak (Defects PQ48085)
• Allowing a distributed transaction that uses two data sources on different notes to run successfully (Defects 2921.RN, 99858)
• Changing the CURSORHOLD Option (Defect PQ49737)
• Enabling plug-in for OSE remote configuration in WebSphere Application Server V3.5.5 or earlier (Defect PQ50243.RN)
• Starting the server after installing the WebSphere Application Server plug-in for the Apache Server (Defect 85322.rn)
• Migrating and upgrading from Version 3.0.2 to Version 3.5 (Defect PQ42682.DOC)
• Manually migrating from WebSphere Application Server Version 3.5.7 to WebSphere Application Server Version 4.0.1 (Defect PTF)
• Pointing to the new installation directory for DB2 V7.1 (Defect 87213)
• Setting the virtual directory (Defect 95004)
• Using the -ignore option to install WebSphere Application Server Version 3.5 with FixPak 7 when machine only has component installed (Defect PQ55146.RN)
• Keeping applications with DB2 settings from failing with WebSphere Application Server V3.5 with FixPak 7 (Defect 111066)
• Configuring WebSphere Application Server to use Sybase as a repository (PQ67688)
• Instructions for installing the Merant driver (Defect PQ54650)

• Running Java applications reliably (Defect 83321.RN)
• Applying APAR IY19277 to use IBM HTTP Server 1.3.12 with the WebSphere Application Server plug-in on AIX 4.3.3 (Defect 112235)
• Setting up the DB2 environment properly when referring to Oracle, Sybase, or IDB databases as the administrative database (Defect 83770.RN)
• Manually allowing WebSphere Application Server to verify an application server repository (Defect 101324)
• Uninstalling WebSphere Application Server V3.5 successfully (Defect 112947.RN)
• Installing the Sun ONE Web Server with the WebSphere Application Server plug-in installed (Defect 158820)
• Additional AIX packages might be required when installing WebSphere Application Server (Defect PQ71546)

• Downloading the HP client through a Web client (Defect 119460.RN)
• Installing and uninstalling WebSphere Application Server with FixPak 7 on an HP machine (Defect 118250.RN)

• Using the custom options of the WebSphere Application Server migration utility with a non-DB2 database (Defect 99541)
• Install IBM HTTP Server manually to avoid getting an error message (Defect PQ63392)

• Increasing the file descriptor limit when connections to servlets and JavaServer Pages are refused
• Exporting the existing configuration during migration (Defect 97733)
• Importing your original server configuration during migration (Defect 97733)
• Installing the WebSphere Application Server Version 3.5 FixPak onto a system that has DB2 UDB V7.1 installed (Defect PQ46537)
• Setting up the DB2 environment properly when referring to Oracle, Sybase, or IDB databases as the administrative database (Defect 83770.RN)
• Manually allowing WebSphere Application Server to verify an application server repository (Defect 101324)
• Viewing the README file successfully (Defect 83618)
• Visiting the database page to configure databases (Defects 96419, 101612)

• Using the administrative agent multi-node configuration (Defect 119463.RN)
• Installing the Sun ONE Web Server with the WebSphere Application Server plug-in installed (Defect 158820)

• Configuring a SequeLink server
• Creating multiple instances of Internet Information Servers (Defects PQ98131.RN)
• Running the WebSphere Application Server V3.5 and V4.0 on the same machine (Defects 108052.RN)
• Using the administrative agent multi-node configuration (Defect 119463.RN)

• Obtaining lodctr.exe before installing the WebSphere Application Server
• Configuring a SequeLink server
• Obtaining the dynamic link libraries needed to install SQL Server 2000 (Defect 93021.RN)
• Running the WebSphere Application Server V3.5 and V4.0 on the same machine (Defects 108052.RN)
• Manually allowing WebSphere Application Server to verify an application server repository (Defect 101324)
• Visiting the database page to configure databases (Defects 96419, 101612)

Avoiding FixPak installation errors

To avoid errors, follow these steps:

1. Stop all Web servers.
2. Stop the WebSphere Application Server.
3. Uninstall the FixPak.
4. Delete the backup files.
5. Reinstall the FixPak.

Increasing the file descriptor limit when connections to servlets and JavaServer Pages are refused

The default communications configuration between the Web server and the servlet engine uses TCP/IP sockets. Each socket represents a file descriptor. If you set the file descriptor limit per process too low, the server refuses attempts to open socket connections and an error 146 displays.

To resolve this condition, increase the file descriptor limit for the user from which the administrative server starts, usually root. Edit the .profile file for the user, and add the following:

ulimit -n 1024

You can increase this value depending on the number of connections. Log off, and then log on for this change to take effect.

To change the hard upper limit of the number of file descriptors in the kernel which defaults to 1024 per CPU, edit the /etc/system configuration file to include:

set rlim_fd_max=4096
set rlim_FD_cur=1024

Save the file and restart the machine for the changes to take effect.

Running Java applications reliably (Defect 83321.RN)

Reduce the LIBPATH length to less than 1548 characters.

Obtaining lodctr.exe before installing the WebSphere Application Server

ERROR-FUNCTION-entry not found on string table because the lodctr.exe file is missing from the WINNT/SYSTEM32 directory.

Before installing the WebSphere Application Server with the IBM HTTP Server, ensure you have the lodctr.exe file in the WINNT/SYSTEM32 directory. If needed, copy this file from another machine running the Windows NT operating system into in the WINNT/SYSTEM directory.

After installing the FixPak (Defect PQ48085)

The WebSphere Application Server FixPak installation program is working as designed. The installation program unpacks files to a new fileset. This program does not affect the operating system registry fileset, so the registry stays at V3.5.0, after a FixPak installation.

Allowing a distributed transaction that uses two data sources on different notes to run successfully (Defects 2921.RN, 99858)

Failed to debit card:

java.rmi.ServerException:

 RemoteException occurred in server thread;

nested exception is:

 java.rmi.RemoteException: debitCard failed:

COM.ibm.db2.jdbc.DB2Exception:

 [IBM][CLI Driver] SQL30090N

Operation invalid for application execution

 environment.

Reason code = "06".

SQLSTATE=25000

Where debitCard represents the name of the application used for testing.

Create the JTA drivers and data sources on the same node, but ensure that the database name in one of the data sources contains the alias to the database on the remote machine.

For example, suppose the following machines have the following database names:

DB2 Server Machine 1: Database A
DB2 Server Machine 2: Database B

On machine 1, catalog the remote database B to create the database alias dbalias B. Then, data source A will point to database A on machine 1, and data source B will point to dbalias on machine 1.

Changing the CURSORHOLD Option (Defect PQ49737)

To set the CURSORHOLD value in a data source, create a datasources.xml file and place this file in the WAS_HOME\properties directory. Use the datasources.xml file to set several properties on the data source.

An example of what the file would look like for CURSORHOLD follows:

  <data-sources>
  <data-source name="data_source_name">
  <attribute name="CURSORHOLD" value="1"/>
  </data-source>
  </data-sources>
 

Downloading the HP client through the Web client (Defect 119460.RN)

The administrative client download is now a function of WebSphere Application Server Version 3.5.7. After installing WebSphere Application Server Version 3.5.7, an HP link is not available on the http://<web server>/admin/install Web page.

Perform the following steps to download the HP administrative client through the Web client:

1. Open the administrative console.
2. Click Default Server, then click Servlet Engine and choose admin Web application, and then click Install.
3. Go to the Advanced page for the installation servlet. In the initial parameter, add the parameter name as: install/install/IBMWebASv3_HP_AdminClient.jar , and add value as: adminclient. for .hp
4. Restart the Default Server.

An enhancement has been made to the plug-in for OSE remote configurations in WebSphere Application Server 3.5.6 or earlier. In these releases if during a "Manual Configuration" of the Web server plug-in stated in the InfoCenter article 7.1.3.6.1 an invalid host name is added to the queues.properties file the plug-in would fail to initialize and no requests would be served for any application server.

In WebSphere Application Server Version 3.5.6 the plug-in is now allowed to initialize and an error will be placed in the plug-in log file as follows:

Warning - ws_init_ip_addr - gethostbyname error 11001. Cannot find host "yourhostname" Requests for other appservers will serve requests.

To correct the error, edit the queues.properties file and restart the server.

Exporting the existing configuration during migration (Defect 97733)

Start the administrative server from the command line.

Using the -ignore option to install WebSphere Application Server Version 3.5 with FixPak 7 when machine only has component installed (Defect PQ55146.RN)

If you are installing WebSphere Application Server Version with FixPak 7 on a machine that does not have the complete WebSphere Application Server product installed (for example, only the administrative console is installed), the installation process displays several errors messages trying to locate JAR files it needs to update. In this case, issue the following command with the ignore option to install the FixPak:

./install.sh -ignore

Using the administrative agent multi-node configuration across different platforms (Defect 119463.RN)

If you are using the administrative agent multi-node configuration across different platforms, you need to modify the path to the SRP EJB on the secondary node to find ibmwebas.jar locally. Otherwise your application servers will not start. Here is an example of this configuration:

1. On Machine A (UNIX) install full service administration.
2. On Machine B (Windows 2000) install AdminServer Runtime and plug-in.
3. Start up Machine A and server snoop servlet to ensure it is working.
4. On Machine B, perform the following steps to edit the admin.config file:
   • Remove the dbURL line (com.ibm.ejs.sm.adminServer.dbURL=jdbc:db2:was
   • Remove dbUser line (com.ibm.ejs.sm.adminServer.dbUser=<db username>
   • Remove the dbPassword line (com.ibm.ejs.sm.adminServer.dbPassword=<db password>
   • Remove the dbDriver line (com.ibm.ejs.sm.adminServer.dbDriver=COM.ibm.db2.jdbc.app.DB2Driver
   • Remove the nameservice line (com.ibm.ejs.sm.sm.adminServer.nameServiceJar=d:/WebSphere/AppServer /lib/ns.jar
   • Add com.ibm.ejs.sm.adminServer.primaryNode=MarchineA
   • Add com.ibm.ejs.sm.adminServer.bootstrapHost=MachineA.raleigh.ibm.com
   • Add com.ibm.ejs.sm.adminServer.agentMode=
   • Add com.ibm.ejs.sm.adminServer.bootstrapPort=900
   • Add com.ibm.ejs.sm.adminServer.lsdPort=9000
5. Start the administrative server on both nodes.
6. Create application server, Web application, and servlets under node B.

   A default EJB container and SRP EJB will be automatically created. On the right panel, click on the EJB SRP, the JAR file /user/WebSphere/AppServer/lib/ibmwebas.jar

7. Start the application server under node B. Note that the application server cannot be started.
8. Edit the JAR file properties for SRP EJB, change the JAR file path to d:\WebSphere\ AppServer\lib\ibmwebas.jar.

   The application server is started successfully.

Configuring a SequeLink Server

Follow these steps to configure the server:

In this example, the nondefault Microsoft SQL Server name is STLAB20\SQLEJS:

1. Access SL Admin Mgr Snapin from the Start menu.
2. Click SLSQLServer51.
3. Click Configuration.
4. Click Data Source Settings.
5. Click Default.
6. Right-click and click New > Attribute.
7. Click DataSourceMSSODBCConnStr from the drop-down menu.
8. Type the following values if you use the SQL Server 2000 ODBC Driver:
   Driver={SQL Server};Server=STLAB20\SQLEJS
   where STLAB20\SQLEJS represents the name of the Microsoft SQL server name.
   
   Type the following values if you use the SQL Server V7.0 ODBC Driver, or the default type:
   Driver={MERANT MSSS Driver for SequeLink 5.0};Server=STLAB20\SQLEJS.
9. Stop the Sequel server agent.
10. Restart the Sequel server agent.

Importing your original server configuration during migration (Defect 97733)

Start a new administrative server process.

Installing and uninstalling WebSphere Application Server with FixPak 7 on an HP machine (Defect 118250.RN)

If you install and uninstall FixPak 7 on an HP machine that previously had the WebSphere Application Server Version 3.5.0 or 3.5.1 installed, you receive the following message when you attempt to start the application server:

"Error! Shared library ioser12 could not be found."

To fix this problem, verify that the libioser12.sl and libioser12_g.sl entries are in the <WAS_ROOT>/bin directory and that these entries have the proper permission. Ensure the permission is greater than or equal to 711.

Applying APAR IY19277 to use IBM HTTP Server 1.3.12 with the WebSphere Application Server plug-in on AIX 4.3.3 (Defect 112235)

To fix this problem, apply AIX APAR IY19277.

If you are installing AIX V4.3.3 ML 9 or greater, you do not need to apply APAR IY19277 for IBM HTTP Server to start.

Obtaining the dynamic link libraries needed to install SQL Server 2000 (Defect 93021.RN)

To fix this problem:
Install the MDAC version that ships on the DataDirect SequeLink CD-ROM, or Version 2.1 from the Microsoft Web site available at:
http://www.microsoft.com/data/download_21242023.htm

Starting the server after installing the WebSphere Application Server plug-in for the Apache Server (Defect 85322.rn)

To fix this problem:
The plug-in installation added the line ose.mode=out to your Apache configuration file srm.conf in the /<apache_home>/conf directory. Open an editor on the srm.conf file, and remove or comment out the ose.mode=out line.

Installing the WebSphere Application Server Version 3.5 FixPak onto a system that has DB2 UDB V7.1 installed (Defect PQ46537)

To fix this problem:

1. Copy the prereq.properties file from the /cdrom directory to the /tmp directory.
2. Edit the SUN packages = db2cliv61 statement in the /tmp/prereq.properties file to SUN packages = db2cliv71.
3. Use the following command to install the FixPak:

   install.sh /prereqfile /tmp/prereq.properties

You need to make changes to the prereq.properties on all UNIX platforms if you are installing DB2 UDB V7.1. For Windows, a warning message will indicated the level of DB2 is higher than the one version needed. You can continue the installs by clicking OK.

Migrating and upgrading from Version 3.0.2 to Version 3.5 (Defect PQ42682.DOC)

Migrate all application files first before migrating from Version 3.0.2 to Version 3.5.

See InfoCenter article 3 for more information. Step 2 of these instructions tells you to migrate or upgrade to IBM WebSphere Application Server V3.5. You need to migrate, then upgrade. Follow steps 3 through 5 for migration, then proceed with your upgrade.

Manually migrating from WebSphere Application Server Version 3.5.7 to WebSphere Application Server Version 4.0.1 (Defect PTF)

When installing WebSphere Application Server Version 4.0.1, if the migration script does not run automatically, run it manually. To run the migration manually, perform the following steps. These steps assume a Windows- based system; 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 directory.
3. Invoke the WASPreUpgrade file by issuing the following command:

   waspreupgrade c:\backup_directory c:\current_3.x.x_WebSphere_directory wssylvester

   where wssylvester represents the adminNodeName. In some cases the waspreupgrade command may not be totally successful. To ensure you have a valid configuration saved, verify that the following file exists:

   c:\backup_directory\websphere_3x_backup.xml

   exists. If the file does not exist, type the following command from the c:\current_3.x.x_WebSphere_directory directory:

   xmlconfig -export c:\backup_directory\websphere_3x_backup.xml -adminNodeName wssylvester

4. Shut down the WebSphere Application Server V3.x.x Administrative Server after the preceding step completes .
5. Run the WebSphere Application Server V4.0.1 Application Server installation program. Do not select the Perform Migration check box in the Previous Installation Detected panel. After the WebSphere Application Server installation program runs, move to the bin directory under the V4.0.1 WebSphere Application Server directory.
6. Invoke the WASPostUpgrade file, by issuing the following command: WASPostUpgrade c:\backup-directory -adminNodeName wssylvester

If you migrate from WebSphere Application Server Release 3.02.x on Solaris, turn global security off before attempting to migrate to Release 4.0. An error can occur while doing the migration steps during installation. If this happens, then proceed with the manual steps provided, modify the passwords using the Administration Console and enable security.

Creating multiple instances of Internet Information Servers (Defect PQ98131.RN)

Create two virtual directories in the second instance of IIS, IBMWebAS, sePlugins. Make these virtual directories identical to the first instance of IIS, so both virtual directories in both instances appear identical. You can create virtual directories for as many IIS instances as you have.

Pointing to the new installation directory for DB2 V7.1 (Defect 87213)

Check that the admin.config file points to the new DB2 directory x:\Program Files\SQLLIB. Modify the admin.config pointer to the DB2 driver if you have already installed and started the WebSphere Application Server and this error displays.

Running the WebSphere Application Server V3.5 and V4.0 on the same machine (Defects 108052.RN)

If you run the WebSphere Application Server V3.5 and V4.0 on the same machine, complete the following steps before installing WebSphere Application Server Version 3.5.6:

1. Remove the WAS_HOME system environment variable.
2. Remove the %WAS_HOME%\bin system path environment variable.

Setting the virtual directory (Defect 95004)

For example, if a user types http://host/SEPlugins/admin.config, this file and its contents, including the password, become viewable. The NTRegistry file in the bin directory becomes another file to avoid accessing.

1. Create a plugins subdirectory under the bin directory.
2. Copy the iis20.dll file to the plugins subdirectory.
3. Ensure the virtual directory, sePlugins, in the IIS configuration points to the bin\plugins directory.

Setting up the DB2 environment properly when referring to Oracle, Sybase, or IDB databases as the administrative database (Defect 83770.RN)

The exception occurs when you use DataSource to access the DB2 database for application data, by choosing the DataSource for Connection Pooling function, or the enterprise bean.

Set up the DB2 environment properly in the WebSphere Application Server startupServer.sh file if you plan to refer to Oracle, Sybase, or IDB databases as administrative databases.

To modify the startupServer.sh file:

1. Find the following line in a then clause:

   export LD_LIBRARY_PATH

2. Add the following lines before the export LD_LIBRARY_PATH line:

     DB2_HOME=/export/home/db2inst1
     
     export DB2_HOME
     
     .$DB2_HOME/sqllib/db2profile
     
     LD_LIBRARY_PATH=$DB2_HOME/sqllib/java12:
     
     $DB2_HOME/sqllib/lib:$LD_LIBRARY_PATH
     
     LIBPATH=$LD_LIBRARY_PATH
     
     export LD_LIBRARY_PATH LIBPATH

Specify your DB2 instance home directory for $DB2_HOME. Type the values for LD_LIBRARY_PATH= on one line; these values appear on two lines to improve readability.

Uninstalling WebSphere Application Server V3.5 successfully (Defect 112947.RN)

Uninstalling the WebSphere Application Server V3.5 product fails on the AIX operating system.
An example of an error message follows:

Pre-installation Failure/Warning Summary------------------------Verifying selections
[3]:/usr/IBMWebAS/java/bin/java: not found OR Verifying selections...Can't find libvm.a...
------------IBMWebAS.base Failed pre-deinstallation check

To uninstall WebSphere Application Server V3.5 successfully, perform the following steps:

1. Copy the juninst file from the WAS_HOME directory to the /usr/bin directory.
   For example,
   #cp /usr/WebSphere/AppServer/juninst /usr/bin
2. Rerun the uninstall.sh file from the WAS_HOME directory.

#./uninstall.sh

Keeping applications with DB2 settings from failing with WebSphere Application Server V3.5 with FixPak 7 (Defect 111066)

When you code the application with the DB2 settings, CursorHold off and AutoCommit on, WebSphere Application Server applications and Samples fail and produce the error,
CLI0125E Function sequence error.

To fix this problem, apply DB2 UDB V6.1 APAR IY22199.

Apply this defect to the following DB2 UDB V6.1 FixPaks:

FixPak 7	Supported and works
FixPak 8	Apply APAR IY22199
FixPak 9	Apply APAR IY22199

This problem no longer exists with DB2 V61 FixPak 10.

For background information, see the technical note.

Using the custom options of the WebSphere Application Server migration utility with a non-DB2 database (Defect 99541)

Edit the startupServer.sh, setupCmdLine.sh, and admin.config files so that they set parameters for the database used, and not for DB2. Then, start the WebSphere Application Server V3.5 administrative server process.

Viewing the README file successfully (Defect 83618)

Ensure that the HotJava browser can start. If not, use another browser to view the README file.

Visiting the database page to configure databases (Defects 96419, 101612)

To fix this problem:
Set the doc_root for your Web server to the appropriate value.

Set the doc_root to HTTP_HOME/htdocs/language_locale for the IBM HTTP Server and Apache. If you set your system to United States English, change doc_root to HTTP_HOME/htdocs/en_US. If you do not have your system set to United States English, specify the appropriate language_locale value for your system.

For other Web servers, replace HTTP_HOME/htdocs with the following values:

Domino

HTTP_HOME/domino/html

iPlanet 4.x and SunOne 6.0x

HTTP_HOME/docs

Microsoft Internet Information Server

HTTP_HOME/wwwroot

Netscape Enterprise Server

HTTP_HOME/docs

Manually allowing WebSphere Application Server to verify an application server repository (Defect 101324)

You can manually enter the com.ibm.ejs.sm.adminServer.dbInitialized property to the admin.config file located in the bin directory of the WebSphere Application Server installation directory. Remove this property after repository creation.

The current behavior of the com.ibm.ejs.sm.adminServer.dbInitialized property, with regard to the repository verification follows:

Property: Does not exist in admin.config

Repository: Does not exist

Action:	Create repository and add to admin.config:

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

Trace Msg: None

Property: Does not exist in admin.config

Repository: Exists

Action:	Attempt to create repository and add to

        admin.config:

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

Trace Msg: Tables already exist



Property: Exists in admin.config with a value of true

Repository: Does not exist

Action:	Create repository

Trace Msg: None

Property: Exists in admin.config with a value of true

Repository: Exists

Action:	Verify table existence

Trace Msg: Tables already exist

Property: Exists in admin.config with a value of false

Repository: Does not exist

Action:	Create repository, value of

        com.ibm.ejs.sm.adminServer.dbInitialized

        remains false

Trace Msg: None

Property: Exists in admin.config with a value of false

Repository: Exists

Action:	Value remains false for

        com.ibm.ejs.sm.adminServer.dbInitialized

Trace Msg: Tables already exist

Property: Exists in admin.config with a value

          of nocreate

Repository: Exists/does not exist

Action:	Repository will not be created, value of

        com.ibm.ejs.sm.adminServer.dbInitialized

        remains nocreate

Comment: This flag is for OS/390 users and

        should not be set otherwise.

Installing the Sun ONE Web Server with the WebSphere Application Server plug-in installed (Defect 158820)

When you start the Sun ONE Web Server (formally iPlanet Web server ) with the WebSphere Application Server plug-in installed, the Web server can fail with a segmentation violation (SIGSEGV).

To solve this problem, change the Sun ONE Web Server configuration. Making this change resets the obj.conf file and the WebSphere Application Server plug-in lines are lost from the obj.conf file. Back up the obj.conf file to use as a reference later.

Complete the following steps before installing WebSphere Application Server Version 3.5 with FixPak 7 so that you do not need to add the plug-in lines manually.

To change the configuration of Sun ONE Web Server, you need to disable Java through these steps:

1. Open the iPlanet administrative console from the URL: http://hostname:8888.
2. Select your HTTP server and select Manage.
3. Deselect the two boxes: Enable Java globally and Enable default class under Java.
4. Click Apply.
5. Restart the Sun ONE Web Server.
6. Regenerate the plug-in after WebSphere Application Server is started.

If you perform these steps after installing WebSphere Application Server Version 3.5 with FixPak 7, you need to add the following lines to the /usr/iplanet/servers/https-< hostname>/config/obj.conf file directly after the <Object name=default> line in the obj.conf file:

NameTrans from="/IBMWebAS" fn="pfx2dir" dir="/usr/WebSphere/AppServer/web"
PathCheck fn="auth_exit"
service fn="service_exit"

Note: The first line must be modified to point to the proper WebSphere Application Server path.

Additional AIX packages might be required when installing WebSphere Application Server (Defect PQ71546)

If you are using the install.sh script to install Websphere Application Server Version 3.5 on an AIX machine that has the minimum required AIX level (for example, AIX 4.3.3 maintenance level 2, AIX 4.3.3.4) or attempting to start the administrative console, you could get the following error message and the installation silently fails:

Exception in thread 'main' java.lang.UnsatisfiedLinkError:
USER\IBM\WEBAS\JAVA\JRE\BIN\LIBAWT.A file in path not found

The IBM Software Development Kit Version 1.2.2 requires additional X11 and BOS packages that might not be present on the minimum required AIX level machine. The following additional filesets are required for installation and you can find them on the AIX 4.3.3 installation media:

x11.adt.lib 4.3.3.0
x11.adt.motif 4.3.3.0
bos.adt.include 4.3.3.0
bos.adt.prof  4.3.3.0

Configuring WebSphere Application Server to use Sybase as a repository (PQ67688)

To configure WebSphere Application Server to use Sybase as a repository, add your JDBC JAR file to the administrative server Java virtual machine arguments and set up the administrative repository attributes in the admin.config file. For example:

com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-Xmx128m -Xminf0.15 -Xmaxf0.25 
-Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util -Dcom.ibm.CORBA.iiop.noLocalCopies=true 
-Dws.ext.dirs=E:/WebSphere/AppServer/java/lib;E:/WebSphere/AppServer/classes;
E:/WebSphere/AppServer/lib/ext;E:/WebSphere/AppServer/lib;d:/sybase/jConnect-5_2/classes 
... 
# Repository database settings 
com.ibm.ejs.sm.adminServer.dbdataSourceClassName=com.sybase.jdbc2.jdbc.SybConnectionPoolDataSource 
com.ibm.ejs.sm.adminServer.dbserverName=FLATPICK 
com.ibm.ejs.sm.adminServer.dbportNumber=1963 
com.ibm.ejs.sm.adminServer.dbdatabaseName=WAS 
com.ibm.ejs.sm.adminServer.dbuser=EJSADMIN 
com.ibm.ejs.sm.adminServer.dbpassword=EJSADMIN 
#   URL is only valid for Oracle 
#com.ibm.ejs.sm.adminServer.dbURL=jdbc:oracle:thin:@FLATPICK:1963:WAS
in setupCmdLine, you need to update several variables to point to your Sybase installation, e.g. 
  
... 
SET DB2DRIVER=D:\sybase\jConnect-5_2\classes\jconn2.jar 
SET DBDRIVER_PATH=D:\sybase\jConnect-5_2\classes 
SET DB_PATH=d:\sybase 

Instructions for installing the Merant driver (Defect PQ54650)

The correct information for the Merant driver Web sites follow:

Use the DataDirect SequeLink Java Web site for installation instructions:

SQL server overview: http://www.datadirect-technologies.com/jdbc/sljava/ddpsl5_sqlserver.asp

Oracle: http://www.datadirect-technologies.com/jdbc/sljava/ddpsl5_oracle.asp

Product documentation: http://www.datadirect-technologies.com/jdbc/techresources/productdoc/jtdocument.asp

Install IBM HTTP Server manually to avoid getting an error message (Defect PQ63392)

You might get the following error message when trying to install IBM HTTP Server on a Linux/390 machine:

ERROR:  "file /etc/rc.d/init.d from install of
IBM_HTTP_Server-1.3.12.2 conflicts with file from package
aaa_dir-2000.12.20-1"

To solve this problem, install IBM HTTP Server manually by issuing rpm -ivh --replacefiles *.rpm command. You can do this when you are in the directory with all the IBM HTTP Server rpms.

• Getting the administrative console after downloading it from the Internet
• Having all nodes in a domain at the same FixPak level so the administrative domain works properly (Defect 94936)
• Starting the application server with different installation directories (Defect 94908)
• Making the Web-based browser administrative console available after the default server stops (Defect 78303.RN)
• Using XMLConfig instead of the XML import feature to handle security configurations (Defect 82455.RN)
• Resizing the left panel of the Java administrative console (Defect 70298)
• Using the administrative repository on DB2/390 (Defect PQ49995)

• Improving the administrative console font (Defect 99390)

• Using the administrative console on Linux Advanced (Defect 112950.RN)
• Using another window manager instead of Sawfish to work with the administrative console (Defect 113277)

• Starting the administrative console using Oracle as the database (Defect 85101.RN)

• Displaying the Java administrative console correctly (Defect 83810)
• Repainting and resizing screens properly (Defect 80592.RN)
• Stopping the administrative server (Defect PQ44787)

• Displaying the Java administrative console correctly (Defect 83810)
• Repainting and resizing screens properly (Defect 80592.RN)
• Refraining from stopping the administrative server while it initializes or starts servers(Defect PQ44787)
• Using Microsoft Internet Explorer so that the Web application property sheet appears

Getting the administrative console after downloading it from the Internet

Having all nodes in a domain at the same FixPak level so the administrative domain works properly (Defect 94936)

The WebSphere Application Server administrative domain requires all nodes at the same FixPak level for domain administration to work properly.

Starting the application server with different installation directories (Defect 94908)

Edit the properties for the RemoteSRP bean under the default container of the administrative agent node in the administrative console, so that the JAR file property specifies the correct path to the ibmwebas.jar file.
For example: C:\WebSphere\AppServer\lib\ibmwebas.jar

Making the Web-based browser administrative console available after the default server stops(Defect 78303.RN)

The Web administrative console runs under the default server. Stopping the default server makes the HTTP administrative console unavailable. Start the default server and then try restarting the HTTP administrative console.

Displaying the Java administrative console correctly (Defect 83810)

Uninstall and reinstall the WebSphere Application Server, including the Java administrative console. You can also install the administrative console on a remote machine, to use for administering the remote administrative server.

Using XMLConfig instead of the XML import feature to handle security configurations (Defect 82455.RN)

Use the XMLConfig command line utility for security configurations that include passwords, instead of the XML import feature.

The XML import feature adversely affects security confirmations, which require the variable substitution feature of XML import to replace password variables in the XML file with actual values. Instead, the feature exports password variables and replaces them during import. This procedure limits password exposure to the import command.
Security configuration areas affected by this password limitation include administrator access, Lightweight Third-Party Authentication, Lightweight Directory Access Protocol, and enterprise application identities.

Improving the administrative console font (Defect 99390)

1. Download the TT font. Locate this font at http://www6.software.ibm.com/dl/dklx130/dklx130-p. Finish the user registration prior to downloading, if you have not registered before. The size of the font can exceed 20 MB.
2. Copy the downloaded fonts to the JAVA_HOME/jre/lib/fonts directory.
3. Edit the font property file. The font property files in the IBM Java2 SDK are preconfigured for the IBM WorldType fonts, by default. The font property file does not often need editing, except for some double-byte languages.

   For Japanese systems, edit the font.properties.ja file, in the JAVA_HOME/jre/lib directory. Replace the

   -*-minchol-medium-r-normal--*-%d-75-75-*-*-jisx0208.1983-0

   alias with:

   -monotype-timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-jisx0208.1983-0

   Also, replace

   -*-minchol-medium-r-normal--*-%d-75-75-*-*-jisx0201.1976-0

   with:

   -monotype-timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-jisx0201.1976-0

   Keep the system running when editing the font.properties file.

4. Ensure that you set the LC_ALL variable appropriately for your locale, if you still cannot see the installed font. The LC_ALL environment variable outweighs another environment variable called LANG, which also affects the current location of Java.

Repainting and resizing screens properly (Defect 80592.RN)

The window appears empty or is missing panes.

When you manually resize the window, the rest of the text and widgets display.

Do one of the following:

• Install the administrative console on a remote machine from the UNIX system running the WebSphere Application Server. Then run the following command to connect to this remote UNIX machine:

  $WAS_HOME/bin /adminclient.bat <remoteHostName>

• Use an alternative X Window manager on the Windows NT operating system.
• Use Hummingbird Exceed Version 6.1 instead. Use the X configuration tool to modify the screen definition.
• Use the following options for the Window Manager settings that appear under the Screen X tab in the Screen Definition configuration tool:

  Window Manager: Window Manager = Native Use Native WM for embedded clients = No First Window to display = No

Hummingbird Exceed Version 6.2.0.18 and later also works. Follow the instructions above for configuring the Window Manager. Exceed requires a patch to work. Without the patch, windows size incorrectly. With the patch, some of the error and message dialog boxes still have clipped edges, so you need to manually resize these windows. Contact Robek Corporation for an upgrade patch to Exceed Version 6.2.0.18, or later. To determine the Exceed patch level you need:

1. Open the Exceed Xconfig tool.
2. Open Troubleshooting.
3. Click View in the Troubleshooting window. The version lists at the top of the Exceed log. For example, after applying the patch Exceed.exe 6.0.2.18, in the Exceed.log file, the version lists as 6.2.0.18.

See InfoCenter article 1.2.2.4.1.1 for more tips and instructions.

Resizing the left panel of the Java administrative console (Defect 70298)

Click the Topology view, then resize the left panel to fix this problem.

Refraining from stopping the administrative server while it initializes or starts servers (Defect 85101.RN)

5803af6d DBMgr W Exception on database query:

 "select * from ejsadmin.REL_DEFN_TABLE where

 SOURCE_TYPE = ? or TARGET_TYPE = ?"

 com.ibm.ejs.cm.portability.

 ResourceAllocationException:

 ORA-01000: maximum open cursors exceeded

To fix this problem:

1. Update the initorcl.ora file and increase the open_cursors=200 value to open_cursors=220.
2. Stop the administrative server and administrative console.
3. Stop and restart Oracle.
4. Restart the administrative server and administrative console .

Refraining from stopping the administrative server while it initializes or starts servers (Defect PQ44787)

It is recommended that you not stop the administrative server while it initializes or starts application servers. End any running java.exe processes using the Task Manager.

Using Microsoft Internet Explorer so that the Web application property sheet appears

To avoid this problem, use Microsoft Internet Explorer as your browser.

Using the administrative console on Linux Advanced (Defect 112950.RN)

Use the Cancel button to close the wizard. The operation completes successfully.

Using another window manager instead of Sawfish to work with the administrative console (Defect 113277)

Use a different window manager to work with the administrative console.

Using the administrative repository on DB2/390 (Defect PQ49995)

• PQ48709 - Fixes a bug in Inactive
• PQ48949 Thread Support - Fixes a bug in a TCP/IP response

Set the value of RRULOCK to yes in the DB2/390 configuration parameters.

This procedure applies to DB2 Version 6.1 FixPak 4, or later.

• Deploying enterprise beans to the WebSphere Application Server (Defect 111660)
• Using the results of an enumerated finder outside a transaction (Defect 85287.RN)
• Missing DB2/390 Samples support (Defect PQ47938)
• Interpreting server-side exceptions in stack traces (Defect 53599)
• Loading a JAR file with the Jetace tool
• Maintaining data in nonpersisted fields across transactions
• Requesting database connections on DB2
• Supporting the FOR UPDATE clause on databases (Defect 93761.RN)
• Viewing a distributed transaction (Defect 84714, 84525)
• Setting the system property NoLocalCopies to true causes a data integrity problem (PQ62081)
• Incorrect BeanNotEntrantException thrown by the EJB container (PQ70353)
• Cannot create a bean within a bean with RollbackOnly set (Defect 156430)

• Deploying specific beans within a JAR file (Defect 89164)

• Configuring resource security to an existing enterprise application (Defect 92771.RN)
• No Binary Large Object or Character Large Object support for Version 3.5 on HP machines

• Deploying specific beans within a JAR file (Defect 89164)

• Deploying specific beans within a JAR file (Defect 89164)
• Starting the administrative server on a Solaris Operating Environment in Traditional Chinese locale (Defect 112431.RN)

Deploying enterprise beans to the WebSphere Application Server (Defect 111660)

This note applies to enterprise beans that developed in VisualAge for Java and use the following features:

• Nonprimitive data types
• Inheritance
• Associations
• Mapped with the VisualAge for Java schema tools

Deploy these enterprise beans within VisualAge for Java. Do not use the WebSphere Application Server deploy tool.

Using the results of an enumerated finder outside a transaction (Defect 85287.RN)

Consider an inheritance hierarchy involving the CMP beans, Bean P (Parent) and Bean C (child). Assume that one instance of P (P1) and one instance of C (C1) exists. An enumerated finder on P returns P1 and C1. However, attempts to use C1 outside the transaction in which the finder was run, results in the methods having the behavior of P, not the behavior of C.

Clients should start a transaction before running enumerated finders on CMP hierarchies, and use the results of the finder within the same transaction. Following the scenario described above, attempts to use C1 demonstrate the behavior of C, as expected, instead of the behavior of P.

Deploying specific beans within a JAR file (Defect 89164)

Drive, com.transarc.systest.ejs.webpennies.

EJBCount does not exist. Please verify the

appropriate drive was given.

where webpennies and EJBCount refer to the application used for testing.

The error occurs when you try to deploy only one entity bean stored within a JAR file. Select the entire *.jar file for deployment. Click Yes at the option to deploy all the entity beans within the file.

Configuring resource security to an existing enterprise application (Defect 92771.RN)

While configuring resource security to an existing enterprise application, a HotSpot virtual machine error can occur while adding an enterprise Java bean clone. This error causes your administrative server to restart.

Resolve this issue by disabling the HotSpot compiler. Remove the HotSpot compiler from the run-time path.
For example:

mv /opt/WebSphere/AppServer/java/jre/lib/PA_RISC/hotspot
/opt/WebSphere/AppServer/java/jre/lib/PA_RISC/hotspot.bak
mv /opt/WebSphere/AppServer/java/jre/lib/PA_RISC2.0/hotspot
/opt/WebSphere/AppServer/java/jre/lib/PA_RISC2.0/hotspot.bak

Starting the administrative server on a Solaris Operating Environment in Traditional Chinese locale (Defect 112431.RN)

If you want to start the administrative server on a Solaris Operating Environment in Traditional Chinese locale, you must set the locale to zh_TW.BIG5. Using the locale setting of zh_TW locale does not work.

Missing DB2/390 Samples support (Defect PQ47938)

The DB2/390 platform does not support the Samples provided with the WebSphere Application Server because these Samples were not developed using VisualAge for Java.

Interpreting server-side exceptions in stack traces (Defect 53599)

Enterprise bean clients must have access to server-side exception classes to interpret server-side exceptions in stack traces. Examine the server-side trace logs for complete error information, or make server-side classes available on the client.

Loading a JAR file with the Jetace tool

When using the Jetace tool, make sure all dependent classes and their dependencies are in the classpath.

See InfoCenter article 6.3 for guidance.

Maintaining data in non-persisted fields across transactions

Entity beans should not rely on data stored in non-persisted fields, particularly, references to other beans. This data is not maintained across multiple transactions. Entity bean instances are stored in an object pool between transactions. Each time a new transaction begins, it retrieves one of the entity bean instances in the pool and loads persisted data for the requested bean. Non-persisted fields can contain values previously set by a different bean. If necessary, you can reinitialize the data in the non-persisted field in the ejbLoad() method of the bean.

Requesting database connections on DB2

Supporting the FOR UPDATE clause on databases (Defect 93761.RN)

When a database does not support the FOR UPDATE clause and the following access pattern appears frequently, deadlocks can occur in the database.

    Transaction 1:
       Select * from tb1 where id=1
       Select * from tbl2 where id=2
		     ---------------------------- x
       Update tbl2 .. where id = 2
       Update tbl1  ... where id=1
	   
    Transaction 2:
       Select * from tb1 where id=1
       Select * from tbl2 where id=2
		     ----------------------------- x
       Update tbl2 .. where id = 2
       Update tbl1  ... where id=1

No Binary Large Object or Character Large Object support for Version 3.5 on HP machines

Any CMP bean used to run on the HP platform with DB2 as its persistent store, cannot designate a Serializable object type as a CMP field.

Viewing a distributed transaction (Defect 84714, 84525)

To stop the console from hanging, restart the administrative console. However, you still cannot access the transaction monitor.

Setting the system property NoLocalCopies to true causes a data integrity problem (PQ62081)

When you set the system property NoLocalCopies to true, you could experience a data integrity problem if a single PrimaryKey object is created and reused for several enterprise beans.

The temporary workaround is not to specify the property to true.

Incorrect BeanNotEntrantException thrown by the EJB container (PQ70353)

Under the following circumstances, a BeanNotEntrantException can be incorrectly thrown by the EJB container:

• During a bean creation, the ejbCreate() is called in the user provided bean implementation. The ejbCreate() throws an unchecked exception, for example, a user-defined security exception.
• The create method of a bean runs in an unsupported transaction attribute, which means a local transaction is created in the create method called. This local transaction is associated to the thread in which the create method runs.
• If the method call has a transaction attribute that requires a new transaction, for example, TX_Required, the local TX is suspended and a new transaction is resumed. The enlistment of this new transaction is prohibited because the bean has already been enlisted in the original global transaction. Thus, the BeanNotEntrantException is thrown.

This problem is solved in WebSphere Application Server Version 3.5.7.

Cannot create a bean within a bean with RollbackOnly set (156430)

Creating an instance of another enterprise bean type or calling a method with TX_REQUIREDNEW within an enterprise bean that has been marked RollbackOnly results in a CSITransactionRolledbackException thrown from the EJB container.

Currently, there is no workaround for this problem.

• Enabling security on a thin servlet redirectory (Defect 90327)
• Select the Make a Clone option when creating clones on the same node (Defect 93693)
• Disabling the checking of URIs during a clone creation to save time (Defect 111818, PQ51576)
• Removing and installing theServletRedirector when the PluginCfgGenerator fails when generating plug-in information for the ServletRedirector (Defect 122590)
• Standalone Java clients must handle their own reauthentication of expired credentials (Defect PQ48143)
• Ignoring error messages that appear when clients prematurely end connections (Defect 94670.RN)
• Getting InvokerServlet to work with WebSphere Application Server FixPak 3 and later (Defect 92747.RN)

• Ignoring the error produced when adding a servlet from the Wizard tab (Defect 85389.RN)

• Setting Max Connections to less than 25 to avoid servlet engine problems (Defect 98019)

• Understanding case sensitivity and the File Serving Enabler Servlet (Defect 98847)

• Setting case-sensitivity for files when served by the File Serving Enabler Servlet (Defect 98847)

Setting Max Connections to less than 25 to avoid servlet engine problems (Defect 98019)

Set the Max Connections to 25, the default and optimal setting.

Ignoring the error produced when adding a servlet from the Wizard tab (Defect 85389.RN)

RepositoryOpException:

 Unexpected naming exception and other exceptions.

Ignore the error. The servlets are created.

Setting case-sensitivity for files when served by the File Serving Enabler Servlet (Defect 98847)

Set case sensitivity for JSP files, HTML and associated image files to resolve a security hole on Windows platforms. If a resource was secured using a URI, only the exact case match was secured. The implementation change affects both secured and non-secured URIs.

To stop receiving 404 errors, change your application.

Enabling security on a thin servlet redirectory (Defect 90327)

To enable security on the thin servlet redirector, define the property in both the plug-in configuration file and the script or batch file first.

Dcom.ibm.CORBA.ConfigURL=file:/D:/WebSphere/AppServer/properties/sas.client.props

Examples of a plug-in configuration Java command:

java -Dcom.ibm.CORBA.ConfigURL=file:/D:/WebSphere/AppServer/properties
  /sas.client.props com.ibm.servlet.engine.oselistener.systemsmgmt.StandalonePluginCfg 
  -serverRoot D:\WebSphere\AppServer -adminNodeName ws-ray -queueProps 
  d:\websphere\appserver\properties\iiopredirector.xml -traceString *=all-disabled 
  -traceFile pluginCfg_trace.log -nameServicePort 900

Example of a script and batch file:

Java -Dcom.ibm.CORBA.ConfigURL=file:/D:/WebSphere/AppServer
  /properties/sas.client.props -Dcom.ibm.CORBA.ListenerPort=9999 -Dserver.root=
  d:\websphere\appserver com.ibm.servlet.engine.ejs.IIOPRedirector -traceString *=all
  =disabled -traceFile iiopredirector_trace.log

To enable security, complete the following steps:

1. Configure an enterprise application.
   a. Click Tasks and expand Configuration from the WebSphere Application Server administrative console.
   b. Select Configuration A.
   c. Provide an application name, for example, ServletRedirectorEA. Click Next.
   d. Expand EnterpriseBeans and select RemoteSRP. Click Add, and then click Finished.
   e. Specify Global Settings.
   f. Check Enable Security.

2. Configure resource security.
   a. Click Tasks and expand Security from the WebSphere Application Server administrative console .
   b. Select Configure Resource Security.
   c. Expand EnterpriseBeans and select RemoteSRP.
   d. Click Next, and then click Finished.

3. Assign permissions.
   a. Click Tasks and expand Security from the WebSphere Application Server administrative console.
   b. Select Assign Permissions.
   c. Select all ServletRedirectorEA=*Method*, and then click Add.
   d. Select All authenticated users or your selection policy, and then click OK.
   e. Select all ServletRedirectorEA= * Methods. Click Add.
   f. Choose All authenticated users or your selection policy. Click OK.
4. Start ServletRedirectorEA.
   This option starts the RemoteSRP bean, but goes back, stops, and restarts the Web server.
5. To authenticate servlet redirector as a non-root user ID for other users to access this bean.
   a. Click Tasks and expand Security from the WebSphere Application Server administrative console.
   b. Select Assign Permissions.
   c. Select all AdminApplication=*Methods. Click Add, and then click Appropriate.
   d. Select all authenticated users, and then click OK.

Select the Make a Clone option when creating clones on the same node (Defect 93693)

When you create a clone on the same node, select the option Make XXX a clone when creating the model. When you create a clone on a different node, you do not need to select this option.

Removing and installing theServletRedirector when the PluginCfgGenerator fails when generating plug-in information for the ServletRedirector (Defect 122590)

If you are upgrading from WebSphere Application Server Version 3.5.3 to Version 3.5.6 and the PluginCfgGenerator fails when generating the plug-in information for the ServletRedirector, you need to remove and then install theServletRedirector again. If the ServletRedirector is not needed for your configuration, you can permanently remove it or disable it and then try to generate the plug-in information.

Disabling the checking of URIs during a clone creation to save time (Defect 111818, PQ51576)

To disable the checking of URIs during a clone creation, perform the following steps:

1. In the <install_root>/AppServer/bin directory, edit the admin.config file.
2. If you want to disable URI checking, add the following line to the bottom of the file:

   com.ibm.ejs.sm.adminServer.uriCheck=false

   The default setting for this property is true. If you do not include this property in the admin.config file, the system checks URIs.
3. Save the admin.config file.
4. Restart the administrative server.

Standalone Java clients must handle their own reauthentication of expired credentials (Defect PQ48143)

For standalone Java clients, implement your own code to reauthenticate credentials, if both the password and Lightweight Third-Party Authentication token have expired.

When a user accessing an EJB application tries to authenticate, a user name and password credential is created and passed to the EJB application. The EJB application uses the credential to validate against the Lightweight Third-Party Authentication token. (If the LTPA token is not available, the EJB application validates the credential directly with the Lightweight Directory Access Protocol server). If the LTPA token has expired, the EJB application uses the credential to check the LDAP server to create a new LTPA token credential automatically -- unless the LTPA token expired because it was not accessed during security cache timeout period. In the latter case, the EJB application will return an authorization failure.

When a user accessing a Web application tries to authenticate, and the LTPA token has expired, the application server detects the problem and automatically invokes the authentication mechanism again.

When a user accessing a Java client tries to authenticate, and the LTPA token has expired, the result depends on how the Java client has been coded to handle the need to reauthenticate in the situation of expired credentials.

Ignoring error messages that appear when clients prematurely end connections (Defect 94670.RN)

An IOException displays when a client sends a request to the WebSphere Application Server and then terminates the connection before sending the entire response. This exception occurs when the responding servlet attempts to send data to the disconnected client. Servlets need to anticipate and handle this IOException, but the servlet programmer can also use it as a signal to end processing, since the client no longer requests data.

When a client prematurely ends a connection to the servlet engine, the following error displays:

Client terminated connection to server before the entire response was sent.

This error message does not indicate a problem and occurs during normal operation, as browsers close, or other network outages occur.

Getting InvokerServlet to work with WebSphere Application Server FixPak 3 and later (Defect 92747.RN)

404 Not found error

The problem results from a FixPak 2 change to URI handling.

1. Go to the Topology view of the administrative console.
2. Click Auto-Invoker, or the InvokerServlet servlet, under the Web application.
3. Click Servlet Web Path List, click Edit, on the General Properties panel.
4. Modify the servlet path to end in /*.
5. Click OK.
6. Click Apply.
7. Stop and restart the application server.

• JavaServer Pages V1.1 is not available for tracing and debugging of the JavaServer Pages files
• JSPWriter reports buffer information for getRemaining()and etBufferSize()(Defect 108783)
• Locating JavaServer Pages files in subdirectories (Defect 92049.RN)
• Creating separate target directories for each clones (Defect 88763.RN)
• Making sure the flastmod query exists to avoid false dates and times (Defect 54574)

JavaServer Pages V1.1 is not available for tracing and debugging of the JavaServer Pages files

JSPWriter reports buffer information for getRemaining()and etBufferSize() (Defect 108783)

getRemaining()
getBufferSize()

#characters= 2 bytes each

Locating JavaServer Pages files in subdirectories (Defect 92049.RN)

Can not write: long_file_name

To fix this problem, try the following workarounds:

1. Reduce the subdirectory level where the JSP files nest.
2. Shorten the length of the directory names.
3. Shorten the JSP names.

Creating separate target directories for each clones (Defect 88763.RN)

To enable this feature, set up the following:

1. Create a file named global.properties in the <WAS_INSTALL_ROOT>/properties/ directory
   
   You can create this file, if it does not exist.



2. Add the following line to the global.properties file:

   com.ibm.clone.separate.temp.target.dirs=true

3. Stop and restart the Administrative Server.

Use this feature for situations where you modify JSP files repeatedly in a production environment. This feature causes a recompile to occur for each JSP file, times the number of created clones.

Making sure the flastmod query exists to avoid false dates and times (Defect 54574)

If the target file for flastmod query does not exist, or is not found, the query responds with a false date and time: Wed Dec 31 19:00 1969.

Ensure that the target of flastmod query exists in the specified path.

• Running DB2 with the default 2.4 kernel IPC parameter (Defect 111337)

• Fast Cache Response Accelerator is not currently supported on AIX V5.1 (Defect 108238.RN)

Fast Cache Response Accelerator is not currently supported on AIX V5.1 (Defect 108238.RN)

• Accessing an HTTP session (Defect PQ47998.RN)
• Ensuring that a session object is current (Defect PQ50400.DOC)
• Turning off the authorization ID association with an HTTP session (Defect 94809.DOC)
• Cannot use Java Transaction API (JTA) with the Sybase JDBC driver (Defect 83300.RN)
• Cannot use Java Transaction API for persisting sessions (Defect PQ49889)
• Using SessionReaperInterval to set the interval of the Invalidation Thread in the Session Manager (Defect PQ54352.doc)
• Using Cache is disabled when upgrading from WebSphere Application Server Version 3.5.x to Version 3.5.5 or higher (Defect PQ62952)
• Adding new system property to read the session configuration from database (Defect PQ55686.doc)

PropertySessionReaperInterval is now a new system property. Use this property to set the sleep interval of the Invalidation Thread in the Session Manager.

The instructions for applying the system property follow:

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

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

Using Cache is disabled when upgrading from WebSphere Application Server Version 3.5.x to Version 3.5.5 or higher (Defect PQ62952)

When upgrading from WebSphere Application Server Version 3.5.x to Version 3.5.5 or higher, you find Using Cache under Tuning in the Session Manager is disabled. The feature was disabled in Version 3.5.5 and is disabled as always being Yes.

Adding new system property to read the session configuration from database (Defect PQ55686.doc)

The added system property SessionConfigInit configures how many seconds the servlet engine waits before allowing session configuration readings from the database. This value overrides the hardcoded default value of 60 seconds. After this time has elapsed, you can read the configuration from the sessions.xml file. In most cases the default value of 60 seconds is adequate for the session configuration to initialize.

Perform the following steps to apply the property:

1. Run the Command Line arguments of an application server.
2. Set the system property SessionConfigInit to a value, for example, -DSessionConfigInit=100
3. Restart the application server.

Ensuring that a session object is current (Defect PQ50400.DOC)

A new system property ensures that the session object in the cache coincides with the session object persisted to the database. This property is in addition to the cache ID mechanism used for the same purpose.

To apply this property, follow these steps:

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

Turning off the authorization ID association with an HTTP session (Defect 94809.DOC)

To turn off the authorization ID association with an HTTP session, perform the following steps:

1. Set the system property to false, on a command line of the WebSphere Application Server.


For example, in the administrative console, click Default Server, and specify the system property, -DHttpSessionSecurity=false, in the command line arguments.


2. Start the server instance.

Cannot use Java Transaction API (JTA) with the Sybase JDBC driver (Defect 83300.RN)

Java Transaction API (JTA) support does not work correctly with the Sybase JDBC driver.

To work around this, create the table with JTA flag off, and then access the table with JTA on. Use a JConnect level of EBF9422 or later.

Cannot use Java Transaction API for persisting sessions (Defect PQ49889)

No additional advantages exist for using JTA for persisting sessions.

• Cannot use Java Transaction API (JTA) with the Sybase JDBC driver (Defect 83300.RN)

• Running connections with 512 MB systems

• Running more than 10 connections with 512 MB systems

Cannot use Java Transaction API (JTA) with the Sybase JDBC driver (Defect 83300.RN)

Create the table with the JTA flag off, and then access the table with JTA on.

Running more than 10 connections with 512 MB systems

Under load conditions, 512 MB systems only support a DB2 connection pool size of 10 connections.

To run more than 10 connections, you need more than 512 MB. On average, DB2 connections use between 1 MB and 2 MB each.

When sending a large number of requests, for example, 100 simultaneous users, use 512 MB to run with 10 connections. The 512 MB includes the administrative server, application process, and so on. DB2 connections usually run about 1.5 MB to 2 MB, so if you want to run more than 10 connections, you need more than 512 MB.

• Adding a new Java Naming and Directory Interface property to allow a choice between resolution of the Java Naming and Directory Interface administrative server failover problem and Java Naming and Directory Interface interoperability with Component Broker and third-party name servers (Defect 117410.RN)
• Recovering from an administrative server failure
• Enabling workload management of requests from one WebSphere Application Server administrative domain to another (Defect 118925.RN)
• Setting up a workload management environment with clones (Defect PQ47372)
• Using a model, clone, and a remote node name in the main server default host (Defects 101332, 101336, 103823)

• Ensure that the correct version of RMIC exists in the path for WLMJAR to operate correctly

• Choosing the IBM Software Development Kit version with the WLMJAR program

• Choosing the IBM Software Development Kit version with the WLMJAR program

Adding a new Java Naming and Directory Interface property to allow a choice between resolution of the Java Naming and Directory Interface administrative server failover problem and Java Naming and Directory Interface interoperability with Component Broker and third-party name servers (Defect 117410.RN)

A Java Naming and Directory Interface (JNDI) lookup fails if a CosNaming NamingContext used for the lookup is in an administrative server which is no longer running.

The lookup failure should not occur in this situation; instead, the request should automatically sent to the logically equivalent CosNaming NamingContext in an administrative server that is still running. The root cause of JNDI administrative server failover is a Workload Management issue that cannot be resolved in WebSphere Application Server Version V3.5, but is fixed in WebSphere Application Server Version 4.0.x.

For a JNDI property to bypass JNDI administrative server failover, interoperability with non-WebSphere Application Server naming servers is affected. A new JNDI property com.ibm.websphere.naming.jndi.interoperability is added to allow a choice between resolution of the JNDI administrative server failover described above and JNDI interoperability with Component Broker and third-party name servers. This property is set to partial by default so that the problem is avoided, however, it also disables JNDI interoperability with Component Broker and third-party name servers. If Component Broker or third-party name server interoperability is desired, pass the following property setting into the InitialContext constructor: com.ibm.websphere.naming.jndi.interoperability=full.

Note: Setting this property to full interoperability is not compatible with the support for JNDI administrative server failover. If you require JNDI administrative server failover support, only set the property to full when your InitialContext connects directly to Component Broker or third-party name servers.

Recovering from an administrative server failure

1. Stop the client.
2. Edit the BootstrapNode and BootstrapHost properties files on the client to point to a remaining live administrative server.
3. Restart the client application.

Choosing the IBM Software Development Kit version with the WLMJAR program

Ensure that your SDK \bin directory does not appear before the WebSphere Application Server \bin directory in your PATH environment variable.

Enabling workload management of requests from one WebSphere Application Server administrative domain to another (Defect 118925.RN)

This note includes the code necessary to enable workload management of requests from one WebSphere Application Server administrative domain to another domain.

Please be aware of the following restrictions:

• Each server group name must be unique across all WebSphere Application Server administrative domains. The client must not attempt to access objects in server groups from separate domains with the same server group name. That is, server group names must be unique for all server groups in all domains.
• The first request by an object uses the remote reference that the client received directly without workload management intervention and thus does not participate in workload distribution or failover. All subsequent requests from that client to the server group where the object resides will participate in workload distribution and failover.
• This restriction is an extreme case that is not likely to occur but is here for completeness. If a client has not completed a request to a server group while all servers in the group were removed and replaced with new clones, the client will not be able to successfully contact any server in the group. The client process must be stopped and restarted to reconnect to the servers.

  An example of this restriction:

  A payroll application that queries beans in a foreign domain monthly to retrieve data. That application, acting as a client to the foreign domain, retrieves workload management information using the subject ptf. At some point while the payroll client is not accessing beans in the foreign domain, the foreign server group stops and removes all servers. New server clones are created and then started. Hence, the beans are alive and accessible. However, since the payroll client does not have the new server group information and can not access the administrative repository in the foreign domain, the client will not be able to access the beans. This would be considered highly irregular and certainly not a recommended approach.

• An expected audit message will occur when a client from a WebSphere Application Server Version 3.5.6 domain that attempts to access a foreign server group in a WebSphere Application Server Version 4.0 domain. This message is benign and may be safely ignored.

  AUDIT [<host name>/<client name>]: Server group was not found in the configuration information manager within the readVersion40 method

  Because the WebSphere Application Server Version 3.5.6 administrative domain acting as the clients bootstrap domain tries to access server group information about the WebSphere Application Server Version 4.0 group from its local domain. The local domain does not have any information about the foreign group and an exception is thrown. The information will be retrieved from the clone on the response from the first request instead.

• An expected audit message will occur when a client attempts to access foreign server group information. This message is benign and may be safely ignored.

  AUDIT [<host name>/<client name>]: EJSW0029W: The findByName("<server group name>") method failed on the ModelHome object with the exception: javax.ejb.ObjectNotFoundException

  Because the WebSphere Application Server administrative domain acting as the clients bootstrap domain tries to access server group information about the group from its local domain. The local domain does not have any information about the foreign group and an exception is thrown. The information will be retrieved from the clone on the response from the first request instead.

Ensure that the correct version of RMIC exists in the path for WLMJAR to operate correctly

Ensure the correct version of RMIC exists in the path. Use the link in the /usr/bin directory for RMIC, to correct the problem. Execute the following:

ln -sf

 /usr/WebSphere/AppServer/hosts/default_host/

   admin/install/aix/rmic

 /usr/bin/rmic

Setting up a workload management environment with clones (Defect PQ47372)

Workload Management in Version 3.5.4 replaces a least loaded algorithm with a Round Robin or Random algorithm.

WebSphere Application Server WLM, as provided by the Web server plug-ins attempts to distribute the workload among peer servers, or clones. The clones make no distinction regarding the host machine, or the clone capacity. WLM considers all clones equal.

Round Robin clone selection follows steps through the clones in order, as requests come in. The first request goes to the first clone, the second request goes to the second clone, and so on. After the last clone receives a request, the next request goes to the first clone. The plug-in selects a random clone to start with, so when WLM starts with heavy traffic, the work initially distributes randomly among the clones.

Random clone selection identifies a clone randomly each time a request arrives. Enable random selection by setting ose.srvgrp.ibmoselink.clone.selection=RANDOM in the bootstrap.properties file, for ibmoselink queue.

If you have session affinity enabled, any request that contains a cookie, or URL, with a WebSphere Application Server session ID bypasses WLM and routes to a single clone. Different session IDs select different clones, but a particular session ID connects to the same clone, the one for which it has a session affinity. You can enable or disable session affinity in the bootstrap.properties file. The default is ose.session.affinity=true.

If any of the defined clones stop, WLM uses the Failover strategy for requests which would otherwise select that clone. When sending a request to a clone results in an error, WLM marks the clone as failed. No more requests go to that clone except when the fail recovery time expires. When the recovery time expires, WLM sends the next request for that clone to determine if the clone is back in service. If that request proves successful, then WLM marks the clone as operational and normal request handling proceeds. Stopping clones is not recommended during heavy usage because some requests went to a stopped clone and were delayed before they were routed to another clone. If you know a clone is down for a day, remove the clone using the administrative console, rather than stop the clone for the day.

Refer to the IBM Redbook WebSphere Scalability: WLM and Clustering for more information.

Using a model, clone, and a remote node name in the main server default host (Defects 101332, 101336, 103823)

A Web server installed on an independent machine that is neither a local node, or a remote node for a model and clone, does not require a workaround.

This workaround applies to the Apache, IBM HTTP Server, iPlanet, and Netscape Enterprise Server Web servers. Edit the queues.properties and bootstrap.properties files.

For example, when using the IBM HTTP Server:

1. Follow the usual steps for configuring remote OSE:
   1. Create your final configuration for application servers and clones.
   2. Modify the host alias entry on the virtual host, as required.
   3. Change the servlet engine transport to INET sockets on Windows NT and AIX operating systems.
   4. Start your application server or model.
   5. Stop the application server or model and the administrative server after the queues.properties file in the WebSphere_root/temp directory refreshes.
   6. Modify the queues.properties file to reflect your configuration.
2. Modify the queues.properties file so that both machines are remote:

   #IBM WebSphere Plug-in Communication Queues
   
   ose.srvgrp.ibmoselink.clonescount=2
   
   ose.srvgrp=ibmoselink
   
   ose.srvgrp.ibmoselink.type=FASTLINK
   
   ose.srvgrp.ibmoselink.clone1.port=8110
   
   ose.srvgrp.ibmoselink.clone1.type=remote
   
   ose.srvgrp.ibmoselink.clone1.host=clone1_hostname
   
   #
   
   ose.srvgrp.ibmoselink.clone2.port=8110
   
   ose.srvgrp.ibmoselink.clone2.type=remote
   
   ose.srvgrp.ibmoselink.clone2.host=clone2_hostname

3. Place the modified file and a copy of the rules.properties and vhosts.properties files into a different directory. For example, create an http subdirectory below the WebSphere_root/temp directory and place the files into the new WebSphere_root/temp/http subdirectory.
4. Copy the bootstrap.properties file in the WebSphere_root/properties directory. The key entry looks like ose.tmp.dir=d:/WEBSPH~1/APPSER~1/temp/. This property specifies the directory where the administrative server places the three properties files noted above, and where the HTTP server plug-in looks for the properties files. In the file copy, change the entry so that the HTTP Server can find the properties files. If you find the files in the WebSphere_root/temp/http directory, the entry looks like the following:
   ose.tmp.dir=d:/WEBSPH~1/APPSER~1/temp/http.

   Use a copy of the bootstrap.properties file because you want the administrative server to continue to update the properties files in their original location, and leave the modified files unchanged. To simplify file administration, create an http subdirectory under the WebSphere_root/properties directory and place the modified bootstrap.properties file in this new WebSphere_root/properties/http subdirectory.

5. Modify the plug-in entry for the bootstrap.properties file in the IBM HTTP Server and Apache configuration file. The entry looks like the following, by default:

   NcfAppServerConfig BootFile
   
   d:\WEBSPH~1\APPSER~1\properties\bootstrap.properties

   Because you want the plug-in to use the modified properties file in the WebSphere_root/properties/http directory in this example, change the entry to look like the following:

   NcfAppServerConfig BootFile
   
   d:\WEBSPH~1\APPSER~1\properties\http\bootstrap.properties

   For Netscape and iPlanet browsers, modify the obj.conf file. The entry looks like the following, by default:

   Init fn="init_exit" bootstrap.properties=
   
    "d:\WEBSPH~1\APPSER~1\properties\bootstrap.properties"

   Because you want the plug-in to use the modified properties file in the WebSphere_root/properties/http directory, in this example, change the entry to look like the following:

   Init fn="init_exit" bootstrap.properties=
   
    "d:\WEBSPH~1\APPSER~1\properties\http\bootstrap.properties"

   For Internet Information Server and Domino, modify the registry setting for the bootstrap.properties file. The path in the registry for this setting is HKEY_LOCAL_MACHINE/SOFTWARE/IBM/WebSphere Application Server/<Version>. The entry looks like the following, by default:

   bootstrap.properties "d:\Websphere\AppServer\properties\bootstrap.properties"

   Because you want the plug-in to use the modified properties file in the WebSphere_root/properties/http directory in this example, change the entry to look like the following:

   bootstrap.properties "d:\Websphere\AppServer\properties\http\bootstrap.properties"

6. Restart the administrative servers, application servers, and HTTP servers.

• Configuring steps to protect the JavaServer Pages Web paths or URIs
• Specifying two different Secure Sockets Layer port numbers for the administrative server when enabling security (Defect 81042.RN)
• Running IKEYMAN (Defect 85084.RN)
• Applying a security configuration to each clone to avoid authorization failure (Defect 85032.RN)
• Enabling security and realizing the effect on the object request broker (Defect PQ35461.RN)
• Improving Microsoft Active Directory performance (Defect PQ48364.RN)
• No support for TBSCertificate extensions for client authentication and authorization support (Defect 84263)
• Avoiding problems when using the WebSphere Application Server with Domino V5.02, V5.02B, and V5.03 (Defect 84858.RN)
• Avoiding the double-byte character set in your user ID or password when security is enabled (Defect 157723)

• Enabling shadow passwords for security (Defect 102779)

• Changing the user ID password without affecting other configuration information (Defect 74697.RN)
• Using a user ID with Administrator rights to start WebSphere Administrative Server

• Changing the user ID password without affecting other configuration information (Defect 74697.RN)
• Using a user ID with Administrator rights to start WebSphere Administrative Server

Configuring steps to protect the JavaServer Pages Web paths or URIs

When you configure steps to protect the JavaServer Pages (JSP) Web paths or URIs, these Web paths get treated as Web server resources because they are not part of a Web application. Therefore, security does not work as intended.

Do not use the Add a JSP or Web resource task to introduce new JSP Web paths (URIs), or associate with Web applications. If you have already used this task, remove all the Web paths and URIs and proceed with the following steps:

1. Click the Topology view.
2. Expand Node and click App Server > Servlet Engine to view the Web application.
3. Select the JSP file processor servlet in that application.
In the configuration panel for that JSP file, a listing of Web paths exists; this list contains the /default_host/webapp_path/*.jsp path.
4. Click Add to add to the Web path list.
5. Enter the Web paths and URIs you want to protect. For example: /default_host/webap_path/toBeProtected.jsp
6. Repeat step 5 for all the JSP files you want to protect.
7. Apply and complete this task.
8. Follow security configuration steps to protect these newly added JSP files.
9. Restart the application server.

Specifying two different Secure Sockets Layer port numbers for the administrative server when enabling security (Defect 81042.RN)

On the server command line, define two port numbers, using the -D option:

For the listener port, specify:

For the Location Service Daemon (LSD) port, specify:

The values of these two properties must differ.

Running IKEYMAN (Defect 85084.RN)

If you installed both the IBM HTTP Server and the WebSphere Application Server Advanced Edition on the same host:

• On Windows NT and Windows 2000 operating systems, enter the following commands to run the IKEYMAN key ring management tool:
  cd <install_root>\bin
  setupCmdLine.bat
  set PATH=%JAVA_HOME%\bin;
  %JAVA_HOME%\jre\bin;
  %JAVA_HOME%\jre\bin\classic;%PATH%
  set CLASSPATH=%WAS_HOME%\lib\cfwk.zip;
  %WAS_HOME%\lib\gsk4cls.jar;
  %WAS_HOME%\lib\swingall.jar;
  %CLASSPATH%
  java -Dkeyman.javaOnly=true
  com.ibm.gsk.ikeyman.Ikeyman
• On AIX, HP-UX, and Solaris Operating Environment enter the following commands to run the IKEYMAN key ring management tool:
  cd <install_root>/bin
  setupCmdLine.sh
  set LIBPATH=$JAVA_HOME/jre/bin:
  $JAVA_HOME/jre/bin/classic:$LIBPATH
  set PATH=$JAVA_HOME/bin;
  $JAVA_HOME/jre/bin;$PATH
  set CLASSPATH=$WAS_HOME/lib/cfwk.zip;
  $WAS_HOME/lib/gsk4cls.jar;
  %WAS_HOME%/lib/swingall.jar;
  $CLASSPATH
  java -Dkeyman.javaOnly=true
  com.ibm.gsk.ikeyman.Ikeyman
  
  or, instead of using the java command, run /usr/opt/ibm/gskit/bin/gsk4ikm

• On Windows NT and Windows 2000 operating systems, enter the following commands to run the IKEYMAN key ring management tool:
  
  cd <install_root>\bin
  setupCmdLine.bat
  set PATH=%JAVA_HOME%\bin;
  %JAVA_HOME%\jre\bin;
  %JAVA_HOME%\jre\bin\classic;%PATH%
  set CLASSPATH=%WAS_HOME%\lib\cfwk.zip;
  %WAS_HOME%\lib\gsk4cls.jar;
  %WAS_HOME%\lib\swingall.jar;
  %CLASSPATH%
  java -Dkeyman.javaOnly=true
  com.ibm.gsk.ikeyman.Ikeyman
• On AIX, HP-UX, or Solaris Operating Environment, enter the following commands to run the IKEYMAN key ring management tool:
  
  cd <install_root>/bin
  setupCmdLine.sh
  set LIBPATH=$JAVA_HOME/jre/bin:
  $JAVA_HOME/jre/bin/classic:$LIBPATH
  set PATH=$JAVA_HOME/bin;
  $JAVA_HOME/jre/bin;$PATH
  set CLASSPATH=$WAS_HOME/lib/cfwk.zip;
  $WAS_HOME/lib/gsk4cls.jar;
  %WAS_HOME%/lib/swingall.jar;
  $CLASSPATH
  java -Dkeyman.javaOnly=true
  com.ibm.gsk.ikeyman.Ikeyman
• Then, follow the online documentation for using the IKEYMAN tool.

Changing the user ID password without affecting other configuration information (Defect 74697.RN)

To change the user ID and password without affecting other configuration information:

1. Start the WebSphere Administrative Server and the WebSphere Application Server administrative console before changing the user ID and password in the registry, while the user ID and password remain valid in the registry.
2. Start the user management utility using LocalOS or Lightweight Directory Access Protocol tools, and then change the password.
3. Make the corresponding change to the WebSphere Application Server user registry configuration:
   1. Click Global Security Settings > User registry > ServerID and password.
   2. Apply the changes.
4. Restart the WebSphere Application Server.

Using a user ID with Administrator rights to start WebSphere Administrative Server

If the following error appears when starting the WebSphere Administrative Server, you need to add the starting user ID to the Administrator group:

com.ibm.ejs.security.registry.

   RegistryErrorException:

 Windows NT: Access is denied

The user ID for starting the WebSphere Administrative Server on Windows NT or the Windows 2000 operating systems requires Administrator rights. Add this user ID to the Administrator group.

Applying a security configuration to each clone to avoid authorization failure (Defect 85032.RN)

Apply a security configuration to each clone. In a model and clone environment, apply security to each clone that needs securing. If you have a secured model, then the security configuration does not automatically apply to all of the clones in the model. Add all clones to an appropriate enterprise application and apply a Configure Resource Security task to all of these clones.

Enabling security and realizing the effect on the object request broker (Defect PQ35461.RN)

Specify com.ibm.CORBA.SSLPort instead.

If you start an application server as:
java -Dcom.ibm.CORBA.listenerPort=7777
<other parameters>

with security enabled, start the server as:
java -Dcom.ibm.CORBA.SSLPort=7777
<other parameters>

Enabling shadow passwords for security (Defect 102779)

Security requires enabled shadow passwords.

The default installation of TurboLinux does not enable shadow passwords.

To enable shadow passwords, start up a shell as the user root. Type pwconv and press Enter.

Improving Microsoft Active Directory performance (Defect PQ48364.RN)

To change the settings for the schema class of a directory object:

1. Go to the Authentication tab of the Security Center.
2. Click the LDAP radio button.
3. Click Advanced.
4. To use objectCategory:
• Replace objectClass=user with objectCategory=user in the User Filter field.
• Replace objectClass=group with objectCategory=group in the Group Member ID Map field.
• Add ;objectCategory:group to the end of the attribute value.

No support for TBSCertificate extensions for client authentication and authorization support (Defect 84263)

The WebSphere Application Server does support certificate mapping using Subject Domain Name, or Issuer DNs.

Avoiding problems when using the WebSphere Application Server with Domino V5.02, V5.02B, and V5.03 (Defect 84858.RN)

Domino V5.05 is required for Windows 2000 operating system support.

Avoiding the double-byte character set in your user ID or password when security is enabled (Defect 157723)

The double-byte character set (DBCS) is not supported in the following three scenarios when security is enabled:

• If you use a user ID or password containing the DBCS in a Java client, the client is unable to log in or access the protected resources. This impacts the Java clients shipped with the product including, but not limited to, the WebSphere Administrative Console and XMLConfig.
• If you use a user ID or password containing the DBCS as server ID configured in global security settings, the administration server fails to come on-line.
• If an enterprise bean uses Run as a function of a user ID or password containing the DBCS, you cannot access the protected resources.

Currently, there is no solution for the problem. Avoid using the DBCS in your user ID or password when security is enabled.

• Using By Reference semantics (Defect 93415)
• Starting the WebSphere Application Server when there are a large number of EPM module objects that have different EPM levels from their parents (Defect PQ66255)
• Definition of active sessions and live sessions in WebSphere Application Server Version 3.5.7 (Defect PQ68205)

• Establishing multiple connections

• Establishing multiple connections

Establishing multiple connections

On AIX and Linux platforms, DB2 issues SQL1224N and WebSphere Application Server administrative server fails with StaleConnectionException when attempting more than ten local concurrent DB2 connections from a single process.

Catalog the DB2 databases using a TCP/IP loopback.
To implement a TCP/IP loopback without changing the application and connect to the new alias and the USER and USING parameters, see step 5 below.

1. Set up a TCP/IP port in the /etc/services directory, if a port for remote DB2 clients is not established.
2. Ensure that the DB2COMM registry parameter specifies the TCP/IP communication protocol. To check the current setting of the DB2COMM parameter, enter db2set DB2COMM. To update the DB2COMM registry variable to include TCP/IP, use the db2set command. For example:
   db2set DB2COMM=existing_protocol_names,tcpip
3. Update the SVCENAME database manager configuration parameter to the connection service name, as defined in the /etc/services directory during step 1. For example:
   db2 update dbm cfg using svcename connection_service_name
4. Catalog the loopback node. For example:
   db2 catalog tcpip node node name remote 127.0.0.1 server connection_service_name
5. Catalog the database as follows:
   • db2 catalog db database_name as database_alias
   • db2 uncatalog db database_name
   • db2 catalog db database_alias as database_name at node node name
   • Restart DB2 to refresh the directory cache.

For background information regarding this problem, see the technical note: http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?&fn=1009742.

Using By Reference semantics (Defect 93415)

Use the IBM-provided Util class by itself, without enabling By Reference (NoLocalCopies) semantics, by specifying the following property:

-Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util

In some cases this specification provides performance benefits, but possible stability issues can exist.

Starting the WebSphere Application Server when there are a large number of EPM module objects that have different EPM levels from their parents (Defect PQ66255)

There are situations where a long EPM specification string causes failure to start the WebSphere Application Server. It happens when there are a large number of EPM module objects that have different EPM levels from their parents.

To work around this problem, choose one of the following methods:

• In Resource Analyzer, set the EPM level at the root or the top level EPM module objects. For example:

  		 performance (this is root)
                EJB  (this is top level)
                container1 (this is lower level)
                       bean1 (this is lower level)
                 .....
                ORB Thread Pool (this is top level)
                Connection manager (this is top level)
                .....
                Servlet Engine (this is top level)
  

• In the administrative console, set epm=high as the EPM specification string and restart the WebSphere Application Server. This enables all the EPM counters.

Definition of active sessions and live sessions in WebSphere Application Server Version 3.5.7 (Defect PQ68205)

• Active sessions: A session is active if WebSphere Application Server is currently processing a request that uses that session.
• Live sessions: A live session is one that has been created but not yet invalidated.

Note: A live session might or might not be active, but all active sessions are live.

• Installing the IBM Distributed Debugger with the WebSphere Application Server (Defect 108096)
• Upgrading from Version 9.0 to Version 9.1.5 (Defect 112711)

• No context sensitive help available (Defect 85120.RN)

• Installing the Distributed Debugger manually on HP-UX (Defect 113300)
• Starting the Distributed Debugger when executing tracing and debugging
• Starting the Distributed Debugger when it is enabled for WebSphere Application Server V3.5.7 (Defect 113221.RN)

• Getting information on Object Level Trace (Defect 95844)

• Starting a failed default server when debug is enabled (Defect 112655.RN)
• Installing the IBM Distributed Debugger on the Solaris Operating Environment (Defect 93361.RN)

• No context sensitive help available (Defect 85120.RN)
• Changing the execution mode in the client controller before starting a trace

• No context sensitive help available (Defect 85120.RN)
• Changing the execution mode in the client controller before starting a trace

No context sensitive help available (Defect 85120.RN)

Changing the execution mode in the client controller before starting a trace

Set the execution mode in the client controller to the default settings before you begin tracing. Do not attempt to change the execution mode, after starting the trace.

Starting a failed default server when debugger is enabled (Defect 112655.RN)

If the default server fails to start when debugger is enabled, complete the following steps:

1. Download the IBM_JPDA patch from the URL: http://www.software.ibm.com/vadd

   Use the Quick Access to Downloads to get the debugger.

2. Unzip or extract the files from the IBM_JPDA patch to the opt/<WAS_HOME> directory
3. Update the CLASSPATH and LD_LIBRARY_PATH environment variables in the adminclient.sh and startupServer.sh scripts. Add the following properties:
   Line 70 of the "startupServer.sh" file:
   CLASSPATH=$CLASSPATH:/opt/WebSphere/AppServer/IBM_JPDA/lib/jpda.jar
   Line 68 of the "adminclient.sh" file :
   WAS_CP=$WAS_CP:/opt/WebSphere/AppServer/IBM_JPDA/lib/jpda.jar
   Line 72 of the "adminclient.sh" file:
   LP=$LP:/opt/WebSphere/AppServer/IBM_JPDA/jre/lib/sparc
4. Add the jpda.jar file to the -Xbootclasspath parameter in the administrative GUI of the Command Line Arguments like the following:
   -Xbootclasspath/a:/opt/WebSphere/AppServer/IBM_JPDA/lib/jpda.jar
5. Start the server.

Installing the IBM Distributed Debugger on the Solaris Operating Environment (Defect 93361.RN)

To run the dbgsetup script, issue the chmod 755 dbgsetup command:

Installing the IBM Distributed Debugger with the WebSphere Application Server (Defect 108096)

To install the debugger:

1. Install Version 9.1.x of the debugger on your workstation.
2. Install Version 9.1.x of the debugger on the machine running the WebSphere Application Server, if the application server is not on your workstation.

If you run the application server on the Solaris Operating Environment, do the following:

• Follow the instructions in the IBM Distributed Debugger and Object Level Trace Release Notes, Section 2.5 Installation on Solaris, for installing the JPDA JAR file for debugging your application.
• In the WebSphere Application Server administrative console, add the -Xbootclasspath/a:/lib/jpda.jar parameter to the command line arguments when you want to debug your application server.

Installing the IBM Distributed Debugger manually on HP-UX (Defect 113300)

When you install the WebSphere Application Server driver, you select to install the IBM Distributed Debugger. After setup is finished, however, the IBM Distributed Debugger fails to install.

To install the IBM Distributed Debugger manually, follow the instructions in the IBM Distributed Debugger and Object Level Trace release notes, Section 2.8 Installation on HP-UX.

Getting information on Object Level Trace (Defect 95844)

To fix this problem, add the dertrjrt.jar file to your classpath.

Starting the IBM Distributed Debugger when executing tracing and debugging

To install the distributed debugger and Object Level Trace to work with the WebSphere Application Server:

1. Copy the dertrjrt.jar file from the IBMDebug\lib to the WebSphere\AppServer\lib directory.
2. Open the administrative console.
3. Add the following parameters to the command line arguments, when you want to debug your application server:

           Xdebug
           Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777
           Xnoagent
           Dcom.ibm.debug.jdwpport=7777
           Djava.compiler=NONE
           Xbootclasspath/a:%JAVA_HOME%\lib\tools.jar;
         

Starting the IBM Distributed Debugger enabled for WebSphere Application Server V3.5.7 (Defect 113221.RN)

To start the IBM Distributed Debugger enabled for WebSphere Application Server V3.5.7, update the following files:

1. Add CLASSPATH=$CLASSPATH:$JAVA_HOME/lib/jpda.jar to the startupServer.sh file.
2. Add the WAS_CP=$WAS_CP:$JAVA_HOME/lib/jpda.jar to the adminclient.sh file.
3. Add the following lines to the LD_LIBRARY_PATH directory:

   LP=$LP:$JAVA_HOME/jre/lib/PA_RISC
   LP=$LP:$JAVA_HOME/jre/lib/PA_RISC/native_threads
   LP=$LP:$JAVA_HOME/jre/lib/PA_RISC2.0
   	  

4. Add the following command line parameter in the administrative console:
   
   -Xbootclasspath/a:/opt/WebSphere/AppServer/java/lib/jpda.jar

Upgrading from Object Level Tracing Version 9.0 to Version 9.1.5 (Defects 112711, 113263)

1. Change directories to your download directory from a command prompt.
2. Issue the su command, to go to the root.
3. Uninstall the previous debugger, by issuing the rpm -ev DERJPICL command.
4. Install the new version of the debugger, by issuing one of the following commands:
   
   rpm -ivh DERJPICL-9-1.5.rpm
   or
   rpm -ivh DERJPICL-9.1.5.s390.rpm

• Tracing dynamically from the Java administrative console

Tracing dynamically from the Java administrative console

Edit the adminclient.bat file and make the following modification:

Change javaw to java in the following line:

@start %JAVA_HOME%\bin\javaw -Xminf0.15 -Xmaxf0.25 -classpath %WAS_CP%
%CLIENTSAS% -Dcom.ibm.CORBA.principalName=%COMPUTERNAME%/AdminClient
-Dserver.root=%WAS_HOME% com.ibm.ejs.sm.client.ui.EJSConsole %DEST%
%DESTPORT% %DEBUGOPTS% %QUALIFYNAMES%

• Determining the request and response encoding (Defect PQ67622)

• Linking to Linux platform from non-English platforms (Defects 112260, 112532)

Linking to Linux platform from non-English platforms (Defects 112260, 112532)

To fix this problem:

1. Add an init parameter to the servlet installation of the administrative application in the Default_Server.wacml file, and the WAS_HOME/config directory,.
   
   For example:

   <parameter name="install/install/IBMWebASv3_LINUX_AdminClient.jar" value="adminclient.for.linux"/">

2. Stop the application server and the administrative server.
3. Change the install.initial.config property to true in the admin.config file.
4. Restart the application server and the administrative server.
5. Request the URL http://localhost/admin and click the Administrative Client hyperlink.

Determining the request and response encoding (Defect PQ67622)

The following search order determines the request encoding used by the Web container when handling the request (post or query string) data:

1. If the default.client.encoding property is set, use the client encoding.
2. Use the charset from the Content-type header, if it is present.
3. If the charset information is not present, try to determine the locale from the request using the Accept-Language HTTP header. If the Accept-Language HTTP header does not contain any language information, or if it contains an asterisk (*), or if it is not present, skip to step 5.
4. If the charset information is not present, try to determine the charset from the request using the Accept-Charset HTTP header.
5. If the default.client.encoding property is not present, use ISO-8859-1.

The following search order determines the response encoding used by the Web container when creating a writer for the response data:

1. Use the charset from the response Content-type header, if it is present.
2. If the default.client.encoding property is set, use that encoding.
3. Use the charset from the Content-type header, if it is present.
4. If the charset information is not present, try to determine the locale from the request using the Accept-Language HTTP header. If the Accept-Language HTTP header does not contain any language information, or if it contains an asterisk (*), or if it is not present, skip to step 6.
5. If the charset information is not present, try to determine the charset from the request using the Accept-Charset HTTP header.
6. If the default.client.encoding property is not present, use ISO-8859-1.

Note: If the converter.properties file exists, check if override exists for that character encoding. If override exists, use that value for creating the PrintWriter.

• Accessing Samples supplied with Version 3.5.3 for S/390 and later (Defect PQ47859)
• Getting the WebSphere Application Server Studio to work after overlapping WebSphere Application Server samples with the Studio samples (Defect 90440)
• Running the Samples after applying the FixPak (Defect 93401)
• Getting WebSphere Application Server Sample to work when using the fully qualified hostname
• Configuring Lotus Domino Administrator to use the new /WSsamples files with Domino Web server after upgrading to WebSphere Application Server Version 3.5.7 (Defect 156666.RN)

• Installing DB2 6.1 Samples database (Defect 114175)

• Starting iPlanet (Defect 96578)

• Starting iPlanet (Defect 96578)

• Starting iPlanet (Defect 96578)

Accessing Samples supplied with Version 3.5.3 for S/390 and later (Defect PQ47859)

The following change command corrects the omission of the NOT NULL keyword:

C'ROWID GENERATED''ROWID NOT NULL GENERATED' all

To address the Add INCBEANTBL step, make the following changes to avoid errors when starting the default server:

1. Add the following to the IDCAMS DELETE portion of the documentation:

   DELETE hlq DSNDBC.wasdb.INCBNTS.I0001.A001

2. Add the following to the IDCAMS cluster definitions:

   DEFINE CLUSTER -
   
    (NAME(hlq.DSNDBC.wasdb.INCBNT:I0001.A001)
   
    LINEAR
   
    REUSE
   
    VOLUMES(tgtVolume)
   
    RECORDS(100 50)
   
    SHAREOPTIONS(3 3) )
   
   DATA
   
    (NAME(hlq.DSNDBD.wasdb.INCBNTS.I0001.A001) )

3. Add Description Definition Language (DDL) to create the objects:

   CREATE TABLESPACE INCBNTS IN wasdb
   
   BUFFERPOOL BP0
   
   LOCKSIZE ROW
   
   SEGSIZE 32
   
   USING VCAT hlq
   
   PCTFREE 15;
   
   CREATE TABLE EJB.INCBEANTBL(
   
    PRIMARYKEY             VARCHAR(50) NOT NULL,
   
    THEVALUE               INTEGER WITH  DEFAULT),
   
    PRIMARY KEY (PRIMARYKEY)) in wasdb.INCBNTS

   You can change the BUFFERPOOL value later.

4. Issue a change all command from OEDIT for the following text occurrences with the job control language (JCL):

   tgtvolume

   Target volume for dataset allocation

   hlq

   High level qualifier used for DB2 user datasets

   wasdb

   Name of the DB2 database you want to create for the administrative repository

   DBXX

   Name of the DB2 subsystem

   BP0

   Contact your system administrator for the proper DB2 buffer pool.

5. Add a JOBLIB card, if required for your environment, for the SDSNLOAD library. An example follows:

   //JOBLIB    DD    DSN=DBV.SDSNLOAD,DISP=SHR

6. Add a GRANT statement for the newly created EJB.INCBEANTBL object:

   GRANT DELETE,INSERT,SELECT,UPDATE
     
    ON TABLE EJB.INCBEANTBL
    
     TO PUBLIC AT ALL LOCATIONS;

7. Consider granting access only to the user IDs used by WebSphere Application Server. The included JCL, grants object access to PUBLIC.

Configuring Lotus Domino Administrator to use the new /WSsamples files with Domino Web server after upgrading to WebSphere Application Server Version 3.5.7 (Defect 156666.RN)

When you use a Domino Web server, after upgrading to WebSphere Application Server Version 3.5.7, the new /WSsamples files are copied to the Domino document path. However, after you restart the Domino Web server and access the URL: http://<host name>/WSsamples/index.html, the /WSsamples files are not updated.

You can use the Lotus Domino Administrator to edit the Domino Web server document by performing the following steps:

1. Install the Lotus Domino Administrator from Notes R5 client software. Configure the administrator to connect your Domino Web server.
2. Select Configuration on the Domino Administrator Console.
3. Click Web > Web Server Configuration.
4. Click <your domino web server> and double-click Domino Server.
The Server Document window appears.
5. Select URL Mapping/Redirection from the Create Web (R5) drop-down menu under Basic.
6. Enter the following information from the Mapping/Redirection window:
   a. Select URL > Directory from the drop-down menu under Basic.
   b. Enter host name or IP address of your Web server under Site Information > IP Address.
   c. Under Mapping:
   Incoming URL string: /WSsamples
   Target server directory: <install_root>/WSsamples
   d. Keep the default value for all the other fields.
7. Click Save and Close.
8. Close the Domino Administrator Console.
9. Type the following commands on Domino Web Server start up terminal:
   tell http restart
   or
   tell http exit
   load http

You can now access the new /WSsamples files by accessing the URL: http://<host name>/WSsamples.

Installing DB2 V6.1 Samples database (Defect 114175)

In the Creating and configuring a database for DB2 V6.1 section of the InfoCenter installation instructions, step number seven is incorrect.

Step number seven should say:

Optionally, install the sample database. As the user ID db2instl, set the environment variable DB2INSTANCE to db2instl, then run:

$ db2samp1

Getting the WebSphere Application Server Studio to work after overlapping WebSphere Application Server samples with the Studio samples (Defect 90440)

When you use DB2 and overlap the WebSphere Application Server Samples installation with the installation of WebSphere Studio Samples, the Studio servlet does not work because it tries to use the table name, WSDEMO as the alias WSDEMO.

The WebSphere Studio Samples configuration expects to have a DB2 database called sample created by a user, other than WSDEMO. The Studio version of the CreateDatabase servlet creates and populates the tables that the Studio Samples need, and gives them a WSDEMO alias.

The Application Server Samples can have a DB2, or other relational database designated with any name, for example, Oracle and Sybase. The Application Server Samples version of the CreateDatabase servlet creates tables using the WSDEMO user ID, which becomes part of the table name.

If you install the Application Server Samples first, and create a DB2 database with the name, sample, then the sample configuration instructions use sample as an example database name. The name, sample, is not required, but used often because it is the example.

Because you use data sources in a certain way, it becomes necessary to change the name of the database and the database name to which it points. The Samples code also needs changing because this code uses the names in the .servlet files.

Follow these steps:

1. Name the database something other than sample when creating the DB2 database during DB2 database configuration.
2. Name the data source something other than sample when creating the data source during DB2 database configuration.
3. Edit the Samples .servlet files and change the dataSourceName and database name to the names used during creation. You can find these files in the WebSphere_home/AppServer/hosts/default_host/WSsamples_app/servlets/WebSphereSamples/[Sample] directory.
   
   The lines in the servlet file look like this:
   Database Name: <init-parameter value="jdbc:db2:sample" name="URL"/> > change "sample" to [whatever]
   DataSource Name: <init-parameter value="jdbc/sample" name="dataSourceName"/> > change "sample" to [whatever]

Running the Samples after applying the FixPak (Defect 93401)

Drop the sample database and follow the instructions in the Sample Gallery to recreate the sample database. Users of the Windows NT operating system may need to reboot after installing the FixPak.

Starting iPlanet (Defect 96578)

The iPlanet obj.conf file must have an entry for the Samples to direct the Web server to the WAS_ROOT/samples directory. Make sure the following line appears in the obj.conf file:

Init fn="load-modules"

     funcs="init_exit,service_exit,auth_exit,term_exit"

     shlib="/usr/WebSphere/AppServer/bin/libns40.so"

To configure WebSphere Application Server Samples:

1. Place the following line after <Object name=default> in the obj.conf file:

   NameTrans from="/IBMWebAS/samples" fn="pfx2dir"
   
             dir="WebSphere_installation_directory/samples"

2. Replace the WebSphere_installation_directory variable with the appropriate installation directory, for example, /opt/WebSphere/Appserver. The changes to the obj.conf file noted above, should each appear on one line. The entries display here on multiple lines to make the information ore readable.
3. Restart iPlanet and test the Samples.

Getting WebSphere Application Server Sample to work when using the fully qualified hostname

If WebSphere Application Server Samples fail when using the fully qualified hostname, but run successfully when using the IP address or localhost, add a virtual host alias for the fully qualified domain name (FQDN) of your Web server. The system automatically defines the short name, but some systems do not automatically define the FQDN:

1. Go to the Topology view of the administrative console.
2. Click default_host.
3. Edit the Advanced Properties panel and add a fully qualified virtual host alias, including domain name.
4. Restart the default server application server.

• Adding a new statement about Lightweight Directory Access Protocol server in InfoCenter article 6.6.18.1.4a.4.1 (Defect 120011)
• Disregarding the following information in InfoCenter article 6.6.46.6: (Defect 98692)
• Additional documentation regarding the database access field (Defect 115986)
• The Request Interceptor is not supported by the IBM WebSphere Application Server (Defect 112303)
• Correction to InfoCenter article 6.6.a.1: Running the product servers and consoles as non-root (Defect 118068)
• Correct names of the database conversion assistant files
• Correction to InfoCenter article 5.5.6.2.1: Creating a self-signed test certificate (Defect 110346)

• Change the directories in step 4 of the WebSphere Application Server V3.5 installation procedure (Defect PQ53789)

• Noting availability of the Just In Time compiler

• Change the directories in step 4 of the WebSphere Application Server V3.5 installation procedure (Defect PQ53789)

Correction to InfoCenter article 5.5.6.2.1: Creating a self-signed test certificate (Defect 110346)

In the InfoCenter article 5.5.6.2.1: Creating a self-signed test certificate, you need to perform the following steps:

Create a self-signed certificate, which is a type of personal certificate.

Export the self-signed certificate as an .arm file.

Now import the self-signed certificate (.arm file) into the signer certificate section of the keyfile. Make sure that keyfile is the same keyfile when the self-signed certificate has been create.

Adding a new statement about Lightweight Directory Access Protocol server in InfoCenter article 6.6.18.1.4a.4.1 (Defect 120011)

The following statement is additional documentation regarding the Lightweight Directory Access Protocol server which is documented in InfoCenter article 6.6.18.1.4a.4.1.

WebSphere Application Server only supports the configuration of one LDAP server, and any LDAP server failover merchanism requires implementation outside of WebSphere Application Server and transparency to the WebSphere Application Server.

Noting availability of the Just In Time compiler

The statement referencing the Just in Time compiler in the WebSphere Application Server InfoCenter, under Operating Systems > Linux on S/390 > System-specific limitations, problems, and workarounds, appears incorrectly.

"In addition, please note that the December 2000 release of IBM WebSphere Application Server Version 3.5.x for Linux on S/390 includes the IBM Software Development Kit 1.2.2 for Linux/390 Toolkit, for developing and testing your Java and Linux applications. The release was shipped without a Just In Time (JIT) compiler. As a result, all Java programs will execute under a Java interpreter. Before using the IBM Software Development Kit 1.2.2 for Linux S/390 Toolkit in production, verify that your performance goals are met by this release. Customers with stringent performance requirements may prefer to wait for a WebSphere Application Server product based on IBM Software Development Kit 1.2.2."

The IBM Software Development Kit now provides a JIT compiler.

Disregarding the following information in InfoCenter article 6.6.46.6: Using administrative server agents. (Defect 98692)

Disregard the following information about using administrative server agents in InfoCenter article 6.6.46.6.

Specify the dbUrl, dbUserId, and dbPassword properties:

com.ibm.ejs.sm.adminServer.dbUser=user_name
com.ibm.ejs.sm.adminServer.dbUrl=location
com.ibm.ejs.sm.adminServer.dbPassword=password

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 Application Server 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.

Change the directories in step 4 of the WebSphere Application Server V3.5 installation procedure (Defect PQ53789)

In the Installing WebSphere Application Server V3.5 section of the InfoCenter, change directories before performing step 4.

On the AIX operating system, change to the /cdrom/aix directory, before issuing the /cdrom/aix/install.sh command.

On the Solaris Operating Environment, change to the /cdrom/adv_sun_128/sun directory, before issuing the /cdrom/adv_sun_128/sun/install.sh command.

Additional documentation regarding the database access field (Defect 115986)

The following information is additional documentation regarding the database access field, which is documented in section 6.6.5.0: Enterprise bean properties of the V3.5 WebSphere Application Server InfoCenter.

The database access field specifies whether to share the persistent data of entity beans across containers or keep this data "exclusive" to one container. With shared access, a container loads persistent data for entity beans from the database at the start of each transaction. If you use exclusive access, then the persistent data caches locally for each container and you are not guaranteed the correctness of bean data due to updates made by other processes.

Use exclusive access for entity beans only if you know that the container has exclusive access to the database used by the entity bean (and therefore has the only copy of a bean persistent state), or that the bean data is accessed read-only at all times. Workload Management of entity beans utilizing exclusive access is not supported.

The Request Interceptor is not supported by the IBM WebSphere Application Server (Defect 112303)

Disregard the information about the Request Interceptor interface of the IBM Java ORB.

Correct names of the database conversion assistant files

On UNIX systems, run the file:      DBConfig.sh
On Windows systems, run the file:   dbconfig.bat 

Correction to InfoCenter article 6.6.49: Administering National Language Support (Defect 143968)

In InfoCenter article 6.6.49: Administering National Language Support, the information in the Supported locales is invalid.