Please bear with me, as I am a newbie in the world of databases and DB2.
We are trying to migrate an application that binds to a DB2 database
(Workgroup Edition, V6.1) from a server running Windows NT 4.0, to a new
server running Windows 2000. Since DB2 V6.1 is no longer supported by IBM, I
cannot even find anything to tell me if V6.1 is compatible with Windows
2000. Also, the new server will be running two hyperthreading processors vs,
the current server running one processor. Can V6.1 handle it?
Thanks in advance for any help!
Mark

In article <saadnUE6WJFRnDjenZ2dnUVZ_v-dnZ2d@adelphia.com>, rowlama1
@adelphia.net says...
> Please bear with me, as I am a newbie in the world of databases and DB2.
> We are trying to migrate an application that binds to a DB2 database
> (Workgroup Edition, V6.1) from a server running Windows NT 4.0, to a new
> server running Windows 2000. Since DB2 V6.1 is no longer supported by IBM, I
> cannot even find anything to tell me if V6.1 is compatible with Windows
> 2000. Also, the new server will be running two hyperthreading processors vs,
> the current server running one processor. Can V6.1 handle it?
> Thanks in advance for any help!
> Mark
>

DB2 V6 was officially supported on Windows 2000. To be sure it works you
might need to download the latest fixpack from
ftp://ftp.software.ibm.com/ps/produc...sh-us/db2ntv61

The differences in hardware should not be a technical problem. Maybe a
license issue arises when running on multiple processors?

Thanks for your reply. The DB2 software was installed onto the new server by
someone else, so I don't know if there was any licensing issues at
installation. Since the software installed I will ASSUME that licensing is
not an issue. Since my last post, we migrated the application to the new
server, which is running Windows 2000 Server. When we attempted to bind the
database to the application, the application abruptly ended with no error
message. Thinking that maybe the DB2 needed updating, we found and installed
fixpack 11 (from the same ftp address you supplied). This made no
difference, the application bombs during binding. I am wondering if the
installation of service packs for Windows has had some impact on the
behavior of DB2. The new server is running Windows 2000, service pack 4.
Please let me know if any ideas come to mind. Thanks again in advance for
any and all help!
Mark


"Gert van der Kooij" <nomail@nl.invalid> wrote in message
news:MPG.1e0f45cfb2b45b8d9896b0@news.xs4all.nl...
> In article <saadnUE6WJFRnDjenZ2dnUVZ_v-dnZ2d@adelphia.com>, rowlama1
> @adelphia.net says...
>> Please bear with me, as I am a newbie in the world of databases and DB2.
>> We are trying to migrate an application that binds to a DB2 database
>> (Workgroup Edition, V6.1) from a server running Windows NT 4.0, to a new
>> server running Windows 2000. Since DB2 V6.1 is no longer supported by
>> IBM, I
>> cannot even find anything to tell me if V6.1 is compatible with Windows
>> 2000. Also, the new server will be running two hyperthreading processors
>> vs,
>> the current server running one processor. Can V6.1 handle it?
>> Thanks in advance for any help!
>> Mark
>>
>
> DB2 V6 was officially supported on Windows 2000. To be sure it works you
> might need to download the latest fixpack from
> ftp://ftp.software.ibm.com/ps/produc...sh-us/db2ntv61
>
> The differences in hardware should not be a technical problem. Maybe a
> license issue arises when running on multiple processors?

In article <VLqdnQXlnesiEzjeRVn-jg@adelphia.com>, Mark Rowland
(rowlama1@adelphia.net) says...
> Thanks for your reply. The DB2 software was installed onto the new server by
> someone else, so I don't know if there was any licensing issues at
> installation. Since the software installed I will ASSUME that licensing is
> not an issue. Since my last post, we migrated the application to the new
> server, which is running Windows 2000 Server. When we attempted to bind the
> database to the application, the application abruptly ended with no error
> message.

After installing FP11, did you follow the instructions in the readme
regarding binding the utilities etc. against your database?

Thanks again for your reply. Yes, we did bind the utilities after the
installation of the fixpack and before the attempted application binding. I
can connect to the database using the command window utility, and I can also
"see" the database structure using the control center utility. I am
beginning to wonder if the addition of windows 2000 service packs has
anything to do with our problem. The question is: How can I tell, other than
checking the event viewer?

Thanks again for any and all help!
Mark

