IBM looking for Feedback on Installation and Packaging - DB2 andWebsphere

[Blair Adamache]

IBM is hosting a user focus session to get feedback on a new design
concept for installing software products and maintenance. The
information below gives a brief summary of the information about the
session. If you are interested and feel that you are qualified, please
send an e-mail to Karen Ball at kb***@protocolusa.com. Or you can phone
Sam Sellers or Flo Tassel at 800-615-9287. Protocol is a recruiting
agency that IBM has hired to handle the logistics for this session. You
will need to answer a short questionnaire over the phone about your DB2
and/or WebSphere installation experience. Please read the information
below and if you are interested, please contact Karen as soon as possible.

Session Name: Solution Install User Focus Session

Subject: User Focus Session on a proposed new installation process for
IBM software that is currently in development. Participants will review
and provide feedback on prototype designs and example user scenarios.

Date: Thursday, January 15, 2004, 8 AM to 5 PM

Location: IBM, Research Triangle Park, NC

[Paul Vader]

Blair Adamache <ba*******@2muchspam.yahoo.com> writes:

IBM is hosting a user focus session to get feedback on a new design
concept for installing software products and maintenance. The
information below gives a brief summary of the information about the
session. If you are interested and feel that you are qualified, please

This isn't really something I can take the time to participate in directly,
but here's some suggestions based on my experience installing DB2 on
Solaris and Linux:

- Package DB2/Connect and UDB seperately. It's incredibly annoying to have
to install an entire DBMS when all you want is to set up a connection to
a remote system. A DB2/Connect development client should be very simple
to set up by itself, and I'm sure I'm not using 95% of the binaries on
many of my machines.

- Don't use Java, especially java + added libraries, in an installer, dang
it! Unix Installers should run from the command line, with little or no
assumptions about what software is installed already. GUI installers
are a pain if you're installing over an SSH/telnet session on a machine
hundreds of miles away - VNC only works if you've got a graphical
environment set up, and even then it can be snarky.

I'll marginally accept the curses install of 7.1, but I didn't like it much
either. I've avoided doing the 8.0 install so far because I don't feel like
goofing with classpaths and installing java on machines that don't need it.

- Is it really necessary to parcel out the code into 70-odd rpms? *
--
* PV something like badgers--something like lizards--and something
like corkscrews.

[Darin McBride]

Paul Vader wrote:

Blair Adamache <ba*******@2muchspam.yahoo.com> writes:

IBM is hosting a user focus session to get feedback on a new design
concept for installing software products and maintenance. The
information below gives a brief summary of the information about the
session. If you are interested and feel that you are qualified, please
This isn't really something I can take the time to participate in
directly, but here's some suggestions based on my experience installing
DB2 on Solaris and Linux:

- Package DB2/Connect and UDB seperately. It's incredibly annoying to have
to install an entire DBMS when all you want is to set up a connection to
a remote system. A DB2/Connect development client should be very simple
to set up by itself, and I'm sure I'm not using 95% of the binaries on
many of my machines.

You sound like you want DB2 Connect Personal Edition. However, that's
only available on Windows and Linux, not Solaris.

If I misunderstood, you must mean the way that UDBEE and Connect EE are
both on the same CD. This oversight was repaired in version 8. No two
licensed products exist on the same media. (A licensed product may
coexist with up to two unlicensed products, such as the clients.)
- Don't use Java, especially java + added libraries, in an installer, dang
it! Unix Installers should run from the command line, with little or no
assumptions about what software is installed already. GUI installers
are a pain if you're installing over an SSH/telnet session on a machine
hundreds of miles away - VNC only works if you've got a graphical
environment set up, and even then it can be snarky.
That's what silent installs are for ;-) Note that the DB2 java
installer does not assume much about what software is installed already
since it uses the version of Java found on the CD.

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.
I'll marginally accept the curses install of 7.1, but I didn't like it
much either. I've avoided doing the 8.0 install so far because I don't
feel like goofing with classpaths and installing java on machines that
don't need it.
You don't need to do any of that. As long as your machine *can* run
Java, you can run DB2's installer graphically. If your machine cannot
run Java, then it may not be following all the requirements laid out in
the DB2 Installation & Configuration Supplement or the DB2 Quick
Beginnings Guides. Note that the silent install does not use Java in
any way.
- Is it really necessary to parcel out the code into 70-odd rpms? *

Ah. In reality, there are likely more RPMs than needed. But only by
about 5, if that. This is a trade-off between low numbers of RPMs and
flexibility that you need if you want to remove 95% of the binaries on
your machines. Here you're observing that DB2 is too granular. But to
fulfill your request to separate out binaries you don't need, we need
to be *more* granular, so you can just pick and choose the RPMs that
you need.

Most of the RPMs, however, are to support other languages. In order
that you do not waste space installing languages that you're not
interested in, each one is partitioned out. This actually should save
you space on your hard disk.

