DB2 Connect® Usage and Editions

The primary use of DB2 Connect is to allow DB2® clients (PC’s, Application Servers, and
DB2/LUW Database Servers) to connect to DB2 on zSeries and iSeries servers. It translates
character data between EBCDIC encoding used on zSeries or iSeries and ASCII encoding
used on Linux, UNIX or Windows. This sounds simple enough, but in reality DB2 Connect
provides your applications, whether written in Java, .NET, ODBC, Ruby, PHP, CLI, etc., to be
tightly integrated with the powerful zSeries and iSeries servers! It can even take advantage
of Workload Manager and Sysplex implementations. In addition, it allows you to place your
data on the platform that makes the most sense to your organization while making the
physical location invisible to your applications. There are various editions of DB2 Connect
that all do the same thing, but the terms of how you are allowed to use them differ. If you
use Type-4 JDBC drivers you can connect to DB2 on zSeries and iSeries servers, but you
still have to license DB2 Connect. I’ll explain the licensing terms (Editions) later in this
document.

The three major parts of this document are:

1. Description of DB2 Connect using Examples

2. DB2 Connect v9.1 Editions
3. Additional Links

Description of DB2 Connect using Examples

First, I’ll define a few abbreviations that I will use throughout this article:

LUW – Linux, UNIX and Windows

DB2/LUW – DB2 on Linux, UNIX and Windows
DB2/z – DB2 on a System Z Server (a.k.a. zSeries)
DB2/i – DB2 on a System I Server (a.k.a. iSeries, a.k.a. AS400)

DB2 Connect is a robust product that can be used in several different ways. I’ll illustrate
those different ways here. I’ll show DB2/z in these examples, but if you are using iSeries,
then it works the same way. These are basic examples that demonstrate how to connect a
DB2 client to a DB2/z or DB2/i database. They do not provide all of the information that
you need to perform a robust configuration of your DB2 Connect system. To learn how to
do that you should consult the DB2 Connect User’s Guide. I have also created another
document called zSeries DB2 Connect Preparation that describes how to gather the catalog
information from your zSeries host for the catalog commands.

Example 1 – Basic DB2 Client

Example 2 – Direct Connect
Example 3 – Connect Gateway
Example 4 – DB2 DB with Connect Gateway
Example 5 – DB2/LUW DB Federated with DB2/z
Example 6 – DB2/LUW DB Server and Gateway server separated
Binding

Example 1 – Basic DB2 Client

I’ll start with an example of a simple DB2/LUW client connecting to a DB2/LUW database
server to illustrate the simplest type of connection in the DB2 distributed world. DB2
Connect is not needed or shown in this example.
In this example the application servers “AppServA” and “AppServB” run applications that
use the DB2 Client to talk to the database on server “dbServ1” that has a database called
“LUWdb1” in instance “db2inst1” that is listening on port 50,000. I have shown the catalog
commands that would be used to create a database alias called “LUWdb1” on the application
servers. The catalog entry “LUWdb1” is then just referenced by the application to connect
to the database rather than having to provide all of the information about where the
database is.
Example 2 – Direct Connect
In example 2 the application servers each have DB2 Connect installed and they each
connect to the DB2 database on zSeries independently:

In this example the application servers “AppServA” and “AppServB” run applications that
use the DB2 Connect to talk to the z/OS database server “dbLPAR1” that has a database
called “Zdb1” that is listening on port 500. It should be noted that the DB2 Client is
installed when DB2 connect is installed, so the same APIs would be used by the application
in Example2 as were used in Example 1. I have shown the catalog commands that would
be used to create a database alias called “Zdb1” on the application servers. Note the
additional “CATALOG DCS” command that must be executed for DB2 Connect connections to
DB2/z. The catalog entry “Zdb1” is then just referenced by the application to connect to the
database rather than having to provide all of the information about where the database is.

Example 3 – Connect Gateway