"Gert van der Kooij" <gert@invalid.nl> wrote in message
news:MPG.1e0fb015ac9675229898c8@news.xs4all.nl...
> In article <VLqdnQXlnesiEzjeRVn-jg@adelphia.com>, Mark Rowland
> (rowlama1@adelphia.net) says...
>> Thanks for your reply. The DB2 software was installed onto the new server
>> by
>> someone else, so I don't know if there was any licensing issues at
>> installation. Since the software installed I will ASSUME that licensing
>> is
>> not an issue. Since my last post, we migrated the application to the new
>> server, which is running Windows 2000 Server. When we attempted to bind
>> the
>> database to the application, the application abruptly ended with no error
>> message.
>
> After installing FP11, did you follow the instructions in the readme
> regarding binding the utilities etc. against your database?

Mark Rowland wrote:
> Thanks again for your reply. Yes, we did bind the utilities after the
> installation of the fixpack and before the attempted application binding. I
> can connect to the database using the command window utility, and I can also
> "see" the database structure using the control center utility. I am
> beginning to wonder if the addition of windows 2000 service packs has
> anything to do with our problem. The question is: How can I tell, other than
> checking the event viewer?

Is there any reason why you prefer to stay on unsupported version? V6 is long
time out of service; V7 is also out of service. Current version is V8.2 with V9
just around the corner.

Are you telling that when you bind application bind file, bind process ends with
no message?

What version is the bind file; what version/level is DB2 client you are binding
from; what version/level is DB2 server you are binding to?

Did you try to bind on DB2 server itself?

DB2 client windows event log does not show anything? DB2 server event log? Check
both system and application event logs in both cases.

Last resort is to take trace and convince anybody here capable of readinhg this
trace why you have to stay on V6 ...

Jan M. Nelken

Thanks for your reply. The reason we prefer to stay on DB2 version 6.1 is
that this database is only used by one and only one application, which is
used to run an automated piece of equipment. There isn't any reason that we
couldn't go to version 8.2 -- my concern is that upgrading to version 8.2
will not fix this particular problem, and it will just be money wasted.
The application uses several proprietary bind files that set up packages
within the database when the application binds itself to the database. The
application, the database and the entire DB2 software all reside on the same
server (Windows 200 server, sp4). When I start the binding process from the
application, the application connects to the database (unseen to the user)
using a login with no password, then attempts to bind with the database. The
application dies with no warning, which indirectly kills the binding
process.
I must be suffering from a caffeine deficiency, because I did not think to
check the application's log. If the error was not handled, then the
application log probably won't contain any useful information, but I will
definitely look at it. Thanks for bringing that up.
How do you run a trace? Can you do that via the command window?
Thanks again for any and all help!
Mark Rowland

"Jan M. Nelken" <Unknown.User@Invalid.Domain> wrote in message
news:3v6dnawsTd4pMDjenZ2dnUVZ_t6dnZ2d@rogers.com.. .
> Mark Rowland wrote:
>> Thanks again for your reply. Yes, we did bind the utilities after the
>> installation of the fixpack and before the attempted application binding.
>> I can connect to the database using the command window utility, and I can
>> also "see" the database structure using the control center utility. I am
>> beginning to wonder if the addition of windows 2000 service packs has
>> anything to do with our problem. The question is: How can I tell, other
>> than checking the event viewer?
>
> Is there any reason why you prefer to stay on unsupported version? V6 is
> long time out of service; V7 is also out of service. Current version is
> V8.2 with V9 just around the corner.
>
> Are you telling that when you bind application bind file, bind process
> ends with no message?
>
> What version is the bind file; what version/level is DB2 client you are
> binding from; what version/level is DB2 server you are binding to?
>
> Did you try to bind on DB2 server itself?
>
> DB2 client windows event log does not show anything? DB2 server event log?
> Check both system and application event logs in both cases.
>
> Last resort is to take trace and convince anybody here capable of readinhg
> this trace why you have to stay on V6 ...
>
> Jan M. Nelken
>
>

Mark Rowland wrote:
> Thanks for your reply. The reason we prefer to stay on DB2 version 6.1 is
> that this database is only used by one and only one application, which is
> used to run an automated piece of equipment. There isn't any reason that we
> couldn't go to version 8.2 -- my concern is that upgrading to version 8.2
> will not fix this particular problem, and it will just be money wasted.
> The application uses several proprietary bind files that set up packages
> within the database when the application binds itself to the database. The
> application, the database and the entire DB2 software all reside on the same
> server (Windows 200 server, sp4). When I start the binding process from the
> application, the application connects to the database (unseen to the user)
> using a login with no password, then attempts to bind with the database. The
> application dies with no warning, which indirectly kills the binding
> process.
> I must be suffering from a caffeine deficiency, because I did not think to
> check the application's log. If the error was not handled, then the
> application log probably won't contain any useful information, but I will
> definitely look at it. Thanks for bringing that up.
> How do you run a trace? Can you do that via the command window?
> Thanks again for any and all help!
> Mark Rowland

