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

• After installing the FixPak (Defects PQ48085)
• Avoiding FixPak installation errors
• Changing the CURSORHOLD Option (Defect PQ49737)
• Enabling the DSAPI filter (Defects 71708.RN, 88006)
• Installing the WebSphere Application Server 3.5 GM code without the administrative console (Defect 111830)
• Installing the WebSphere Application Server plug-in for the Apache Server (Defect 85322.rn)
• Migrating and upgrading from Version 3.02 to Version 3.5 (Defect PQ42682.DOC)
• Migrating from Version 3.5.5 to Version 4.01 (Defect PTF)
• Pointing to the new installation directory for DB2 V7.1 (Defect 87213)
• Setting the virtual directory (Defect 95004)
• Uninstalling and reinstalling the FixPak (Defect 92657)
• Using DB2 UDB 6.1 with WebSphere Application Server V3.5 FixPak 5 (Defect 111066)
• Using Java Transaction API-enabled DB2 7.1 and DB2 7.2 with FixPak 2 JDBC drivers (Defects 2921.RN, 99858)

• Cancelling the installation (Defect 95013.relnotes)
• Changing file permissions (Defect 90948)
• Choosing database drivers and prefixes (Defect 90948)
• Installing AIX 4.3.3 ML 8 (Defect 112235)
• Running java applications(Defect 83321.RN)
• Setting up the DB2 environment properly when referring to Oracle, Sybase, or IDB databases as the administrative database (Defect 83770.RN)
• Verifying an application server repository (Defect 101324)
• Uninstalling WebSphere Application Server 3.5 (Defect 112947.RN)

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

• Accessing servlets and JavaServer Pages files
• Changing file permissions (Defect 90948)
• Choosing database drivers and prefixes (Defect 90948)
• Exporting the existing configuration during migration (Defect 97733)
• Importing your original server configuration during migration (Defect 97733)
• Installing the WebSphere 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)
• Verifying an application server repository (Defect 101324)
• Viewing the README file (Defect 83618)
• Visiting the database page in order to configure databases (Defects 96419, 101612)

• Installing the FixPak with only the administrative console and the IBM JDK (Defect 113595, 113450)

• Configuring Sequelink
• Installing the FixPak with only the administrative console and the IBM JDK (Defect 113595, 113450)
• Multiple instances of Internet Information Servers (IIS) (Defects PQ98131.RN)
• Running the WebSphere Application Server V3.5 and V4.0 on the same machine. (Defects 108052.RN)

• Configuring Sequelink
• Installing SQL Server 2000 (Defect 93021.RN)
• Installing the FixPak with only the administrative console and the IBM JDK (Defect 113595, 113450)
• Installing the WebSphere Application Server
• Running the WebSphere Application Server V3.5 and V4.0 on the same machine. (Defects 108052.RN)
• Verifying an application server repository (Defect 101324)
• Visiting the database page in order to configure databases (Defects 96419, 101612)

Accessing servlets and JavaServer Pages files

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.

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.

After installing the FixPak (Defect PQ48085)

After installing the FixPak, the product.xml file and the administrative console show the correct FixPak level, but the operating system shows V3.5.0.

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.

Cancelling the installation (Defect 95013.relnotes)

If you need to cancel the installation, press Ctrl+X.

Changing file permissions (Defect 90948)

Change the startupServer.sh file permissions to enable execution before starting the administrative server.

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>
 

Choosing database drivers and prefixes (Defect 90948)

Choose the right database driver from the pull-down menu and change the database prefix to the appropriate value.

Configuring Sequelink

Follow these steps to configure Sequelink:

The nondefault Microsoft SQL Server name is STLAB20\SQLEJS in this example.

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

Enabling the DSAPI filter (Defects 71708.RN, 88006)

• AIX: libdomino5.a
• HP_UX: libdomino5.sl
• Solaris: libdomino5.so
• Windows: libdomino5.dll

You can locate these files in the WAS_HOME/bin directory.

Use the following steps to enable the new DSAPI filter. These steps assume Solaris as the operating system, but you can use the same steps on other operating systems.