Finally, the rest of the RPMs are probably aggravating in that you want
a single RPM that says "Connect EE". The problem is that we want DB2
Connect Personal Edition and DB2 UDB Workgroup Server Edition to
coexist on the same machine. Any common files that they may share must
be in RPMs that they share. This is a requirement from RPM. And even
if it weren't, this also reduces the size of our fixpaks.

[Blair Adamache]

As Darin mentions, you need DB2 Connect Personal Edition. DB2 Connect
Enterprise Edition contains a full DBMS because it uses a DB2 database
internally for two-phase commit (synchpoint manager transactions are
tracked in a DB2 database).

Paul Vader wrote:

Blair Adamache <ba*******@2muchspam.yahoo.com> writes:

IBM is hosting a user focus session to get feedback on a new design
concept for installing software products and maintenance. The
information below gives a brief summary of the information about the
session. If you are interested and feel that you are qualified, please

This isn't really something I can take the time to participate in directly,
but here's some suggestions based on my experience installing DB2 on
Solaris and Linux:

- Package DB2/Connect and UDB seperately. It's incredibly annoying to have
to install an entire DBMS when all you want is to set up a connection to
a remote system. A DB2/Connect development client should be very simple
to set up by itself, and I'm sure I'm not using 95% of the binaries on
many of my machines.

- Don't use Java, especially java + added libraries, in an installer, dang
it! Unix Installers should run from the command line, with little or no
assumptions about what software is installed already. GUI installers
are a pain if you're installing over an SSH/telnet session on a machine
hundreds of miles away - VNC only works if you've got a graphical
environment set up, and even then it can be snarky.

I'll marginally accept the curses install of 7.1, but I didn't like it much
either. I've avoided doing the 8.0 install so far because I don't feel like
goofing with classpaths and installing java on machines that don't need it.

- Is it really necessary to parcel out the code into 70-odd rpms? *

[Ken]

Darin McBride <dm******@naboo.to.org.no.spam.for.me> wrote in message news:<cKsDb.723692$9l5.11586@pd7tw2no>...

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.

That would be great - I've got a variety of servers in multiple data
centers. Some support X11 port forwarding and remote x-windows via
cygwin works fine, in others there are a variet of issues - and I've
had to retreat to Exceed. Once I get it working then I've still got
to deal with bandwidth: although I'm on broadband, I've got to use X
over a VPN.

The net result is that the graphical install easily doubles the total
installation time. And what value does it provide? The db2
installation is fairly straight-forward: far fewer options than
oracle, or installing an os - so no additional windows (for help, etc)
are really necessary anyhow.

So, when is v9 expected?

[Fred Prose]

From an experience standpoint I've installed BD2 UDB on AIX and
Windows platforms. Here's what feedback I can supply:

AIX:

One. Give up on the Java install. Life is too short to put up with
running this installer. Command line is the only way to go. If you
wanted to spend any time, beef up a question and answer session script
for AIX/Unix.

Two. The loading of the software itself from CD or un-tar'ed file
system takes a considerable amount of time – much longer than seems
necessary. I can load Informix in less than half the time.

Three. Give me more choices where DB2 binaries are going to go.
Don't assume every one wants to put DB2 in /usr. It's even rough to
use a symbolic link and point to a different file system since the
installer checks space availability under /usr. Give me a warning,
but don't stop my install!

Windows:

One. Takes WAY TOO LONG to install! You sit around wondering what's
happening – no disk or CD I/O.
Two. Give more flexibility as to what installs. I don't (think I)
need half the stuff that goes on the drive.
Three. Why automatically start all those services?

[Darin McBride]

Ken wrote:

Darin McBride <dm******@naboo.to.org.no.spam.for.me> wrote in message
news:<cKsDb.723692$9l5.11586@pd7tw2no>...

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.
That would be great - I've got a variety of servers in multiple data
centers. Some support X11 port forwarding and remote x-windows via
cygwin works fine, in others there are a variet of issues - and I've
had to retreat to Exceed. Once I get it working then I've still got
to deal with bandwidth: although I'm on broadband, I've got to use X
over a VPN.

In my experience, VNC is significantly better than Exceed for VPN use.
First, it uses less bandwidth. Second, if your connection goes down,
you don't lose any data with VNC (your programs continue running on the
server).

I work from home permanently. When I want to use X at work (3000+km
away), I use VNC. It is definitely not as peppy as being local. But I
really can't complain. I highly recommend it.

Be sure to look for TightVNC - it's faster than normal VNC. I've got
it running both as my server in the lab and as my client here at home.
The net result is that the graphical install easily doubles the total
installation time. And what value does it provide? The db2
installation is fairly straight-forward: far fewer options than
oracle, or installing an os - so no additional windows (for help, etc)
are really necessary anyhow.
Efforts are always underway to simplify the install ;-)
So, when is v9 expected?

Now, you must know better than to expect an answer to that. :-) "Some
time after v8 is released" I suppose is the answer. Then again, v8 is
released, so that's not really saying much. DB2 Stinger is coming up
"real soon now", I think, but I don't think I'm at liberty to say
whether that is a new release of v8, or it's actually v9.

