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

• After installing the FixPak (Defects PQ48085)
• Avoiding FixPak installation errors
• Changing the CURSORHOLD Option (Defect PQ49737)
• Enhancement to plug-in for OSE remote configuration (Defect PQ50243.RN)
• 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.6 to Version 4.01 (Defect PTF)
• Pointing to the new installation directory for DB2 V7.1 (Defect 87213)
• Setting the virtual directory (Defect 95004)
• Use -ignore option to install FixPak when machine only has component installed (Defect PQ55146.RN)
• Using DB2 UDB V6.1 with WebSphere Application Server V3.5 FixPak 5 (Defect 111066)
• Using Java Transaction API-enabled DB2 V7.1 and DB2 V7.2 with FixPak 2 JDBC drivers (Defects 2921.RN, 99858)

• Installing AIX V4.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 V3.5 (Defect 112947.RN)

• Installing and uninstalling FixPak 6 on an HP machine (Defect 118250.RN)
• Downloading the HP client through a Web client (Defect 119460.RN)

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

• Accessing servlets and Java Server Pages files
• 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 to configure databases (Defects 96419, 101612)

• Using the administrative agent multi-node configuration (Defect 119463.RN)

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

• Configuring a SequeLink server
• Installing SQL Server 2000 (Defect 93021.RN)
• 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 to configure databases (Defects 96419, 101612)

Accessing servlets and Java Server 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)

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.

An enhancement has been made to the plug-in for OSE remote configurations in WebSphere Application Server Version 3.5.6. In earlier releases (V3.5.5 and below) 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.

Use -ignore option to install FixPak when machine only has component installed (Defect PQ55146.RN)

If you are installing FixPak 5 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, you can 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. 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 admin.config:
   • 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>
   • Remvoe 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

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>
 

Configuring a SequeLink server

Follow these steps to configure a SequeLink server:

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.

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 and uninstalling FixPak 6 on an HP machine (Defect 118250.RN)

If you install and uninstall FixPak 6 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.

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.6. After installing FixPak 6, 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.

Installing AIX V4.3.3 ML 8 (Defect 112235)

To fix this problem, apply AIX APAR IY19277.

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

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

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

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.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.6 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 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 directory:

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

4. Shut down the WebSphere V3.x.x Administrative Server after the preceding step completes .
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 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 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 run the WebSphere Application Server V3.5 and V4.0 on the same machine, perform the following before installing FixPak 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. Enter the values for LD_LIBRARY_PATH= on one line; these values display on two lines to improve readability.

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 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, 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 6 (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 Java Transaction API-enabled DB2 V7.1 and DB2 V7.1 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, 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 Internet Information Server

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.

• Making the Web-based browser administrative console available (Defect 78303.RN)
• Downloading the administrative console from the Internet
• Handling security configurations with the XML import feature (Defect 82455.RN)
• Resizing the left panel of the Java administrative console (Defect 70298)
• Managing the administrative domain (Defect 94936)
• 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)

• Starting the administrative console (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)
• Stopping the administrative server (Defect PQ44787)
• Missing the Web application property sheet on the Netscape browser

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

Downloading the administrative console from the Internet

An IBM Software Development Kit must reside on the machine. To fix this problem, use the remote console, set the JAVA_HOME value, or put the IBM Software Development Kit 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, 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.

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.

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.

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

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 initializes or starts application servers. End any running java.exe processes using the Task Manager.

Missing 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 completes 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.

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

• Starting the administrative server on a Solaris platform (Defect 112431.RN)
• 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 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 platform (Defect 112431.RN)

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

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

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

This defect 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.

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 a thin servlet redirector with security enabled (Defect 90327)
• Creating clones on the same node (Defect 93693)
• Creating clones with a Web application that contains multiple servlets (Defect 111818, PQ51576)
• Generating or regenerating the plug-in information fails with a ClassCastException (Defect 122590)
• Standalone Java clients must handle their own reauthentication of expired credentials (Defect PQ48143)
• Serving all servlet requests with a single servlet engine (Defect 123051)
• 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)

• Serving all servlet requests with a single servlet engine (Defect 123051)

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

• Understanding 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.

Understanding case sensitivity and 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 nonsecured URIs.

To stop receiving 404 errors, change your application.