1. Install the WebSphere Application Server, and click Lotus Domino plug-in.
2. Run the Lotus Domino server.
3. Open the server document, either in the Lotus Notes client, or in a browser.
4. Go to the Internet Protocols tab. In the DSAPI filter file names, under DSAPI heading field, add the full path to the DSAPI filter file name. For example, on the Solaris operating system add: /opt/WebSphere/AppServer/bin/libdomino5.so
5. Restart the Lotus Domino server. When the HTTP task starts, the following line displays:

   WebSphere DSAPI filter loaded

   This means the new filter has loaded and the WebSphere Application Server is ready to use the Domino HTTP server.
6. Start the WebSphere Application Server.

Exporting the existing configuration during migration (Defect 97733)

Start the administrative server from the command line.

Importing your original server configuration during migration (Defect 97733)

Start a new administrative server process.

Installing AIX V4.3.3 ML 8 (Defect 112235)

To fix this problem, apply AIX APAR IY19277.

Installing SQL Server 2000 (Defect 93021.RN)

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

Installing the FixPak with only the administrative console and the IBM JDK (Defect 113595, 113450)

When installing FixPak 5, you choose to only install the administrative console and the IBM JDK V1.2.2. After the administrative console updates, the FixPak installation ends and you receive errors. The FixPak installation code fails to update the IBM JDK V1.2.2 installation to the appropriate level.

To fix this problem, follow the steps below, according to your platform.

For the Windows 2000 and Windows NT platforms:

1. Uninstall the FixPak. For the Advanced Edition product, follow the instructions in the was35_adv_ptf_5.readme file. For the Standard Edition product, follow the instructions in the was35_std_ptf_5.readme file. You can find these files in the directory where you extracted the FixPak zip file.
2. In the FixPak install.bat file, search for the word errorlevel. At the first occurrence of this word, replace
   (%errorlevel%) NEQ (0) goto was_ptf_error
   with
   rem (%errorlevel%) NEQ (0) goto was_ptf_error
3. Run the installation again.
   During the installation, if the machine prompts you to upgrade to a different version of the IBM HTTP Server, or the WebSphere Application Server Samples, reply No.

For UNIX platforms (AIX, Solaris, HP-UX):

1. Uninstall the FixPak. For the Advanced Edition product, follow the instructions in the was35_adv_ptf_5.readme file. For the Standard Edition product, follow the instructions in the was35_std_ptf_5.readme file. You can find these files in the directory where you extracted the FixPak zip file.
2. In the FixPak install.sh script, search for the words Installing the WAS PTF.
3. Comment out the six lines which make up the if block which follows the line starting with java-jar. Insert a # at the beginning of each line. For example,
   

   #Installing the WAS PTF
   echo "Installing the WebSphere Application Server 3.5 PTF 5"
   
   java -jar $DELTA_JAR-TargetDir $WAS_DIR-backupJar $WAS_DIR/$BACKUP_JAR-log
   $WAS_DIR/logs/$LOG_FILE
   #if [[$? -ne 0]]; then
   #  echo "Either the user has chosen to exit, or there was an error"
   #  echo "during the WebSphere PTF upgrade."
   #  echo "In case of error, run uninstall_ptf_#.sh to back out the changes."
   #  exit
   #  fi
   		

4. Run the installation again.
   During the installation, if the machine prompts you to upgrade to a different version of the IBM HTTP Server or the WebSphere Application Server Samples, reply No.

On all platforms, when you update the administrative console during the WebSphere Application Server PTF installation, ignore the following errors:

Error 45 -- Unable to open source file: c:\websphere\appserv
er\/bin/admin.config : c:\websphere\appserver\/bin/admin.config 
(The system cannot find the file specified)

Error 76 -- Failed to fill backup entry: /bin/admin.config

Error 45 -- Unable to open source file: c:\websphere\appserv
er\/properties/sas.server.props : c:\websphere\appserver\/properties/sas.server.props 
(The system cannot find the file specified)

Error 76 -- Failed to fill backup entry: /properties/sas.ser
ver.props

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/databeans.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/deployTool.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/ibmjndi.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/ivjejb35.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/jetace.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/ns.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/servlet.jar

Error 20 -- Jar file does not exist: c:\websphere\appserver\
/lib/was20cm.jar

Error 99 -- Error in Helper1.class :  file2Vector: FileNotFo
undException for (c:\websphere\appserver\bin\admin.config); c:\websphere\appserv
er\bin\admin.config (The system cannot find the file specified)