[Darin McBride]

Fred Prose wrote:

From an experience standpoint I've installed BD2 UDB on AIX and
Windows platforms. Here's what feedback I can supply:

AIX:

One. Give up on the Java install. Life is too short to put up with
running this installer. Command line is the only way to go. If you
wanted to spend any time, beef up a question and answer session script
for AIX/Unix.
Fair enough.
Two. The loading of the software itself from CD or un-tar'ed file
system takes a considerable amount of time – much longer than seems
necessary. I can load Informix in less than half the time.
DB2 probably supports more languages, so the tar file is probably
larger. The actual install has large numbers of help files - try
reducing the number of features you select (e.g., Compact install) - it
should be significantly faster.
Three. Give me more choices where DB2 binaries are going to go.
Don't assume every one wants to put DB2 in /usr. It's even rough to
use a symbolic link and point to a different file system since the
installer checks space availability under /usr. Give me a warning,
but don't stop my install!
This is a limitation of using installp. That said, we're looking at
improving the space checks for the next release (DB2 Stinger), and
other improvements (e.g., installing anywhere) beyond that.
Windows:

One. Takes WAY TOO LONG to install! You sit around wondering what's
happening – no disk or CD I/O.
We'll need to look into this - at what point do you see this behaviour?
During the GUI, or during the actual laying down of files? It could
be that it's scanning your system for valid users (which may include a
large domain). I believe that this aspect is being addressed
(somewhat) in Stinger.
Two. Give more flexibility as to what installs. I don't (think I)
need half the stuff that goes on the drive.
Again - what did you select? This is somewhat of a balancing act - we
can give more choices meaning you have 1,000 selectable options, or we
can make the feature selection something manageable, but you end up
with stuff you didn't necessarily realise you selected.
Three. Why automatically start all those services?

The general idea is that if you're installing DB2, you want it to work.
The services are required for DB2 to work, so they're started
automatically.

[Paul Vader]

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

You sound like you want DB2 Connect Personal Edition. However, that's
only available on Windows and Linux, not Solaris.
Actually, no, I want EE, for reasons not worth going into here. What I
don't want is to install UDB in 'trial mode' when I install DB2/connect.
If I misunderstood, you must mean the way that UDBEE and Connect EE are
both on the same CD. This oversight was repaired in version 8. No two
licensed products exist on the same media. (A licensed product may
coexist with up to two unlicensed products, such as the clients.)
My I/T folks distribute the products in a tar and feather file, which is
certainly big enough to be a CD image I suppose, but I've never actually
seen the physical media. The version 8 one that was made available to me
still seems to be UDB and connect in the same download. However, I couldn't
get it to go very far because the installer couldn't find Java. Perhaps
this is my I/T guy's fault for not packaging the thing correctly when they
pulled it off the CD.

Is there any way I can get a CD image from IBM? My employer has a site
license for DB2/connect EE.

That's what silent installs are for ;-)
If the install was silent, I would agree with you! I actually have gotten a
7.2 install totally scripted and in the bag, but I had issues doing the
install on debian, because of having to trick the system into using RPM
instead of apt-get to install the packages. The only way I could complete the
install was to go behind the installer's back and install all the RPM's
manually with --nodeps, then start up db2setup. Otherwise, I ran into
dependency issues with such obscure programs as bin/sh, because the RPM
package database doesn't have anything in it on debian. In fact, to even
get rpm to work, you have to build some directories as well.

I understand why IBM is using RPMs, given their partnership with dead rat,
but I'm more a debian man myself.
Note that the DB2 java
installer does not assume much about what software is installed already
since it uses the version of Java found on the CD.
No Java on my 8.2 image. That's the problem. And why do you need a java
installer anyway? Something more along the lines of autoconf, which normally
does it's thing via shell scripts and make files, would be a lot nicer.
Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...
VNC works fine, but I do run into issues sometimes with very slow or even
lost updates. And it defeats the purpose of what I'm trying to do - set up
a completely automated server config script that installs everything all by
itself.
That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.
Thanks.
You don't need to do any of that. As long as your machine *can* run
Java, you can run DB2's installer graphically. If your machine cannot
run Java, then it may not be following all the requirements laid out in
the DB2 Installation & Configuration Supplement or the DB2 Quick
Beginnings Guides. Note that the silent install does not use Java in
any way.
Perhaps this is because I don't have all the bits, but at least in the 7.2
guide, Java is not mentioned as a requirement. Are you saying I have to
have Java available to use db2/connect EE v8? I know that is definitely not
the case in 7.2.
Ah. In reality, there are likely more RPMs than needed. But only by
about 5, if that. This is a trade-off between low numbers of RPMs and
flexibility that you need if you want to remove 95% of the binaries on
your machines. Here you're observing that DB2 is too granular. But to