Creating a thin servlet redirector with security enabled (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 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 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 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 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.
   

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.

Generating or regenerating the plug-in information fails with a ClassCastException (Defect 122590)

If you are upgrading from WebSphere Application Server Version 3.5.3 to 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.

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

Serving all servlet requests with a single servlet engine (Defect 123051)

The plug-in distributes request in round-robin fashion unless session affinity is enabled. The first clone is randomly chosen; subsequent clones are selected in numerical order (2, 3, 4, 1). On UNIX platforms, multi-process Web servers (such as IBM HTTP Server and Apache) may choose a different starting clone, giving the appearance that round-robin algorithm is not functioning correctly. However, a closer look shows that for each individual process, the round-robin algorithm is indeed working correctly. Request will be routed to each clone in round-robin fashion as long as a connection can be established between the plug-in (OSE) and the servlet engine clone.

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

Set the 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, 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.

• Identifying Java Server Page V1.1 availability limitations for Java Server Page files
• Reporting JSPWriter buffer information (Defect 108783)
• Locating JSP files in subdirectories (Defect 92049.RN)
• Sharing target directories (Defect 88763.RN)
• Targeting the flastmod NCSA tag (Defect 54574)

Identifying Java Server Page V1.1 availability limitations for Java Server Page files

Reporting 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 files nest.
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 <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.

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

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

• Lacking support of Fast Cache Response Accelerator on AIX V5.1 (Defect 108238.RN)

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

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 CommandLine arguments of an application server.
2. Set the system property SessionConfigInit to a value, for example, -DSessionConfigInit=100
3. Restart the application server.

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 session affinity for the session manager to behave correctly in a clustered environment. (Defect PQ55573)

In a clustered environment, if session affinity is absent, requests go to multiple application servers. This situation leads to problems such as concurrent access of the session object found in multiple application servers and the session object not being current in the Java virtual machine (JVM) code.

Session affinity is a prerequisite for the session manager to behave correctly in a clustered environment.

Lacking support of Fast Cache Response Accelerator support on AIX V5.1 (Defect 108238.RN)

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

The Linux 2.4 kernel changes the default values of some interprocess communication (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 FixPak 9:

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 the DB2 instance:

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

• Accessing an HTTP session (Defect PQ47998.RN)
• Adding system property to ensure session object is latest (Defect PQ50400.DOC)
• 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 Java Transaction API 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. This approach also had stability issues, for example, any servlet hangs would lock up individual sessions, or the entire database. This implementation proved unusable with the introduction of the servlet 2.2 API and concurrent access requirements for an 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 can route to a particular Java virtual machine (JVM) you can utilize, standard Java locking mechanisms, within a single JVM. 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, and servlet execution aborts.

Adding a system property to ensure 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.

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.

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

• Running connections with 512 MB systems

• Running connections with 512 MB systems

Identifying problems with Java Transaction API support and 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.

• Adding a new Java Naming and Directory Interface property to allow a choice between resolution of the Java Naming and Directory Interface AdminServer 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 failover
• Enabling workload management of requests from one WebSphere 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)

• Installing the Remote Invocation Method compiler

• 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 AdminServer 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 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 WebSphere Application Server Version V3.5 cannot be resolved, 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 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 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 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 administrative domain to another (Defect 118925.RN)

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

Please be aware of the following restrictions:

1. Each server group name must be unique across all WebSphere 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.
2. 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.
3. 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.

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

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

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

• 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 realizing the effect on the object request broker (ORB) (Defect PQ35461.RN)
• Improving Microsoft Active Directory performance (Defect PQ48364.RN)
• Running IKEYMAN (Defect 85084.RN)
• Identifying TBSCertificate extensions for client authentication and authorization support(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 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.

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

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

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

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 systems 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 systems, 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.

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

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

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

• Identifying lack of context sensitive help availability(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.6 (Defect 113221.RN)

• Missing Object Level Trace documentation (Defect 95844)

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

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

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

Identifying lack of context sensitive help availability(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.

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 (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 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 IBM Distributed Debugger 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.

Missing Object Level Trace documentation (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.6 (Defect 113221.RN)

To start the IBM Distributed Debugger enabled for WebSphere Application Server V3.5.6, 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%

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

• 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 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. 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 the user ID db2instl, set the environment variable DB2INSTANCE to db2instl, then run:

$ db2samp1

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

• 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)
• Requiring more information about database access (Defect 115986)
• Disregarding the Request Interceptor interface information about the IBM Java object request broker (Defect 112303)
• Correction to InfoCenter article 6.6.a.1: Running the product servers and consoles as non-root (Defect 118068)

• Installing the WebSphere Application Server 3.5 (Defect PQ53789)

• Noting availability of the Just In Time compiler

• Installing the WebSphere Application Server 3.5 (Defect PQ53789)

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.
6. Start the WebSphere Administrative console under the root ID.
7. In the Java administrative console tree view, locate and click the application server to display its properties.
8. In the Advanced properties, modify the User ID and Group ID to be the user and group for the application server to "run as."
9. In the General properties, modify the standard output and standard error log paths to refer to directories to which the "run as" identity has access.
10. Start the application server, using the new ID.

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

Installing the WebSphere Application Server V3.5 (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 system, change to the /cdrom/adv_sun_128/sun directory, before issuing the /cdrom/adv_sun_128/sun/install.sh command.

Requiring more information needed about database access (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.

Disregarding the Request Interceptor interface information about the IBM Java object request broker (Defect 112303)

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