Just to help somebody else if they are looking, we wasted 2 hours last
night trying to figure out the problem. (With a manager over our shoulder)
We upgraded our 8.1 FP11 instance to FP13. Instructions first say that
there are no instruction changes from FP11 to FP13. Great, so we install
FP13, run all the binds on the server like it says, same ones we did
when we went to FP11, and we can command line connect, but our
applicatoin cannot connect. We thought we had an applicaiton problem, so
we spend time trying to figure out what, rebuild our connection modules,
express schema...few other things...no love...

We ended up having to run db2schema.bnd from a client (from one of each
OS type). Instructions specifcally say:

""""
Bind db2schema.bnd to existing databases

After installation on the server, an additional bind file needs to be
bound to existing databases. This requirement does not apply to clients.
""""
http://download.boulder.ibm.com/ibmd...adme.html#wq45

I know, right above that it says you must bind utilities for run-time
clients, one for each os type. So it's a bit contradicting. But I looked
up my notes from when we went to FP11, and we did not run from any
clients. So to go to FP11, they are right. To FP13, not so clear.


Here is the error our application was spitting.

CATDbCursor Error : 38553-[IBM][CLI Driver][DB2/AIX64] SQL0443N Routine
"SYSIBM.SQLCOLUMNS" (specific name "COLUMNS") has returned an error SQLS
Error sdaiESYSERROR : Underlying system error
( RdbMapping::RdbMapping CATDbCursor Error in Select )


db2schema.bnd from clients, and magic, it all works again.

FP13 was fixing a few issues for us, already good reports of performance
improvments for certain operations! We admins rarly ever get positive
feedback, so something must be really be good.

"yoyo" <yoyo@ma.com> wrote in message
news:qv2dnYZybJUsr4TYnZ2dnUVZ_tmdnZ2d@centurytel.n et...
> Just to help somebody else if they are looking, we wasted 2 hours last
> night trying to figure out the problem. (With a manager over our shoulder)
> We upgraded our 8.1 FP11 instance to FP13. Instructions first say that
> there are no instruction changes from FP11 to FP13. Great, so we install
> FP13, run all the binds on the server like it says, same ones we did when
> we went to FP11, and we can command line connect, but our applicatoin
> cannot connect. We thought we had an applicaiton problem, so we spend time
> trying to figure out what, rebuild our connection modules, express
> schema...few other things...no love...
>
> We ended up having to run db2schema.bnd from a client (from one of each OS
> type). Instructions specifcally say:
>
> """"
> Bind db2schema.bnd to existing databases
>
> After installation on the server, an additional bind file needs to be
> bound to existing databases. This requirement does not apply to clients.
> """"
> http://download.boulder.ibm.com/ibmd...adme.html#wq45
>
> I know, right above that it says you must bind utilities for run-time
> clients, one for each os type. So it's a bit contradicting. But I looked
> up my notes from when we went to FP11, and we did not run from any
> clients. So to go to FP11, they are right. To FP13, not so clear.
>
>
> Here is the error our application was spitting.
>
> CATDbCursor Error : 38553-[IBM][CLI Driver][DB2/AIX64] SQL0443N Routine
> "SYSIBM.SQLCOLUMNS" (specific name "COLUMNS") has returned an error SQLS
> Error sdaiESYSERROR : Underlying system error
> ( RdbMapping::RdbMapping CATDbCursor Error in Select )
>
>
> db2schema.bnd from clients, and magic, it all works again.
>
> FP13 was fixing a few issues for us, already good reports of performance
> improvments for certain operations! We admins rarly ever get positive
> feedback, so something must be really be good.

There is always a potential need to rebind remote clients depending on which
fixpack level your clients are at. There is no way that a server fixpack
instructions could know which client release and fixpack you are running, so
there is no way they can say that no rebind is necessary.