I've never been able to get the Solaris or linux versions to install *just*
DB2/connect, regardless of how careful I was in db2setup. Maybe this is
fixed in version 8; I'll have to check it out one of these days. I'm pretty
happy with 7.2 right now, and I shouldn't need to upgrade for a long time. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.

[Darin McBride]

Paul Vader wrote:

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

You sound like you want DB2 Connect Personal Edition. However, that's
only available on Windows and Linux, not Solaris.
Actually, no, I want EE, for reasons not worth going into here. What I
don't want is to install UDB in 'trial mode' when I install DB2/connect.

Then don't install DB2 Connect EE from that image. ;-) If you have a
licensed UDB EE, then you do not need to install Connect EE at all.
All of the Connect functionality is part of UDB EE.

If you have a licensed Connect EE, then you should not install UDB EE
from the same CD unless you want to have a trial version of UDB EE. If
you really want UDB EE but have Connect EE, then you need to work with
your IBM rep to fix that.

If I misunderstood, you must mean the way that UDBEE and Connect EE are
both on the same CD. This oversight was repaired in version 8. No two
licensed products exist on the same media. (A licensed product may
coexist with up to two unlicensed products, such as the clients.)

My I/T folks distribute the products in a tar and feather file, which is
certainly big enough to be a CD image I suppose, but I've never actually
seen the physical media. The version 8 one that was made available to me
still seems to be UDB and connect in the same download. However, I
couldn't get it to go very far because the installer couldn't find Java.
Perhaps this is my I/T guy's fault for not packaging the thing correctly
when they pulled it off the CD.

Java should be located on the version 8 image in db2/<platform>/java.
If it is not there, then someone munged up your image. The only CD
that does not have Java embedded is the HTML Documentation CD.
Is there any way I can get a CD image from IBM? My employer has a site
license for DB2/connect EE.
Probably - you may need to talk to IBM DB2 Service to work this out,
though. I wouldn't know where it was.

That's what silent installs are for ;-)

If the install was silent, I would agree with you! I actually have gotten

It is silent (or at least could be if you redirected stdout/stderr) if
you're on a supported system ;-)
a 7.2 install totally scripted and in the bag, but I had issues doing the
install on debian, because of having to trick the system into using RPM
instead of apt-get to install the packages. The only way I could complete
the install was to go behind the installer's back and install all the
RPM's manually with --nodeps, then start up db2setup. Otherwise, I ran
into dependency issues with such obscure programs as bin/sh, because the
RPM package database doesn't have anything in it on debian. In fact, to
even get rpm to work, you have to build some directories as well.
Ah - but DB2 documents that DB2 only supports RPM systems. If you're
on a non-RPM system, you're basically on your own ;-)
I understand why IBM is using RPMs, given their partnership with dead rat,
but I'm more a debian man myself.
The request, then, is to use something other than RPM - although using
..deb files is not doable for basically the same reason, then. We've
been looking at other formats, but there's just so many gotchas with
dropping RPM support that I really can't promise anything other than
looking. And some of those gotchas are even technical ;->

Note that the DB2 java
installer does not assume much about what software is installed already
since it uses the version of Java found on the CD.

No Java on my 8.2 image. That's the problem. And why do you need a java

I hope you mean "8.1". If you have an 8.2 image, that's the problem.
IBM won't even comment on IF there will be an 8.2. ;-)
installer anyway? Something more along the lines of autoconf, which
normally does it's thing via shell scripts and make files, would be a lot
nicer.

Because DB2 is slightly more complicated than what autoconf handles.
Normally, when you compile/install via autoconf, you get everything.
DB2 has 20+ languages - are you sure you want everything?

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

VNC works fine, but I do run into issues sometimes with very slow or even
lost updates. And it defeats the purpose of what I'm trying to do - set up
a completely automated server config script that installs everything all
by itself.

That's what our response files are designed for. They can create
users, create instances (new in v8 - create multiple instances if you
want with a single response file!), and configure the instances. That
includes both dbm cfg parms and registry variables that you normally
set via db2set. We're still working on allowing remote databases to be
catalogued.

Most of DB2's automated install testing is via response file because,
well, it does everything. It is more flexible than the GUI as well (or
the "TUI" (Text User Interface) in v7).

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.

Thanks.

You don't need to do any of that. As long as your machine *can* run
Java, you can run DB2's installer graphically. If your machine cannot
run Java, then it may not be following all the requirements laid out in
the DB2 Installation & Configuration Supplement or the DB2 Quick
Beginnings Guides. Note that the silent install does not use Java in
any way.

Perhaps this is because I don't have all the bits, but at least in the 7.2
guide, Java is not mentioned as a requirement. Are you saying I have to
have Java available to use db2/connect EE v8? I know that is definitely
not the case in 7.2.

Correct - v7 does not have as much Java dependency as v8. Version 8
uses Java (optionally) in the install, or (required) in the engine.
But also in v8, if you don't have Java, DB2 should install it (the
installable version of Java should be in db2/<platform>/Java-1.3). In
v7, Java was only automatically installed on some platforms (Windows
and AIX, I think).