I would locate all the bind files application is tryimg to bind and locate the
failing one - by binding it manually from command line:

db2 connect to <alias>
db2 bind <bindfile> blocking all grant public

I would also check db2diag.log - after raising diaglevel to 4 and restarting
instance.

After locating the failing bind file you can trace the bind command with:


db2 connect to <alias>
db2trc on -l 16000000
db2 bind <badbindfile> blocking all grant public
db2trc dmp badbind.trc
db2trc off
db2trc flw badbind.trc badbind.flw
db2trc fmt badbind.trc badbind.fmt

Now it's the tricky part:

archive into one zip file the failing bind file, db2trc.flw, db2trc.fmt and be
ready to send to me. When it is ready post here and I will e-mail you with my
e-mail address.

I personally don't believe it's Windows 2000 issue - but who knows.
When this application was written - in what language and against whicl level of DB2?

You still owe us an answer about Db2 level - try db2level command from command
window and paste here the ouput.

Jan M. Nelken

Thanks again for your reply. After a good bit more research into this
problem, I determined a few things:
(1) In April of this year, our application worked (bound to the database,
etc.) OK. At the time, Windows 2000 server, service pack 4 had been
installed, with no other patches installed.
(2) Between April and December, numerous Windows "Hotfixes" had been
installed. In December, the application could no longer bind to the
database, even after installing fixpack 11 for DB2 version 6.1.
(3) After some discussion between the technical support of the company that
developed the application, it was decided that we should install DB2
Personal Edition version 8.2.3. This was available as a 90-day trial
version.
(4) Uninstalled DB2 Workgroup version 6.1 and installed DB2 Personal Edition
8.2.3, recreated the database, and bound the application to the database.
Everything works well.
Lesson Learned: DB2 Workgroup version 6.1 is not compatible with Windows
2000 server WITH hotfixes applied.

Mark Rowland


"Jan M. Nelken" <Unknown.User@Invalid.Domain> wrote in message
news:xOWdnWfjSKAnUjjenZ2dnUVZ_tGdnZ2d@rogers.com.. .
> Mark Rowland wrote:
>> Thanks for your reply. The reason we prefer to stay on DB2 version 6.1 is
>> that this database is only used by one and only one application, which is
>> used to run an automated piece of equipment. There isn't any reason that
>> we couldn't go to version 8.2 -- my concern is that upgrading to version
>> 8.2 will not fix this particular problem, and it will just be money
>> wasted.
>> The application uses several proprietary bind files that set up packages
>> within the database when the application binds itself to the database.
>> The application, the database and the entire DB2 software all reside on
>> the same server (Windows 200 server, sp4). When I start the binding
>> process from the application, the application connects to the database
>> (unseen to the user) using a login with no password, then attempts to
>> bind with the database. The application dies with no warning, which
>> indirectly kills the binding process.
>> I must be suffering from a caffeine deficiency, because I did not think
>> to check the application's log. If the error was not handled, then the
>> application log probably won't contain any useful information, but I will
>> definitely look at it. Thanks for bringing that up.
>> How do you run a trace? Can you do that via the command window?
>> Thanks again for any and all help!
>> Mark Rowland
>
> I would locate all the bind files application is tryimg to bind and locate
> the failing one - by binding it manually from command line:
>
> db2 connect to <alias>
> db2 bind <bindfile> blocking all grant public
>
> I would also check db2diag.log - after raising diaglevel to 4 and
> restarting instance.
>
> After locating the failing bind file you can trace the bind command with:
>
>
> db2 connect to <alias>
> db2trc on -l 16000000
> db2 bind <badbindfile> blocking all grant public
> db2trc dmp badbind.trc
> db2trc off
> db2trc flw badbind.trc badbind.flw
> db2trc fmt badbind.trc badbind.fmt
>
> Now it's the tricky part:
>
> archive into one zip file the failing bind file, db2trc.flw, db2trc.fmt
> and be ready to send to me. When it is ready post here and I will e-mail
> you with my e-mail address.
>
> I personally don't believe it's Windows 2000 issue - but who knows.
> When this application was written - in what language and against whicl
> level of DB2?
>
> You still owe us an answer about Db2 level - try db2level command from
> command window and paste here the ouput.
>
> Jan M. Nelken
>
>
>
>
>