Mark A wrote:
> "yoyo" <yoyo@ma.com> wrote in message
> news:qv2dnYZybJUsr4TYnZ2dnUVZ_tmdnZ2d@centurytel.n et...
>
>>Just to help somebody else if they are looking, we wasted 2 hours last
>>night trying to figure out the problem. (With a manager over our shoulder)
>>We upgraded our 8.1 FP11 instance to FP13. Instructions first say that
>>there are no instruction changes from FP11 to FP13. Great, so we install
>>FP13, run all the binds on the server like it says, same ones we did when
>>we went to FP11, and we can command line connect, but our applicatoin
>>cannot connect. We thought we had an applicaiton problem, so we spend time
>>trying to figure out what, rebuild our connection modules, express
>>schema...few other things...no love...
>>
>>We ended up having to run db2schema.bnd from a client (from one of each OS
>>type). Instructions specifcally say:
>>
>>""""
>>Bind db2schema.bnd to existing databases
>>
>>After installation on the server, an additional bind file needs to be
>>bound to existing databases. This requirement does not apply to clients.
>>""""
>>http://download.boulder.ibm.com/ibmd...adme.html#wq45
>>
>>I know, right above that it says you must bind utilities for run-time
>>clients, one for each os type. So it's a bit contradicting. But I looked
>>up my notes from when we went to FP11, and we did not run from any
>>clients. So to go to FP11, they are right. To FP13, not so clear.
>>
>>
>>Here is the error our application was spitting.
>>
>>CATDbCursor Error : 38553-[IBM][CLI Driver][DB2/AIX64] SQL0443N Routine
>>"SYSIBM.SQLCOLUMNS" (specific name "COLUMNS") has returned an error SQLS
>> Error sdaiESYSERROR : Underlying system error
>> ( RdbMapping::RdbMapping CATDbCursor Error in Select )
>>
>>
>>db2schema.bnd from clients, and magic, it all works again.
>>
>>FP13 was fixing a few issues for us, already good reports of performance
>>improvments for certain operations! We admins rarly ever get positive
>>feedback, so something must be really be good.
>
>
> There is always a potential need to rebind remote clients depending on which
> fixpack level your clients are at. There is no way that a server fixpack
> instructions could know which client release and fixpack you are running, so
> there is no way they can say that no rebind is necessary.
>
>

Well, it says it. "This requirement does not apply to clients." Hence
the wasted time. I don't pretend to be a database architect, which is
why I rely on the documentation to tell me what things need to be done
when you apply a fixpak. DB2 documention is pretty reliable, that is why
we went looking for application issues first.

We had upgraded all our clients for this application to FP13 as well and
had dropped and re-created all the run-time client instances.

"yoyo" <yoyo@ma.com> wrote in message
news:qtGdnZQA6dFvpoTYnZ2dnUVZ_oadnZ2d@centurytel.n et...
> Well, it says it. "This requirement does not apply to clients." Hence the
> wasted time. I don't pretend to be a database architect, which is why I
> rely on the documentation to tell me what things need to be done when you
> apply a fixpak. DB2 documention is pretty reliable, that is why we went
> looking for application issues first.
>
> We had upgraded all our clients for this application to FP13 as well and
> had dropped and re-created all the run-time client instances.

It gets a little confusing if they are talking about the client that is
installed on the server. These are usually automatically updated when the
server is updated.

But remote clients are different, and potentially a remote bind is need for
them. Sometimes it is not needed if the particular code did not change on
the client, but the server install instructions have no way of knowing which
version of the client you have, and they don't know which server fixpack you
are upgrading from.

Mark A wrote:
> "yoyo" <yoyo@ma.com> wrote in message
> news:qtGdnZQA6dFvpoTYnZ2dnUVZ_oadnZ2d@centurytel.n et...
>
>>Well, it says it. "This requirement does not apply to clients." Hence the
>>wasted time. I don't pretend to be a database architect, which is why I
>>rely on the documentation to tell me what things need to be done when you
>>apply a fixpak. DB2 documention is pretty reliable, that is why we went
>>looking for application issues first.
>>
>>We had upgraded all our clients for this application to FP13 as well and
>>had dropped and re-created all the run-time client instances.
>
>
> It gets a little confusing if they are talking about the client that is
> installed on the server. These are usually automatically updated when the
> server is updated.
>
> But remote clients are different, and potentially a remote bind is need for
> them. Sometimes it is not needed if the particular code did not change on
> the client, but the server install instructions have no way of knowing which
> version of the client you have, and they don't know which server fixpack you
> are upgrading from.
>
>

Yep, thanks for clarifying, I understand. I just thought I'd post so
others around the world if they go searching around, it's one more place
to find an answer.

The bind file db2schema.bnd is needed to create a package for a stored
procedure that is used by CLI-based applications (and JDBC/.NET/etc).


Since the package is for a stored procedure and stored procedures are
always executed at the server, the bind file should only be bound at
the server (connected locally).