Error 89 --  writing c:\websphere\appserver/bin/admin.config

Error 105 -- Error in Helper1.class :  file2Vector: FileNotF
oundException for (c:\websphere\appserver\bin\admin.config); c:\websphere\appser
ver\bin\admin.config (The system cannot find the file specified)

Error 105 -- Error in Helper1.class :  vector2File: Vector2F
ile -- input Vector is null.

Error 94 -- Unable to write to c:\websphere\appserver/proper
ties/sas.server.props
17 errors were noted, functionality may be compromised.

Installing the WebSphere Application Server

Before installing WebSphere with IHS, 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.

Installing the WebSphere Application Server V3.5 GM code without the administrative console (Defect 111830)

When installing the WebSphere Application Server V3.5 GM code without the administrative console, installation of FixPak 5 is unsuccessful.

To fix this problem:

1. After installing GM, create empty ejscp.ajr and servletconsole.jar files in the WebSphere Application Server ../lib directory.
2. Install FixPak 5.

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

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

Migrate all application files first before migrating from Version 3.02 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.

Migrating from Version 3.5.5 to Version 4.01 (Defect PTF)

When installing Version 4.01, 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.
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 file

   c:\backup_directory\websphere_3x_backup.xml

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

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

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

If you migrate from WebSphere Release 3.02.x on Solaris, turn global security off before attempting to migrate to Release 4.0. An error may 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.

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 is pointing 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 Java applications (Defect 83321.RN)

Reduce the LIBPATH length to less than 1548 characters.

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

If you are running the WebSphere Application Server V3.5 and V4.0 on the same machine, perform the following before installing FixPak 5:

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 sub-directory 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. Enter the values for LD_LIBRARY_PATH= on one line; these values display on two lines to improve readability.

Uninstalling and reinstalling the FixPak (Defect 92657)

To fix this problem:
After uninstalling the FixPak, delete the backup JAR files and the uninstaller of the FixPak.

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

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

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 the WebSphere V3.5, 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

Using DB2 UDB 6.1 with WebSphere Application Server V3.5 FixPak 5 (Defect 111066)

When you code the application with the DB2 default 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

For background information, see the technical note.

