V9 runtime client setup problems

[Scav]

Helpful folks,

We recently upgraded DB2 V7 to V8 on Windows 2003 Enterprise Edition.
The plan is to migrate to V9 as soon as possible. In anticipation of
that migration, IT management has decided that all our user desktop
workstations (a few hundred) should be upgraded to the V9 runtime
client before we migrate the server to V9. This upgrade process will
be automated using a response file.

Our authentication model is set to CLIENT at the server, such that
authentication takes place on each user desktop when they login. (I
know this is badness, but we can't change it yet.) The DB2 Security
Service, which runs on each workstation provides this functionality.
The V9 client install process does not support installing over a V7
client, so I must uninstall the V7 client, then install the V9 client.

However, when I attempt to install the V9 runtime client on a "clean"
box, nothing I try will install the DB2 Security Service. I've tried
toggling just about every parameter in the response file, but to no
avail. A DB2 Management Service appears, but not the security service.
Does anyone know how to get the V9 runtime client setup program to
install the security service? And why in the world does the setup
program for a runtime client install an instance of DB2 on a client
machine???

Any help or suggestions would be greatly appreciated.

Sean

[Darin McBride]

Re: V9 runtime client setup problems

Scav wrote:

And why in the world does the setup
program for a runtime client install an instance of DB2 on a client
machine???

Common misconception. An instance is *NOT* a server. It is an
*environment*. It is an environment under which applications may run DB2
applications. It just so happens that one of the biggest and most
pervasive DB2 applications might just be the DB2 server itself.

This environment tells applications where to load DB2 libraries (DLLs on
Windows), and tells DB2 where to find its own configuration, both for
reading and for updating. This configuration includes local databases for
the server, and remote nodes and databases for client applications. This
allows applications to simply connect to "mydb" and not care whether the
database named "mydb" is local or remote, or even if it's on a mainframe,
or if it's anything else supported by the DB2 Client (I think it includes
Informix and maybe even Cloudscape, but can't recall offhand for sure).
The client configuration, which exists even in the servers, will handle
that abstraction.

So why are there instances? To be able to have multiple such configurations
on a single machine. Not quite so useful on single-user machines, but
still can be useful when you want to better isolate two apps such that they
don't accidentally connect to the wrong database by having more than one
database cataloged. Or if you're just testing your app - you can have your
production configuration in one instance, and a test configuration in
another, both with the same database name cataloged, but connecting to
different databases at the other end (either different nodes, or different
real database names, or both) - you just have to switch between instances
when you go to test, and back when you need to work with the production
database.

Not everyone needs them, but those who do can find it invaluable.

[binchen6596@gmail.com]

Re: V9 runtime client setup problems

Hello, Sean:

Did some v91 RTCL install testing myself. Both "DB2 Management
Service (copyName)" and "DB2 Security Server (copyName)" services were
created after the DB2 Runtime Client was installed, even in a Compact
install where only the core component was installed.
Thus, please try the v91 runtime Client install on a clean machine
again.

By the way, also checked the V9.5 DB2 products. The "DB2 Security
Server" service is no longer available in v95, even in the server
products (eg. ESE). Thus, it will not be created by the db2 install,
ESE or RTCL. This would be a design decision in v95. Which version
DB2 did you test? FYI, DB2 9 means v9.1.

Regarding to the v7 to v9 migration you are going to do, since the
directly migration from v7 to v91 (or v95) is not supported, there are
two options you can choose:
(1). 2 steps migration:
1). Migrate v7 db2 to v8
2). Then, migrate v8 db2 to v91 or v95
The good thing for this option is the v91 db2 will be configured
in the same (or similar) way when the migration install is completed
(2). This is what you said earlier, to uninstall v7 db2, and then
install the new version DB2 (v91 or v95).
You can export/import the configuration, or configure it
manually after the v9 db2 is installed.

Regards.



.. I believe there should be some request to remove it in the v95ga
cycle.