IBM looking for Feedback on Installation and Packaging - DB2 andWebsphere

[Paul Vader]

Re: IBM looking for Feedback on Installation and Packaging - DB2 and Websphere

Darin McBride <dmcbride@naboo .to.org.no.spam .for.me> writes:[color=blue]
>You sound like you want DB2 Connect Personal Edition. However, that's
>only available on Windows and Linux, not Solaris.[/color]

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.
[color=blue]
>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.)[/color]

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.
[color=blue]
>
>That's what silent installs are for ;-)[/color]

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.
[color=blue]
>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.[/color]

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.
[color=blue]
>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...[/color]

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.
[color=blue]
>That said, I will continue to raise this point and see if something can
>be done in v9 to address these concerns.[/color]

Thanks.
[color=blue]
>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.[/color]

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.
[color=blue]
>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[/color]

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]

Re: IBM looking for Feedback on Installation and Packaging - DB2 and Websphere

Paul Vader wrote:
[color=blue]
> Darin McBride <dmcbride@naboo .to.org.no.spam .for.me> writes:[color=green]
>>You sound like you want DB2 Connect Personal Edition. However, that's
>>only available on Windows and Linux, not Solaris.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>>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.)[/color]
>
> 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.[/color]

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.
[color=blue]
> Is there any way I can get a CD image from IBM? My employer has a site
> license for DB2/connect EE.[/color]

Probably - you may need to talk to IBM DB2 Service to work this out,
though. I wouldn't know where it was.
[color=blue][color=green]
>>That's what silent installs are for ;-)[/color]
>
> If the install was silent, I would agree with you! I actually have gotten[/color]

It is silent (or at least could be if you redirected stdout/stderr) if
you're on a supported system ;-)
[color=blue]
> 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.[/color]

Ah - but DB2 documents that DB2 only supports RPM systems. If you're
on a non-RPM system, you're basically on your own ;-)
[color=blue]
> I understand why IBM is using RPMs, given their partnership with dead rat,
> but I'm more a debian man myself.[/color]

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 ;->
[color=blue][color=green]
>>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.[/color]
>
> No Java on my 8.2 image. That's the problem. And why do you need a java[/color]

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. ;-)
[color=blue]
> 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.[/color]

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?
[color=blue][color=green]
>>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...[/color]
>
> 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.[/color]

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).
[color=blue][color=green]
>>That said, I will continue to raise this point and see if something can
>>be done in v9 to address these concerns.[/color]
>
> Thanks.
>[color=green]
>>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.[/color]
>
> 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.[/color]

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).
[color=blue][color=green]
>>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[/color]
>
> 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. *[/color]

What is your definition of "just DB2 Connect"?

[Cui Jun Hai]

Re: IBM looking for Feedback on Installation and Packaging - DB2 and Websphere

fprose@hotmail. com (Fred Prose) wrote in message news:<195a4770. 0312160725.4a65 dc11@posting.go ogle.com>...[color=blue]
> 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?[/color]


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]

Re: IBM looking for Feedback on Installation and Packaging - DB2 and Websphere

Darin McBride <dmcbride@naboo .to.org.no.spam .for.me> writes:[color=blue]
>What is your definition of "just DB2 Connect"?[/color]

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]

Re: IBM looking for Feedback on Installation and Packaging - DB2 and Websphere

Paul Vader wrote:
[color=blue]
> Darin McBride <dmcbride@naboo .to.org.no.spam .for.me> writes:[color=green]
>>What is your definition of "just DB2 Connect"?[/color]
>
> 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.[/color]

:-) 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.
[color=blue]
> 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. *[/color]

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.