Using Java Transaction API-enabled DB2 7.1 and DB2 7.2 with FixPak 2 JDBC drivers (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, you should 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.

Using the custom options of the WebSphere 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 V3.5 administrative server process.

Viewing the README file (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:

Domino

HTTP_HOME/domino/html

iPlanet 4.x

HTTP_HOME/docs

Microsoft IIS

HTTP_HOME/wwwroot

Netscape Enterprise Server

HTTP_HOME/docs

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

• Availability of the Web-based browser administrative console (Defect 78303.RN)
• Downloading the administrative console from the Internet
• Handling security configurations with the XML import feature (Defect 82455.RN)
• Installing the default configurations (Defect sa62023)
• Managing the administrative domain (Defect 94936)
• Resizing the left panel of the Java administrative console (Defect 70298)
• Starting the administrative console (Defect 85101.RN)
• Starting the application server with different installation directories (Defect 94908)
• 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 the administrative console with the Sawfish window manager (Defect 113277)

• Displaying the WebSphere Application Server help (Defect 98429)

• Displaying the Java administrative console correctly (Defect 83810)
• Proper screen repainting and resizing (Defect 80592.RN)
• Stopping the administrative server (Defect PQ44787)

• Displaying the Java administrative console correctly (Defect 83810)
• Proper screen repainting and resizing (Defect 80592.RN)
• Stopping the administrative server (Defect PQ44787)
• The Web application property sheet on the Netscape browser

Availability of the Web-based browser administrative console (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.

Displaying the WebSphere Application Server help (Defect 98429)

Ensure the Web browser runs before trying to access the product online help.

Downloading the administrative console from the Internet

A Java Development Kit (JDK) must reside on the machine. To fix this problem, use the remote console, set the JAVA_HOME value, or put the JDK location in the PATH.

Handling security configurations with the XML import feature (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, LTPA, LDAP, 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. You must 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.

Installing the default configurations (Defect sa62023)

Add a virtual host alias for the fully qualified domain name (FQDN) of the machine running the 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. Select default_host.
3. Edit the Advanced Properties panel and add a fully qualified virtual host alias, including the domain name.
4. Restart the default server application server.

Managing the administrative domain (Defect 94936)

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

Proper screen repainting and resizing (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 Windows NT.
• 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 a patch to upgrade 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 the View button 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.

Starting the administrative console (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 open_cursors=200 to open_cursors=220.
2. Stop and restart Oracle.
3. Restart the administrative console.

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

Stopping the administrative server (Defect PQ44787)

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

The Web application property sheet on the Netscape browser

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 has completed successfully.

Using the administrative console with the Sawfish window manager (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.

• DB2/390 Samples support (Defect PQ47938)
• Deploying enterprise beans to the WebSphere Application Server (Defect 111660)
• 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)
• Using the results of an enumerated finder outside a transaction (Defect 85287.RN)
• Viewing a distributed transaction (Defect 84714, 84525)

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

• Configuring resource security to an existing enterprise application (Defect 92771.RN)
• Using DB2 with Container Managed Persistence

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

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

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

DB2/390 Samples support (Defect PQ47938)

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

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

This defect applies to enterprise beans that were 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.

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.

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

Using DB2 with Container Managed Persistence

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.

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.

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.

• Creating clones on the same node (Defect 93693)
• Creating clones with a Web application that contains multiple servlets (Defect 111818, PQ51576)
• Serving all servlet requests with a single servlet engine
• Terminating a request (Defect 94670.RN)
• Using the InvokerServlet with WebSphere Application Server FixPak (Defect 92747.RN)

• Adding a servlet from the Wizard tab (Defect 85389.RN)

• Setting Max Connections greater than 25 for the servlet engine (Defect 98019)

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

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

Adding a servlet from the Wizard tab (Defect 85389.RN)

RepositoryOpException:

 Unexpected naming exception and other exceptions.

Ignore the error. The servlets are created.

Case sensitivity and the File Serving Enabler Servlet (Defect 98847)

Set case sensitivity for JSP, 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 nonsecured URIs.

To stop receiving 404 errors, change your application.

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.

Creating clones with a Web application that contains multiple servlets (Defect 111818, PQ51576)

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

1. In the <WAS_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.

Serving all servlet requests with a single servlet engine

Load balancing in the plug-in uses a scheme where the outstanding units of work determine the bad.

When you execute a single servlet instance, for example, with no client load on the system, the first application server on the list services the request. After the request completes, the application server has no outstanding units of work, placing it as the first available server on the list. A new request finds this first server chosen again, giving the appearance that load-balancing does not work. If multiple requests arrive at once, then the (OSE) plug-in starts dispatching requests, based on the outstanding units of work.

Setting Max Connections greater than 25 for the servlet engine (Defect 98019)

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

Terminating a request (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.

Using the InvokerServlet with WebSphere Application Server FixPak (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 and 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.

• JSP V1.1 availability
• JSPWriter buffer information (Defect 108783)
• Locating JSP files in subdirectories (Defect 92049.RN)
• Sharing target directories (Defect 88763.RN)
• The flastmod NCSA tag (Defect 54574)

JSP V1.1 availability

JSPWriter buffer information (Defect 108783)

getRemaining()
getBufferSize()

#characters= 2 bytes each

Locating Java Server Page 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 nests.
2. Shorten the length of the directory names.
3. Shorten the JSP names.

Sharing target directories (Defect 88763.RN)

To enable this feature, set up the following:

1. Create a file named global.properties in the directory <WAS_INSTALL_ROOT>/properties/
   
   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 JSPs are modified repeatedly in a production environment. This feature causes a recompile to occur for each JSP, times the number of created clones.

The flastmod NCSA tag (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.

• Fast Cache Response Accelerator on AIX 5.1L (Defect 108238.RN)

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

Fast Cache Response Accelerator on AIX 5.1L (Defect 108238.RN)

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

The Linux 2.4 kernel changes the default values of some IPC limits. The default value for the msgmni parameter is 16, which causes difficulties running DB2 with the default 2.4 kernel IPC parameter. Fortunately, this kernel also enables you to change a number of these parameters through the /proc file system.

Configure the msgmni parameter, by issuing the sysctl command as root:

bash# sysctl -w kernel.msgmni=128

For DB2 6.1 SP9:

If you select Creating DB2 Instance and Administrative Server, when installing DB2 6.1 with the db2setup command, the DB2 Instance and Administrative Server cannot start successfully at the end of installation.

Follow these steps to successfully start up DB2 instance:

1. Install DB2 6.1 with the command ./db2setup
   Do not click Creating DB2 Instance and Administrative Server.
2. Install DB2 FixPak 9.
3. Create db2instance with the command ./db2setup
   Click Creating DB2 Instance and Administrative Server.

• Accessing an HTTP session (Defect PQ47998.RN)
• Turning off the authorization id association with an HTTP session (Defect 94809.DOC)
• Using a connection from a JTA-enabled data source (Defect 83300.RN)
• Using JTA for persisting sessions (Defect PQ49889)

Accessing an HTTP session (Defect PQ47998.RN)

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

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

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

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

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

• syncOnHttpSession - Indicates whether or not to turn on the locking behavior. Set this option to any non-null value to turn on this behavior.
• syncOnHttpSessionTO - Indicates the amount of time a servlet request waits on an HTTP session before continuing execution. This parameter is optional and expressed in milliseconds. The default is 120000, or 2 minutes. Under normal conditions, a servlet request waiting for access to an HTTP session gets notified by the request that currently owns the given HTTP session when the request finishes.
• syncOnHttpSessionFailOnTO - Determines if the request executes the servlet, or aborts servlet execution in the event of a timeout, creating error logs. This parameter is optional and expressed as the boolean true or false. If the value is false, multiple servlet requests that have timed out concurrently, execute concurrently. The default value is true, servlet execution aborts.

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, select Default Server, and specify the system property,
-DHttpSessionSecurity=false, in the command line arguments.


2. Start the Server instance.

Using a connection from a Java Transaction API-enabled data source (Defect 83300.RN)

Sybase V12.0 does not support local transaction modes with a Java Transaction API (JTA)-enabled data source.

To use a connection from a JTA-enabled data source in a local transaction, install Sybase patch EBF9422.

Using Java Transaction API for persisting sessions (Defect PQ49889)

No additional advantages exist for using JTA for persisting sessions.

• Java Transaction API support with the Sybase JDBC driver (Defect 83300.RN)

• Running connections with 512 MB systems

• Running connections with 512 MB systems

Java Transaction API support 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 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.

• Administrative server failover
• 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)

• Installing the Remote Invocation Method compiler

• Choosing the JDK version with the WLMJAR program

• Choosing the JDK version with the WLMJAR program

Administrative server failover

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 JDK version with the WLMJAR program

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

Installing the Remote Invocation Method compiler

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 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 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 WebSphere_root/temp 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 Plugin 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 subdirectory, the WebSphere_root/temp/http directory.
4. Copy the bootstrap.properties file in WebSphere_root/properties. 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 subdirectory, WebSphere_root/properties/http.

5. Modify the plug-in entry for the bootstrap.properties file in the IHS 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 IIS 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.

• Applying a security configuration to each clone (Defect 85032.RN)
• Configuring steps to protect the Java Server Pages Web paths or URIs
• Enabling security (Defect 81042.RN)
• Enabling security and the affect on the object request broker (ORB) (Defect PQ35461.RN)
• Improving Microsoft Active Directory performance (Defect PQ48364.RN)
• Running IKEYMAN (Defect 85084.RN)
• TBSCertificate extensions for client authentication and authorization (Defect 84263)
• Using the WebSphere Application Server with Domino V5.02, V5.02B, and V5.03 (Defect 84858.RN)

• Enabling shadow passwords (Defect 102779)

• Accessing the WebSphere Administrative Server
• Changing the user ID password in the user registry (Defect 74697.RN)

• Accessing the WebSphere Administrative Server
• Changing the user ID password in the user registry (Defect 74697.RN)

Accessing the WebSphere Administrative Server

com.ibm.ejs.security.registry.

   RegistryErrorException:

 Windows NT: Access is denied

The user ID for starting the WebSphere 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 (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.

Changing the user ID password in the user registry (Defect 74697.RN)

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

1. Start the WebSphere Administrative Server and the WebSphere 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 LDAP 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.

Configuring steps to protect the Java Server Pages Web paths or URIs

When you configure steps to protect the Java Server 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. Select 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 should contain 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.

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.

Enabling security and the affect 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 (Defect 102779)

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

TBSCertificate extensions for client authentication and authorization (Defect 84263)

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

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 keyring management tool:
  cd <WebSphere_installation_directory>\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 systems enter the following commands to run the IKEYMAN keyring management tool:
  cd <WebSphere_installation_directory>/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 keyring management tool:
  
  cd <WebSphere_installation_directory>\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 systems, enter the following commands to run the IKEYMAN keyring management tool:
  
  cd <WebSphere_installation_directory>/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.

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.

• Using By Reference semantics (Defect 93415)

• Establishing multiple connections

• Establishing multiple connections

Establishing multiple connections

Catalog the DB2 databases using a TCP/IP loopback.
To implement a TCP/IP loopback, without changing the application, to 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 nodename 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 nodename
   • Restart DB2 to refresh the directory cache.

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

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.

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

• Availability of context sensitive help (Defect 85120.RN)

• Installing the Distributed Debugger 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.5 (Defect 113221.RN)

• Installing the Distributed Debugger (Defect 93361.RN)

• Availability of context sensitive help (Defect 85120.RN)
• Changing the execution mode in the client controller

• Availability of context sensitive help (Defect 85120.RN)
• Changing the execution mode in the client controller

Availability of context sensitive help (Defect 85120.RN)

Changing the execution mode in the client controller

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.

Installing the Distributed Debugger (Defect 93361.RN)

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

Installing the 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 are running the application server on the Solaris operating system, 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 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 Distributed Debugger on HP-UX (Defect 113300)

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

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

Object Level Trace documentation (Defect 95844)

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

Starting the 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 Distributed Debugger enabled for WebSphere Application Server V3.5.5 (Defect 113221.RN)

To start a Distributed Debugger enabled for WebSphere Application Server V3.5.5, 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. In the administrative console, add the following command line parameter:
   
   -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%

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

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

After starting the default server, accessing the http://localhost/admin directory, and clicking the Administrative Client hyperlink, the Linux platform is not available on the screen.

To fix this problem:

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

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

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

• Accessing Samples (Defect PQ47859)
• Installing the WebSphere Application Server Samples and the WebSphere Studio Samples (Defect 90440)
• Running the Samples after applying the FixPak (Defect 93401)
• Using the fully qualified hostname

• Installing DB2 6.1 Samples database (Defect 114175)

• Starting iPlanet (Defect 96578)

• Starting iPlanet (Defect 96578)

• Starting iPlanet (Defect 96578)

Accessing Samples (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 DDL to create the objects:

   CREATE TAVLESPACE 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 BUFFERPOOL later.

4. Issue a change all command from OEDIT for the following text occurrences with the 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 userids used by WebSphere. The included JCL, grants object access to PUBLIC.

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 root, set the environment variable DB2INSTANCE to db2instl, then run:

# /opt/IBMdb2/V6.1/bin

Installing the WebSphere Application Server Samples and the WebSphere 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 userid, 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: --> change "sample" to [whatever]
   DataSource Name: --> 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 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.

Using the fully qualified hostname

If WebSphere 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.

• The Request Interceptor interface of the IBM Java object request broker (Defect 112303)

• Installing the WebSphere Application Server 3.5 (Defect PQ53789)

• Availability of the Just In Time compiler

• Installing the WebSphere Application Server 3.5 (Defect PQ53789)

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 JDK 1.2.2 for Linux/390 Toolkit, for developing and testing your Java/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 JDK 1.2.2 for Linux S/390 Toolkit in production, verify that your performance goals are being met by this release. Customers with stringent performance requirements may prefer to wait for a WebSphere Application Server product based on JDK 1.2.2."

The JDK now provides a JIT compiler.

Installing the WebSphere Application Server 3.5 (Defect PQ53789)

In the Installing WebSphere application server 3.5 section of the InfoCenter, change directories before performing step 4.

For AIX, change the directory to /cdrom/aix, before issuing the /cdrom/aix/install.sh command.

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

The Request Interceptor interface of the IBM Java object request broker (Defect 112303)

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