Ah. In reality, there are likely more RPMs than needed. But only by
about 5, if that. This is a trade-off between low numbers of RPMs and
flexibility that you need if you want to remove 95% of the binaries on
your machines. Here you're observing that DB2 is too granular. But to

I've never been able to get the Solaris or linux versions to install
*just* DB2/connect, regardless of how careful I was in db2setup. Maybe
this is fixed in version 8; I'll have to check it out one of these days.
I'm pretty happy with 7.2 right now, and I shouldn't need to upgrade for a
long time. *

What is your definition of "just DB2 Connect"?

[Blair Adamache]

As Darin mentions, you need DB2 Connect Personal Edition. DB2 Connect
Enterprise Edition contains a full DBMS because it uses a DB2 database
internally for two-phase commit (synchpoint manager transactions are
tracked in a DB2 database).

Paul Vader wrote:

Blair Adamache <ba*******@2muchspam.yahoo.com> writes:

IBM is hosting a user focus session to get feedback on a new design
concept for installing software products and maintenance. The
information below gives a brief summary of the information about the
session. If you are interested and feel that you are qualified, please

This isn't really something I can take the time to participate in directly,
but here's some suggestions based on my experience installing DB2 on
Solaris and Linux:

- Package DB2/Connect and UDB seperately. It's incredibly annoying to have
to install an entire DBMS when all you want is to set up a connection to
a remote system. A DB2/Connect development client should be very simple
to set up by itself, and I'm sure I'm not using 95% of the binaries on
many of my machines.

- Don't use Java, especially java + added libraries, in an installer, dang
it! Unix Installers should run from the command line, with little or no
assumptions about what software is installed already. GUI installers
are a pain if you're installing over an SSH/telnet session on a machine
hundreds of miles away - VNC only works if you've got a graphical
environment set up, and even then it can be snarky.

I'll marginally accept the curses install of 7.1, but I didn't like it much
either. I've avoided doing the 8.0 install so far because I don't feel like
goofing with classpaths and installing java on machines that don't need it.

- Is it really necessary to parcel out the code into 70-odd rpms? *

[Ken]

Darin McBride <dm******@naboo.to.org.no.spam.for.me> wrote in message news:<cKsDb.723692$9l5.11586@pd7tw2no>...

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.

That would be great - I've got a variety of servers in multiple data
centers. Some support X11 port forwarding and remote x-windows via
cygwin works fine, in others there are a variet of issues - and I've
had to retreat to Exceed. Once I get it working then I've still got
to deal with bandwidth: although I'm on broadband, I've got to use X
over a VPN.

The net result is that the graphical install easily doubles the total
installation time. And what value does it provide? The db2
installation is fairly straight-forward: far fewer options than
oracle, or installing an os - so no additional windows (for help, etc)
are really necessary anyhow.

So, when is v9 expected?

[Fred Prose]

From an experience standpoint I've installed BD2 UDB on AIX and
Windows platforms. Here's what feedback I can supply:

AIX:

One. Give up on the Java install. Life is too short to put up with
running this installer. Command line is the only way to go. If you
wanted to spend any time, beef up a question and answer session script
for AIX/Unix.

Two. The loading of the software itself from CD or un-tar'ed file
system takes a considerable amount of time – much longer than seems
necessary. I can load Informix in less than half the time.

Three. Give me more choices where DB2 binaries are going to go.
Don't assume every one wants to put DB2 in /usr. It's even rough to
use a symbolic link and point to a different file system since the
installer checks space availability under /usr. Give me a warning,
but don't stop my install!

Windows:

One. Takes WAY TOO LONG to install! You sit around wondering what's
happening – no disk or CD I/O.
Two. Give more flexibility as to what installs. I don't (think I)
need half the stuff that goes on the drive.
Three. Why automatically start all those services?

[Darin McBride]

Ken wrote:

Darin McBride <dm******@naboo.to.org.no.spam.for.me> wrote in message
news:<cKsDb.723692$9l5.11586@pd7tw2no>...

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.
That would be great - I've got a variety of servers in multiple data
centers. Some support X11 port forwarding and remote x-windows via
cygwin works fine, in others there are a variet of issues - and I've
had to retreat to Exceed. Once I get it working then I've still got
to deal with bandwidth: although I'm on broadband, I've got to use X
over a VPN.

In my experience, VNC is significantly better than Exceed for VPN use.
First, it uses less bandwidth. Second, if your connection goes down,
you don't lose any data with VNC (your programs continue running on the
server).

I work from home permanently. When I want to use X at work (3000+km
away), I use VNC. It is definitely not as peppy as being local. But I
really can't complain. I highly recommend it.

