|
Problem |
You use two different datasources, using
two different DB2® subsystems, with a single J2EE server instance . One of
these datasources (session clustering) points to the same DB2 subsystem in
which WebSphere® Application Server was installed. The second datasource
(application data) points to a second DB2 location that is not the DB2 in
which WebSphere Application Server was installed. |
|
|
|
Solution |
When you setup a WebSphere Application Server for z/OS
system, you specify the following values in the current.env file (through
environment variables at the sysplex level or a lower level):
- SYS_DB2_SUB_SYSTEM_NAME=DB2_subsystem_name_in_which_
WAS_systems_management_tables_reside
-
DB2SQLJPROPERTIES=location_of_the_db2sqljjdbc.properties_file
The first specification indicates the DB2 subsystem that the WebSphere
Application Server uses to retrieve runtime configuration information. All
of these accesses are done using static SQL that is baked into the C code
that is responsible for getting the server up and running.
In a WebSphere Application Server configuration, you can define one or
more DB2 Datasources as J2EE resources that can have different location
names in them. For example, you can have a datasource for the location
names WASDS1 and WASDS2. These are actually two different DB2 datasharing
groups on the same PLEX, which have members on one or more machines. In
this case, there is an instance of WASDS1 active on the system where the
WebSphere Application Server is running and there might or might not be an
active instance of WASDS2 on this system. However, WASDS1 is the DB2
subsystem with which the JDBC driver communicates.
How does the JDBC® driver find the DB2 subsystem it must use?
The DB2 V7 JDBC driver is a type 2 driver, there is native code that
interacts with DB2, like calling DB2 from a batch job, CICS or IMS. This
DB2 driver is going to communicate with a DB2 subsystem that is on this
z/OS image.
If there are two DB2 subystems active on the MVS image which one does the
JDBC Driver use?
Normally, the name of the DB2 subsystem is determined by the contents of
the db2sqljjdbc.properties file in the second specification. This file
contains the following variable:
DB2SQLJSSID=name_of_the_DB2_subsystem_to_be
used_by_the_JDBC_driver
If DB2SQLJSSID is not specified in this file, the JDBC driver uses
the DB2 subsystem name specified in the DSNHDECP module in the
DSN710.SDSNEXIT PDS to find the correct DB2 subsystem. The DB2 subsystem
specified in the properties file or the DSNHDEP module must either:
- Be the location name specified in the datasource definition that you
specified in the WAS configuration
or
- There must be definition for the location name in the
SYSIBM.SYSLOCATIONS (and some other miscellaneous definitions)
You can have any application reference table in either DB2 data sharing
environment by using the correct data source. However, the JDBC driver
talks to only one DB2 subsystem. If the location name is associated
with another DB2 subsystem (or data sharing group) and is known to the DB2
subsystem to which the JDBC driver uses, you must flow a request through
the DB2 subsystem that the JDBC driver uses to get to the destination
subsystem through DDF. This is true if the subsystem is on the same z/OS
image or on a different z/OS image.
It is not possible to have the WebSphere Application Server running on a
z/OS image with two DB2 subsystems and get a direct connection to each of
the DB2 subsytems so that the JDBC driver talks to the appropriate DB2
subystem. Even if you define two DB2 datasources, this is not possible.
There is only one db2sqjljdbc.properties file and one DSNHDECP module
available in the address space.
WebSphere Application Server for z/OS V4 has the WebSphere Application
Server configuration data in one DB2 subystem; all the JDBC accesses from
the runtime use a different DB2 subsystem. That is what the two
specifications at the top of this technote allow you to define.
If you want to place HTTP session data in the DB2 subsystem in which the
WebSphere Application Server tables live, you must set this up as a DDF
flow from the DB2 subsystem that the JDBC communicates with, to the DB2
subsystem that is connected to your WebSphere Application Server for z/OS
system. |
|
|
|
|
|
|
|