PQ54774: WEBSPHERE 3.5 TO 4.0 DATASOURCE NAMESPACE ISSUE

 A fix may be available

Obtain the fix for this APAR



APAR status
Closed as program error.

Error description
In attempting to move servlets and/or EJBs from the WebSphere
3.5 environment to the WAS 4.0 environment, we have the
problem where the code issed a lookup with the following syntax:
   db2ds = (javax.sql.DataSource)ctx.lookup("jdbc/mydb");
These applications, after deployment into the WebSphere 4.0
runtime will fail as there is no DB2DataSource object
bound into the namespace at "jdbc/mydb".  While it is
understood the EJB 1.1 spec states that jdbc resources
should be looked up with ctx.lookup
("java:comp/env/jdbc/mydb"), the tooling which generated
these servlets/beans does not implement the higher spec
levels.  There is resistance to re-open and change the
code to deploy the application and thus have to maintain
platform specific code or multiple versions.

WebSphere needs to provide a mechanism to allow these
programs to continue to run by registering the DB2DataSource
in the namespace.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 V4.0.1 for z/OS and OS/390                   *
****************************************************************
* PROBLEM DESCRIPTION: WebSphere Application Server V3.5 for   *
*                      z/OS and OS/390 supports JNDI lookup    *
*                      of datasource objects via the           *
*                      jdbc/<resource_name> convention.        *
*                      WebSphere Application Server V4.1 for   *
*                      z/OS and OS/390 does not support this   *
*                      format.When applications written for    *
*                      V3.5 that use this convention are       *
*                      deployed on V4.1 systems, datasource    *
*                      lookups will fail and throw a           *
*                      javax.naming.NamingException.           *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In attempting to move servlets and/or EJBs from the WAS 3.5
environment to the WAS 4.1 environment,
the code issues a lookup with the following syntax:
  db2ds = (javax.sql.DataSource)ctx.lookup("jdbc/mydb").
These applications, after deployment into the WebSphere
Application Server V4.1 for z/OS and OS/390 run time, will
fail since there is no DB2DataSource object bound into the
namespace at "jdbc/mydb".  While it is understood that the EJB
1.1 specification states that jdbc resources should be looked
up with ctx.lookup("java:comp/env/jbbc/mydb"), the tooling which
generated these servlets/beans does not implement the higher
specification levels.  There is resistance to re-open and change
the code to deploy the application, since it would mean having
to maintain platform-specific code or multiple versions.

WebSphere Application Server V4.1 for z/OS and OS/390 needs to
provide a mechanism to allow these programs to continue to run
by registering the DB2DataSource in the namespace
jdbc/<resource_name>.
Problem conclusion
During activate processing, WebSphere goes through the J2EE
resources defined on the sysplex and selects those resources
which have a J2EE Resource type of "DB2datasource". WebSphere
then binds each DB2DataSource object in JNDI to the name
jdbc/<resource_name>. If the subcontext jdbc does not exist, it
gets created. If there is already an entry under the same name,
WebSphere unbinds the old entry first. For each resource, this
unbind/bind processing is done only if at least one of the
resource instances has been added, modified, or deleted since
the last conversation activate.

Consequences: If this APAR fix is applied to an existing
WebSphere Application Server V4.1 for z/OS and OS/390
installation, existing datasource resources will not be bound
in JNDI immediately.  To modify an existing DB2DataSource
resource, it is sufficient to use the System Management End User
Interface (Administration and Operations applications), also
known as the SM EUI, to highlight the resource, select 'Modify'
from the context menu, and then press the save button. It is not
necessary to change any parameters of the resource.

You can also make use of this feature by adding a new
DB2DataSource resource and defining one or more resource
instances using the SM EUI.

During a cold start, all DB2DataSources will be bound in JNDI.

Restrictions: Exploitation of the support provided by this APAR
fix is for use within a WebSphere Application Server V4.1 for
z/OS and OS/390 server on managed threads only.

The following publication was revised as a result
of APAR PQ54774:
________________________________________________________________
WebSphere Application Server V4.0.1 for z/OS and OS/390
Messages and Diagnosis
GA22-7837-02
________________________________________________________________
This APAR requires changes to documentation.