Be sure to look for TightVNC - it's faster than normal VNC. I've got
it running both as my server in the lab and as my client here at home.
The net result is that the graphical install easily doubles the total
installation time. And what value does it provide? The db2
installation is fairly straight-forward: far fewer options than
oracle, or installing an os - so no additional windows (for help, etc)
are really necessary anyhow.
Efforts are always underway to simplify the install ;-)
So, when is v9 expected?

Now, you must know better than to expect an answer to that. :-) "Some
time after v8 is released" I suppose is the answer. Then again, v8 is
released, so that's not really saying much. DB2 Stinger is coming up
"real soon now", I think, but I don't think I'm at liberty to say
whether that is a new release of v8, or it's actually v9.

[Darin McBride]

Fred Prose wrote:

From an experience standpoint I've installed BD2 UDB on AIX and
Windows platforms. Here's what feedback I can supply:

AIX:

One. Give up on the Java install. Life is too short to put up with
running this installer. Command line is the only way to go. If you
wanted to spend any time, beef up a question and answer session script
for AIX/Unix.
Fair enough.
Two. The loading of the software itself from CD or un-tar'ed file
system takes a considerable amount of time – much longer than seems
necessary. I can load Informix in less than half the time.
DB2 probably supports more languages, so the tar file is probably
larger. The actual install has large numbers of help files - try
reducing the number of features you select (e.g., Compact install) - it
should be significantly faster.
Three. Give me more choices where DB2 binaries are going to go.
Don't assume every one wants to put DB2 in /usr. It's even rough to
use a symbolic link and point to a different file system since the
installer checks space availability under /usr. Give me a warning,
but don't stop my install!
This is a limitation of using installp. That said, we're looking at
improving the space checks for the next release (DB2 Stinger), and
other improvements (e.g., installing anywhere) beyond that.
Windows:

One. Takes WAY TOO LONG to install! You sit around wondering what's
happening – no disk or CD I/O.
We'll need to look into this - at what point do you see this behaviour?
During the GUI, or during the actual laying down of files? It could
be that it's scanning your system for valid users (which may include a
large domain). I believe that this aspect is being addressed
(somewhat) in Stinger.
Two. Give more flexibility as to what installs. I don't (think I)
need half the stuff that goes on the drive.
Again - what did you select? This is somewhat of a balancing act - we
can give more choices meaning you have 1,000 selectable options, or we
can make the feature selection something manageable, but you end up
with stuff you didn't necessarily realise you selected.
Three. Why automatically start all those services?

The general idea is that if you're installing DB2, you want it to work.
The services are required for DB2 to work, so they're started
automatically.

[Paul Vader]

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

You sound like you want DB2 Connect Personal Edition. However, that's
only available on Windows and Linux, not Solaris.
Actually, no, I want EE, for reasons not worth going into here. What I
don't want is to install UDB in 'trial mode' when I install DB2/connect.
If I misunderstood, you must mean the way that UDBEE and Connect EE are
both on the same CD. This oversight was repaired in version 8. No two
licensed products exist on the same media. (A licensed product may
coexist with up to two unlicensed products, such as the clients.)
My I/T folks distribute the products in a tar and feather file, which is
certainly big enough to be a CD image I suppose, but I've never actually
seen the physical media. The version 8 one that was made available to me
still seems to be UDB and connect in the same download. However, I couldn't
get it to go very far because the installer couldn't find Java. Perhaps
this is my I/T guy's fault for not packaging the thing correctly when they
pulled it off the CD.

Is there any way I can get a CD image from IBM? My employer has a site
license for DB2/connect EE.

That's what silent installs are for ;-)
If the install was silent, I would agree with you! I actually have gotten a
7.2 install totally scripted and in the bag, but I had issues doing the
install on debian, because of having to trick the system into using RPM
instead of apt-get to install the packages. The only way I could complete the
install was to go behind the installer's back and install all the RPM's
manually with --nodeps, then start up db2setup. Otherwise, I ran into
dependency issues with such obscure programs as bin/sh, because the RPM
package database doesn't have anything in it on debian. In fact, to even
get rpm to work, you have to build some directories as well.

I understand why IBM is using RPMs, given their partnership with dead rat,
but I'm more a debian man myself.
Note that the DB2 java
installer does not assume much about what software is installed already
since it uses the version of Java found on the CD.
No Java on my 8.2 image. That's the problem. And why do you need a java
installer anyway? Something more along the lines of autoconf, which normally
does it's thing via shell scripts and make files, would be a lot nicer.
Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...
VNC works fine, but I do run into issues sometimes with very slow or even
lost updates. And it defeats the purpose of what I'm trying to do - set up
a completely automated server config script that installs everything all by
itself.
That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.
Thanks.
You don't need to do any of that. As long as your machine *can* run
Java, you can run DB2's installer graphically. If your machine cannot
run Java, then it may not be following all the requirements laid out in
the DB2 Installation & Configuration Supplement or the DB2 Quick
Beginnings Guides. Note that the silent install does not use Java in
any way.
Perhaps this is because I don't have all the bits, but at least in the 7.2
guide, Java is not mentioned as a requirement. Are you saying I have to
have Java available to use db2/connect EE v8? I know that is definitely not
the case in 7.2.
Ah. In reality, there are likely more RPMs than needed. But only by
about 5, if that. This is a trade-off between low numbers of RPMs and
flexibility that you need if you want to remove 95% of the binaries on
your machines. Here you're observing that DB2 is too granular. But to