In example 3 only the gateway server has DB2 Connect installed. The application servers
all use it to connect to DB2/z:
In this example the application servers “AppServA” and “AppServB” run applications that
use the DB2 client to connect to the database on z/OS through DB2 Connect installed on the
gateway server, “gwServ1”. The DB2 Connect instance db2inst1 on “gwServ1” is set up to
connect to the z/OS database server “dbLPAR1” that has a database called “Zdb1” that is
listening on port 500. In this example, the applications servers think that they are just
talking to a DB2/LUW in instance db2inst1 database just as the application servers in
Example 1 do. Using a gateway allows you to manage your connections to DB2/z from a
single location. You can create a cluster of gateway servers for high availability if needed. I
have shown the catalog commands that would be used to create a database alias called
“Zdb1” on the application servers as well as on the gateway server. Note the additional
“CATALOG DCS” command that must be executed for DB2 Connect connections to DB2/z is
only needed on the gateway server. The catalog entry “Zdb1” is then just referenced by the
application to connect to the database rather than having to provide all of the information
about where the database is.
Example 4 – DB2 DB with Connect Gateway

In example 4 the LUW database server has DB2 Connect installed along with the DB2
database software.

In this example the application servers “AppServA” and “AppServB” run applications that
use the DB2 client to connect to both the DB2/LUW database “LUWdb2” as well as the z/OS
database “Zdb1”. In this case both the LUWdb1 database and the Zdb1 catalog entry are in
the same instance, db2inst1, but they could have been created in different instances if that
had been desired. In this diagram, DB2 connect on dbServ1 is used by application servers
to talk to the z/OS database server “dbLPAR1” that has a database called “Zdb1” that is
listening on port 500. Here the application servers think that both of the databases are
actually on dbServ1, when in reality one of them is on z/OS. In this example, dbServ1 is
both a database server and a DB2 Connect gateway server. I have shown the catalog
commands that would be used to create a database alias called “Zdb1” on the application
servers as well as on the gateway server. Note the additional “CATALOG DCS” command
that must be executed for DB2 Connect connections to DB2/z is only needed on the
gateway/database server.

Example 5 – DB2/LUW DB Federated with DB2/z

In example 5 the database server has DB2 Connect installed along with the DB2 database
software. Further the application accesses the DB2/z tables while only connecting to the
DB2/LUW database.

Example 5 is very similar to example 4, except that the application servers do not directly
reference Zdb1. When you purchase DB2 Connect, you get a feature called DB2
Homogenous Replication which means that you can “federate” your DB2 and Informix
databases on all platforms. In this case you would create nicknames in the LUWdb2
database that reference tables in the Zdb1 database. To your application nicknames are
like views in that they are indistinguishable from tables. You use the “CREATE NICKNAME”
command to create nicknames in the LUWdb1 database1 on the Zdb1 tables.

In this example the application servers “AppServA” and “AppServB” run applications that
use the DB2 client to connect to just the DB2/LUW database LUWdb2. After connecting the
application sees a bunch of objects that all look like tables, but some are local tables, some
are local views and some are local nicknames that really point to tables and views on the
DB2/z database called Zdb1. Federation is a very large topic and you can read more about
in Redbook: Data Federation with IBM DB2 Information Integrator V8.1 Please note that
this Redbook was written before the product was renamed WebSphere Federation Server.

Example 6 – DB2/LUW DB Server and Gateway server separated

In example 6 the database server has had only the DB2 database software and the gateway
server has only DB2 connect Installed.
In this example there is one database server and one DB2 Connect gateway server. Both
application servers have only the DB2 client software installed. The application on
AppServA needs to get data from LUWdb2 as well as Zdb1. As in previous examples, the
data in Zdb1 only resides on the z/OS database server. For some reason we only want DB2
Connect installed on gwServ1. To allow AppServA query Zdb1, we catalog the Zdb1
database on AppServA and on gwServ1 to allow the connection to happen through a chain
of servers. Depending on network speeds and server speeds, this may or may not be a
good idea in reality. This can be done through any number of DB2/LUW servers and can
end on a DB2/LUW database rather than a DB2/z database if desired.