NOTE: Periodically, we refresh the documentation on our
Web site, so the changes might have been made before you
read this text. To access the latest on-line
documentation, go to the product library page at:


http://www.ibm.com/software/webservers/appserv/

________________________________________________________________
Chapter 9, pg. 155 (new message)
BBON1154E Failed to bind a datasource object for
location location_name to name name.
Explanation: The Systems Management Server created
a datasource object for the location specified. The
server attempted to bind this datasource object in
the Java Naming and Directory Interface (JNDI) to the
name specified, but failed.
User Response: The cause of the problem can vary.
Check the LDAP error log, the Systems Management Server
job log, and the server console for more details. The
problem may appear in other logs. Especially look for
JNDI or LDAP related exceptions in the Systems Management
Server job log. If the problem persists, contact the IBM
Software Support Center for assistance.
________________________________________________________________
Chapter 9, pg. 155 (new message)
BBON1155E Could not create subcontext subcontext.
Explanation: The Systems Management Server attempted
to create the specified subcontext in the Java Naming
and Directory Interface (JNDI), but failed.
User Response: The cause of the problem can vary.
Check the LDAP error log, the Systems Management Server
job log, and the server console for more details. The
problem may appear in other logs. Especially look for
JNDI or LDAP related exceptions in the Systems Management
Server job log. If the problem persists, contact the IBM
Software Support Center for assistance.
________________________________________________________________
Chapter 9, pg. 156 (new message)
BBON1156E Creation of internal object failed: object.
Explanation: The Systems Management Server failed to
create an object of name object or type object due to
an internal error.
User Response: Contact the IBM Support Center.
________________________________________________________________
Chapter 9, pg. 156 (new message)
BBON1158E Failed to retrieve datasource location: reason.
Explanation: The Systems Management Server failed to
retrieve the datasource location due to an internal error.
User Response: Contact the IBM Support Center.
________________________________________________________________
Chapter 9, pg. 156 (new message)
BBON1159E Creation of a JNDI initial context object failed.
Explanation: The Systems Management Server failed to create
an object of type javax.naming.InitialContext. The
server needs the initial context to access the Java Naming
and Directory Interface (JNDI). The object creation can
fail due to missing or corrupted JNDI security settings.
User Response: Check the java.naming.security.principal
and java.naming.security.credentials environment variables
for correct values. Check the Systems Management Server
job log for additional information. If the problem persists,
contact the IBM Support Center.
________________________________________________________________

APAR PQ54774 is associated with SERVICE LEVEL W401078 of
WebSphere Application Server V4.0.1 for z/OS and OS/390.
Temporary fix Comments
APAR information
APAR number PQ54774
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2001-11-14
Closed date 2002-06-29
Last modified date 2003-03-07

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
UQ67634

Modules/Macros
BBOCOMM BBOIROOT BBOI3PLI BBOJJU BBOMBOOT BBOMDDLI
BBOMDDLO BBOMDDLV BBOMDDLX BBOMDDLZ BBOMIBO BBOMICP
BBOMIDO BBOMRDO BBOMSBO BBOMSBOI BBOMSBO1 BBOMSBO2
BBOMSBO6 BBOMSBO7 BBOMSBO8 BBOMSDO BBOMSMOI BBOMUTIL
BBOOBOAI BBOOBOAT BBOOORB BBOSM BBOSSDMA BBOSSECM
BBOSSESS BBOSSIOR BBOSSKUT BBOSSOUT BBOUBINF BBOZ0769
BBOZ0770 BBOZ0772 BBOZ0773 BBOZ0774 BBOZ0776 BBOZ0778
BBOZ0779 BBOZ0781 BBOZ0812 BBOZ0813 BBOZ0814 BBOZ0977

Fix information
Fixed component name WASKBASE
Fixed component ID 5655A9801

Applicable component levels
R401 PSY UQ67634    UP02/07/09 P F207

  Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ54774
IBM Group: Software Group
Modified date: Mar 7, 2003