I've never been able to get the Solaris or linux versions to install *just*
DB2/connect, regardless of how careful I was in db2setup. Maybe this is
fixed in version 8; I'll have to check it out one of these days. I'm pretty
happy with 7.2 right now, and I shouldn't need to upgrade for a long time. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.

[Darin McBride]

Paul Vader wrote:

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

You sound like you want DB2 Connect Personal Edition. However, that's
only available on Windows and Linux, not Solaris.
Actually, no, I want EE, for reasons not worth going into here. What I
don't want is to install UDB in 'trial mode' when I install DB2/connect.

Then don't install DB2 Connect EE from that image. ;-) If you have a
licensed UDB EE, then you do not need to install Connect EE at all.
All of the Connect functionality is part of UDB EE.

If you have a licensed Connect EE, then you should not install UDB EE
from the same CD unless you want to have a trial version of UDB EE. If
you really want UDB EE but have Connect EE, then you need to work with
your IBM rep to fix that.

If I misunderstood, you must mean the way that UDBEE and Connect EE are
both on the same CD. This oversight was repaired in version 8. No two
licensed products exist on the same media. (A licensed product may
coexist with up to two unlicensed products, such as the clients.)

My I/T folks distribute the products in a tar and feather file, which is
certainly big enough to be a CD image I suppose, but I've never actually
seen the physical media. The version 8 one that was made available to me
still seems to be UDB and connect in the same download. However, I
couldn't get it to go very far because the installer couldn't find Java.
Perhaps this is my I/T guy's fault for not packaging the thing correctly
when they pulled it off the CD.

Java should be located on the version 8 image in db2/<platform>/java.
If it is not there, then someone munged up your image. The only CD
that does not have Java embedded is the HTML Documentation CD.
Is there any way I can get a CD image from IBM? My employer has a site
license for DB2/connect EE.
Probably - you may need to talk to IBM DB2 Service to work this out,
though. I wouldn't know where it was.

That's what silent installs are for ;-)

If the install was silent, I would agree with you! I actually have gotten

It is silent (or at least could be if you redirected stdout/stderr) if
you're on a supported system ;-)
a 7.2 install totally scripted and in the bag, but I had issues doing the
install on debian, because of having to trick the system into using RPM
instead of apt-get to install the packages. The only way I could complete
the install was to go behind the installer's back and install all the
RPM's manually with --nodeps, then start up db2setup. Otherwise, I ran
into dependency issues with such obscure programs as bin/sh, because the
RPM package database doesn't have anything in it on debian. In fact, to
even get rpm to work, you have to build some directories as well.
Ah - but DB2 documents that DB2 only supports RPM systems. If you're
on a non-RPM system, you're basically on your own ;-)
I understand why IBM is using RPMs, given their partnership with dead rat,
but I'm more a debian man myself.
The request, then, is to use something other than RPM - although using
..deb files is not doable for basically the same reason, then. We've
been looking at other formats, but there's just so many gotchas with
dropping RPM support that I really can't promise anything other than
looking. And some of those gotchas are even technical ;->

Note that the DB2 java
installer does not assume much about what software is installed already
since it uses the version of Java found on the CD.

No Java on my 8.2 image. That's the problem. And why do you need a java

I hope you mean "8.1". If you have an 8.2 image, that's the problem.
IBM won't even comment on IF there will be an 8.2. ;-)
installer anyway? Something more along the lines of autoconf, which
normally does it's thing via shell scripts and make files, would be a lot
nicer.

Because DB2 is slightly more complicated than what autoconf handles.
Normally, when you compile/install via autoconf, you get everything.
DB2 has 20+ languages - are you sure you want everything?

Granted about the GUI via SSH/telnet. That said, I regularly install
DB2 graphically on a machine that's over 3000km away. But I've the
advantage of VNC working...

VNC works fine, but I do run into issues sometimes with very slow or even
lost updates. And it defeats the purpose of what I'm trying to do - set up
a completely automated server config script that installs everything all
by itself.

That's what our response files are designed for. They can create
users, create instances (new in v8 - create multiple instances if you
want with a single response file!), and configure the instances. That
includes both dbm cfg parms and registry variables that you normally
set via db2set. We're still working on allowing remote databases to be
catalogued.

Most of DB2's automated install testing is via response file because,
well, it does everything. It is more flexible than the GUI as well (or
the "TUI" (Text User Interface) in v7).

That said, I will continue to raise this point and see if something can
be done in v9 to address these concerns.

Thanks.