AppServB also needs to get data from both LUWdb1 and Zdb1. This illustration shows how
that can be accomplished by chaining database and gateway servers together. It would
probably be a better idea to catalog dbServ1 directly on the application server, but the point
of this example is to show what can be done. This stuff is like tinker toys – the ways that
you can connect the nodes is only limited by your imagination.
Federation was not used in this example, but you could federate the database here if
desired. If that was done, it may eliminate the need to catalog Zdb1 on AppServ1 because
then AppServ1 could just access the Zdb1 tables as nicknames in LUWdb1.

Binding

Each combination of Operating System (OS), DB2 Version and DB2 fix pack on the DB2
client and DB2 Connect server that connect to the zSeries or iSeries server must be bound
to the database. That just means that for each combination you must run the “BIND”
command using certain input files from the client while connected to the database. To
illustrate, assume that you had the 4 types clients in the table below that you wanted to
connect to a database on DB2/z or DB2/i. They would have slightly different contents in the
local bind files and would each have to run the bind commands that I will show later.

Client 1 Client 2 Client 3 Client 4

Windows Linux Linux Linux
DB2 v8.2 DB2 v8.2 DB2 v8.2 DB2 v7.2
Fix pack 12 Fix pack 12 Fix pack 13 Fix pack 13

Even if you have 100 clients, but they all ran on one of the above 4 configurations then you
would only have to run the binds 4 times – once from each software stack. Running the
binds puts objects in the database that allow the clients with various software combinations
to be recognized by that database. If you have multiple databases on your DB2/z system
then you would have to run the 4 binds while connected to each database. This topic is
covered more completely in Chapter 6 in the DB2 Connect User’s Guide, but I will provide a
summary of what needs to be done here because this step is often forgotten and the errors
that you get when this is not done do not really indicate what is actually wrong.

The files that you will bind to the database are found in the “sqllib/bnd” directory under the
client instance home directory. So when you are on your client or DB2 Connect Gateway
Server and are in the “bnd” directory then you will run one of the following sets of
commands depending on which platform you are binding to:

DB2 on z/OS
db2 “BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @ddcsmvs.lst BLOCKING ALL SQLERROR CONTINUE MESSAGES
DDCSMVS.MSG GRANT PUBLIC

DB2 on System I
db2 “BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @ddcs400.lst BLOCKING ALL SQLERROR CONTINUE MESSAGES
DDCSMVS.MSG GRANT PUBLIC

DB2 on VSE
db2 “BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC"
db2 “BIND @ddcsvse.lst BLOCKING ALL SQLERROR CONTINUE MESSAGES
DDCSMVS.MSG GRANT PUBLIC
DB2 Connect v9.1 Editions

As I said in the beginning of this document, all of the editions of DB2 Connect perform the
same function. That function is described in my long diatribe above. The different editions
are just different terms under which you can license the software from IBM. Here I will
attempt to summarize the different license terms that correspond to each edition. Please
keep in mind that this is Dean Compher’s interpretation of these terms and may not
represent the official IBM terms and conditions. They are my best attempt to describe them
in easily understood language, but may not be 100% accurate so don’t yell at your friendly
sales rep if I made any mistakes. You can tell that I’ve been working for large corporations
for way too long because I feel compelled to put disclaimers in everything that I write!
Anyway if you want to see for yourself the exact terms and conditions of each edition please
click this link: DB2 Connect Announcement Letter.

To reduce confusion about how DB2 connect is licensed, you really need to keep in mind
that IBM is attempting to license DB2 connect based on how you will use it and that has
very little to do with where it is installed as you can see by the above examples. If you
keep in mind that we are trying to charge you based on a measurable way to use the
product, then the editions will make more sense. If you don’t keep this in mind then they
are just plain confusing. These definitions are for DB2 Connect v9.1 only. The v8.x editions
used similar names, but in some cases the license terms for the names have changed
significantly. If you purchased and began using DB2 Connect v8.x prior to the data of the
above announcement letter then you may continue to use the license for the original
purpose under the original terms. However, even if you are using DB2 Connect v8.x license
purchased after the announcement letter date then you are bound by the DB2 v9.1 terms.

Some of the editions are based on Processor Value Units or PVUs. This is a way of licensing
software based on the power of the processor running it. In general, single core processors
are worth 100 PVUs, but the power of cores in multi-core processors vary greatly. To see
the full explanation of a PVU please visit the Processor Value Unit page. The v9.1 editions
are:

Unlimited Edition for iSeries or zSeries

Application Server Edition
Enterprise Edition Authorized Users
Enterprise Edition Concurrent Users
Personal Edition

Unlimited Edition for iSeries or zSeries

This edition is licensed based on the processing power of your zSeries or iSeries database
servers. For the zSeries server the price is based on the MSU rating of the physical
machine(s) or LPARS running DB2. On iSeries the price is based on the Processor Value
Unit (number of processor cores) rating of the iSeries Server(s). This edition is a way for
IBM to license the product based on the maximum value that you could possibly get from
the product based on the database server capability. In this case the limit is imposed by
the maximum processing power of the zSeries or iSeries system(s) where DB2 is running,
so when you purchase DB2 Connect Unlimited Edition, you can install DB2 Connect on as
many application servers or workstations as you like. If you contact IBM and request it, you
can also install it on third part servers that connect to your System Z or System I servers.
With this edition you are also licensed for Personal Edition which is described below for no
extra charge.

For zSeries when purchasing this edition you always purchase one Host License if you are
running one server and enough MSU licenses for the server itself or the LPAR where DB2 is
running. If you are running DB2 in a single SYSPLEX environment, then you purchase one
Host License and enough MSU licenses to cover all of the servers or LPARS in the SYSPLEX
running DB2. If you are running multiple independent System Z servers or multiple
independent SYSPLEX environments, then you must purchase one Host License for each
server or SYSPLEX and enough MSU licenses to cover the MSUs available on the
environments where DB2 is actually running.

Application Server Edition

This edition is licensed based on the combined processing power of the LUW APPLICATION
servers that are ACCESSING the DB2 databases on your iSeries or zSeries servers – NOT
the number of processors where DB2 is installed. To illustrate using Example 6 above, you
would determine the total number of processors in AppServ1 and AppServ2 as part of
determining how many licenses of the Application Server Edition that you need to
purchase. “dbServ1” and “gwServ1” do not run applications so they do not count in
determining your processor count. DB2 Connect is a fairly lightweight application and you
can support lots of application server processing through a single small DB2 connect
gateway. To determine the quantity of licenses for this edition you just determine the total
number and type of processors in your LUW application servers accessing the DB2/i or
Db2/z databases and convert them to PVU using the chart on the Processor Value Unit page.

Enterprise Edition Authorized Users

This edition is based on the number of known individuals who use the databases on iSeries
or zSeries either directly or through an application. You must be able to give the names of
the individuals who directly or indirectly access the database through DB2 Connect. No
other users should use the applications that access DB2/i or DB2/z. Because you must be
able to identify the individuals who are using this application, it is generally only applicable
to internally used applications. It does not lend itself to internet applications. You purchase
licenses in increments of 25 known users. For organizations of any size it takes a lot of
work to ensure that you remain in compliance with the terms of the agreement. Anyone
considering purchasing this edition should give this fact serious consideration.

Enterprise Edition Concurrent Users

The terms of this edition only allow it to be used for two-tier applications. Therefore, it
could not be purchased to support any of my above examples because the examples all use
application servers and application servers imply 3-tier or larger-tier applications. However,
Examples 3-6 would be allowed if they were modified such that “AppServ1” was changed to
“EndUserPC1” and “AppServ2” was changed to “EndUserPC2” where “EndUserPCx”
represents a desktop or laptop with an application and DB2 Client installed. This edition
lends itself to having a standard desktop installation that includes the DB2 Client and
catalog entries for connect gateway databases, but where no more than the licensed
number of users will be connecting through DB2 Connect at the same time. You also
purchase this edition in increments of 25 users. For organizations of any size it takes a lot
of work to ensure that you remain in compliance with the terms of the agreement. Anyone
considering purchasing this edition should give this fact serious consideration.

Personal Edition
This edition is for single users to use on their desktop or laptop and does not accept
connections from outside of the machine where it is installed like the other editions do. This
edition is typically used for developers and individuals who do ad-hoc queries against their
zSeries or iSeries databases