The only utilities that needs to be bound from a remote client are
"db2cli.lst", "db2ubind.lst" (and perhaps one of the ddcs*.lst lists if
you are connecting to host databases like DB2 on z/OS).

This is true for both DB2 UDB Version 8 and DB2 UDB Version 9. The
instructions do not change between DB2 UDB Version 8 FixPak 11 and 13.


I'm afraid I can't tell what the cause of your problem was based on the
error message, but if it happens again I recommend that you contact DB2
technical support. SQL0443N is a rather common error message. The
important part of its messages is the diagnostic text. For example in
your case, this would be "Error sdaiESYSERROR : Underlying system
error ( RdbMapping::RdbMapping CATDbCursor Error in Select )...".
If you wish to get a better understanding of what this "underlying
system error" was, and how/if the problem was resolved, there may be an
entry in the db2diag.log at that time with some additional details.

For more information about the meaning of that error, refer to:
http://publib.boulder.ibm.com/infoce...e/rsql0400.htm

You can see more information about the db2schema.bnd bind file in the
DB2 UDB Version 8 and DB2 Version 9 documentation here (respectively):
http://publib.boulder.ibm.com/infoce...d/r0007866.htm
http://publib.boulder.ibm.com/infoce...c/r0007866.htm


73blazer wrote:
> Mark A wrote:
> > "yoyo" <yoyo@ma.com> wrote in message
> > news:qtGdnZQA6dFvpoTYnZ2dnUVZ_oadnZ2d@centurytel.n et...
> >
> >>Well, it says it. "This requirement does not apply to clients." Hence the
> >>wasted time. I don't pretend to be a database architect, which is why I
> >>rely on the documentation to tell me what things need to be done when you
> >>apply a fixpak. DB2 documention is pretty reliable, that is why we went
> >>looking for application issues first.
> >>
> >>We had upgraded all our clients for this application to FP13 as well and
> >>had dropped and re-created all the run-time client instances.
> >
> >
> > It gets a little confusing if they are talking about the client that is
> > installed on the server. These are usually automatically updated when the
> > server is updated.
> >
> > But remote clients are different, and potentially a remote bind is need for
> > them. Sometimes it is not needed if the particular code did not change on
> > the client, but the server install instructions have no way of knowing which
> > version of the client you have, and they don't know which server fixpack you
> > are upgrading from.
> >
> >
>
> Yep, thanks for clarifying, I understand. I just thought I'd post so
> others around the world if they go searching around, it's one more place
> to find an answer.
yoyo wrote:
> Just to help somebody else if they are looking, we wasted 2 hours last
> night trying to figure out the problem. (With a manager over our shoulder)
> We upgraded our 8.1 FP11 instance to FP13. Instructions first say that
> there are no instruction changes from FP11 to FP13. Great, so we install
> FP13, run all the binds on the server like it says, same ones we did
> when we went to FP11, and we can command line connect, but our
> applicatoin cannot connect. We thought we had an applicaiton problem, so
> we spend time trying to figure out what, rebuild our connection modules,
> express schema...few other things...no love...
>
> We ended up having to run db2schema.bnd from a client (from one of each
> OS type). Instructions specifcally say:
>
> """"
> Bind db2schema.bnd to existing databases
>
> After installation on the server, an additional bind file needs to be
> bound to existing databases. This requirement does not apply to clients.
> """"
> http://download.boulder.ibm.com/ibmd...adme.html#wq45
>
> I know, right above that it says you must bind utilities for run-time
> clients, one for each os type. So it's a bit contradicting. But I looked
> up my notes from when we went to FP11, and we did not run from any
> clients. So to go to FP11, they are right. To FP13, not so clear.
>
>
> Here is the error our application was spitting.
>
> CATDbCursor Error : 38553-[IBM][CLI Driver][DB2/AIX64] SQL0443N Routine
> "SYSIBM.SQLCOLUMNS" (specific name "COLUMNS") has returned an error SQLS
> Error sdaiESYSERROR : Underlying system error
> ( RdbMapping::RdbMapping CATDbCursor Error in Select )
>
>
> db2schema.bnd from clients, and magic, it all works again.
>
> FP13 was fixing a few issues for us, already good reports of performance
> improvments for certain operations! We admins rarly ever get positive
> feedback, so something must be really be good.