You don't need to do any of that. As long as your machine *can* run
Java, you can run DB2's installer graphically. If your machine cannot
run Java, then it may not be following all the requirements laid out in
the DB2 Installation & Configuration Supplement or the DB2 Quick
Beginnings Guides. Note that the silent install does not use Java in
any way.

Perhaps this is because I don't have all the bits, but at least in the 7.2
guide, Java is not mentioned as a requirement. Are you saying I have to
have Java available to use db2/connect EE v8? I know that is definitely
not the case in 7.2.

Correct - v7 does not have as much Java dependency as v8. Version 8
uses Java (optionally) in the install, or (required) in the engine.
But also in v8, if you don't have Java, DB2 should install it (the
installable version of Java should be in db2/<platform>/Java-1.3). In
v7, Java was only automatically installed on some platforms (Windows
and AIX, I think).

Ah. In reality, there are likely more RPMs than needed. But only by
about 5, if that. This is a trade-off between low numbers of RPMs and
flexibility that you need if you want to remove 95% of the binaries on
your machines. Here you're observing that DB2 is too granular. But to

I've never been able to get the Solaris or linux versions to install
*just* DB2/connect, regardless of how careful I was in db2setup. Maybe
this is fixed in version 8; I'll have to check it out one of these days.
I'm pretty happy with 7.2 right now, and I shouldn't need to upgrade for a
long time. *

What is your definition of "just DB2 Connect"?

[Cui Jun Hai]

fp****@hotmail.com (Fred Prose) wrote in message news:<19**************************@posting.google. com>...

From an experience standpoint I've installed BD2 UDB on AIX and
Windows platforms. Here's what feedback I can supply:

AIX:

One. Give up on the Java install. Life is too short to put up with
running this installer. Command line is the only way to go. If you
wanted to spend any time, beef up a question and answer session script
for AIX/Unix.

Two. The loading of the software itself from CD or un-tar'ed file
system takes a considerable amount of time ? much longer than seems
necessary. I can load Informix in less than half the time.

Three. Give me more choices where DB2 binaries are going to go.
Don't assume every one wants to put DB2 in /usr. It's even rough to
use a symbolic link and point to a different file system since the
installer checks space availability under /usr. Give me a warning,
but don't stop my install!

Windows:

One. Takes WAY TOO LONG to install! You sit around wondering what's
happening ? no disk or CD I/O.
Two. Give more flexibility as to what installs. I don't (think I)
need half the stuff that goes on the drive.
Three. Why automatically start all those services?

Forget about java and GUI install on Unix. It's not necessary. I would
rather spend more time on investigating what's and where being
installed.

[Paul Vader]

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

What is your definition of "just DB2 Connect"?

The parts of the software that allow me to write applications on my unix
servers (I normally use CLI), but access the databases on the mainframe. I
don't use DB2 on the server itself; I put all the data on the big iron
where God intended.

Because of the some Solaris, some Linux server environment, I think I'm
precluded from using PE. But really, all that I'm using is the piece that
talks to the mainframe, and it would be really nice if I could install just
that and the header files and libraries. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.

[Darin McBride]

Paul Vader wrote:

Darin McBride <dm******@naboo.to.org.no.spam.for.me> writes:

What is your definition of "just DB2 Connect"?
The parts of the software that allow me to write applications on my unix
servers (I normally use CLI), but access the databases on the mainframe. I
don't use DB2 on the server itself; I put all the data on the big iron
where God intended.

:-) You might be somewhat surprised with the amount of code that is
actually involved in this. To be honest, you're looking for one of two
possible scenarios (at least for this portion of it):

Scenario 1: One-tier

Here you would, ideally, have Connect Personal Edition on your clients.
If you install CPE using the "Compact" option, you'll get as small of
a client as DB2 supports on Unix. Granted, this is still a bit larger
than is really needed (working towards fixing that in v9), but it's as
close as you get.

Unfortunately, the problem is that CPE is not available on Solaris.
Only Linux and Windows. However, you can still use CPE on your Linux
boxes while using ConnectEE on your Solaris boxes.

Scenario 2: Two-tier

Set up a single box (or two or three) with Connect EE. Probably
Solaris boxes, I would suppose, but in reality, it doesn't matter from
a DB2 perspective. (Solaris probably has better reliability than Intel
boxes.)

On the rest of the machines, install compact Runtime Clients. Catalog
your B.I. machine(s) through the Connect EE gateway(s).

Note that you can still use your CEE gateway(s) as clients at the same
time, so you'll really still be using the same number of machines with
this scenario.
Because of the some Solaris, some Linux server environment, I think I'm
precluded from using PE. But really, all that I'm using is the piece that
talks to the mainframe, and it would be really nice if I could install
just that and the header files and libraries. *

From this perspective, you're looking for Connect Personal Edition for
Solaris. And a slimmer CPE. While I can't talk about CPE being
available for Solaris, I can assure you that we're looking at how to
slim down CPE on Unix.

That said, it may still end up being larger than you had hoped if only
because DB2 does a lot of stuff on clients, including language support,
codepage conversion, etc.