Client version higher than DB causes error

[Brian Tkatch]

Server: DB2/SUN 8.1.6
Client: DB2 Connect Personal Edition (No 11)
<URL:ftp://ftp.software.ibm.com/ps/products/db2/fixes2/english-us/db2winIA32v8/fixpak/FP11_WR21365/FP11_WR21365_CONPE.exe>

Uninstalled old version, installed new version, and am now trying to
use the CLP.

<<<<<<<<<<<<
For more detailed help, refer to the Online Reference Manual.

db2 => UPDATE COMMAND OPTIONS USING C OFF
DB20000I The UPDATE COMMAND OPTIONS command completed successfully.
db2 => CONNECT TO DEV USER xxx USING xxx

Database Connection Information

Database server = DB2/SUN 8.1.6
SQL authorization ID = xxx
Local database alias = DEV

db2 => SET SCHEMA xxx
DB21034E The command was processed as an SQL statement because it was
not a
valid Command Line Processor command. During SQL processing it
returned:
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 => select * from syscat.tables
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 => values current date
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 =>
<<<<<<<<<<<<

Must the db be upgraded too?

B.

[Dave Hughes]

Brian Tkatch wrote:

Server: DB2/SUN 8.1.6
Client: DB2 Connect Personal Edition (No 11)
<url:
ftp://ftp.software.ibm.com/ps/produc...h-us/db2winIA3
2v8/fixpak/FP11_WR21365/FP11_WR21365_CONPE.exe>

Uninstalled old version, installed new version, and am now trying to
use the CLP.

<<<<<<<<<<<<
For more detailed help, refer to the Online Reference Manual.

db2 => UPDATE COMMAND OPTIONS USING C OFF
DB20000I The UPDATE COMMAND OPTIONS command completed successfully.
db2 => CONNECT TO DEV USER xxx USING xxx

Database Connection Information

Database server = DB2/SUN 8.1.6
SQL authorization ID = xxx
Local database alias = DEV

db2 => SET SCHEMA xxx
DB21034E The command was processed as an SQL statement because it was
not a
valid Command Line Processor command. During SQL processing it
returned:
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 => select * from syscat.tables
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 => values current date
SQL0805N Package "NULLID.SQLC2E07 0X4141414141634555" was not found.
SQLSTATE=51002
db2 =>
<<<<<<<<<<<<

Must the db be upgraded too?

B.

I think you need to rebind the client utilities against the database.
See the "Binding bind files" section in the fixpak readme for more
details (this only needs to be done once per database, and typically
requires administrative privileges on the database).
HTH,

Dave.

--

[Brian Tkatch]

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working with
..NET.

B.

[Dave Hughes]

Brian Tkatch wrote:

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working with
.NET.

B.

AFAIK (and admittedly I know very little about this whole "binding"
business beyond the fact that I've run into this same problem myself),
it won't affect any other users, unless they too have upgraded to the
same fixpak and are experiencing the same problem (in which case it'll
fix it for them too).
HTH,

Dave.

--

[Mark A]

"Brian Tkatch" <Ma***********@ThePentagon.com> wrote in message
news:11**********************@d71g2000cwd.googlegr oups.com...

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working with
.NET.

B.

Generally speaking, each version (or fixpack) of a DB2 client must do the
bind on the remote database (use the Configuration Assistant on the client,
bind option, and select all bind files). You can use the instance owner id
to do the bind. This only has to be done once for each client version, and
not for each client installed. But you must do it for each remote database.

The client bind files stay with database server when the server is upgraded,
but the local DB2 client on server must be bound after an upgrade (except on
Windows where it is automatically done during the install, mostly because
the client version on the server must be the same as the database server
version in Version 8 on Windows).

In some cases, the DB2 client may not change from fixpack to fixpack, so you
can sometimes get away without the bind, but it is a good idea to do it
anyway.

[Pierre Saint-Jacques]

It should not affect any other users of different client fixpacks.
It has been my experience that IBM takes good care to see that for each fix
pack the packages are uniquely identified.
Your binding will then generate a unique package identifier for your version
and will not attempt to overwrite any previous version as their names will
be different.
HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"Brian Tkatch" <Ma***********@ThePentagon.com> a écrit dans le message de
news: 11**********************@d71g2000cwd.googlegroups. com...

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working with
.NET.

B.

[Brian Tkatch]

Mark A wrote:

"Brian Tkatch" <Ma***********@ThePentagon.com> wrote in message
news:11**********************@d71g2000cwd.googlegr oups.com...

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working with
.NET.

B.

Generally speaking, each version (or fixpack) of a DB2 client must do the
bind on the remote database (use the Configuration Assistant on the client,
bind option, and select all bind files). You can use the instance owner id
to do the bind. This only has to be done once for each client version, and
not for each client installed. But you must do it for each remote database.

The client bind files stay with database server when the server is upgraded,
but the local DB2 client on server must be bound after an upgrade (except on
Windows where it is automatically done during the install, mostly because
the client version on the server must be the same as the database server
version in Version 8 on Windows).

In some cases, the DB2 client may not change from fixpack to fixpack, so you
can sometimes get away without the bind, but it is a good idea to do it
anyway.

OK, thanx, i ust tried this:

1) Opened Configuration Assistant
2) Right-clicked on the development alias
3) Chose Bind.
4) Bind File Location chose "C:\Program Files\IBM\SQLLIB\bnd" (already
there with files.
5) Under "Select Utilities or files to bind" i chose "Select All"
6) Left Bind Options alone. (BLOCKING All, SQLERROR CONTINUE)
7) Under "Enter Connection Information" the DBA came by and put in the
instance owner information.
8) Clicked Bind.
[results are below, two warnings, everything else was fine]
9) In the client (tried the still open one and terminated and tried a
new one. )
db2 => set schema [schema]
DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned:
SQL0551N "[user]" does not have the privilege to perform operation
"EXECUTE" on object "NULLID.SQLC2E07". SQLSTATE=42501

So, the errror message is slightly shorter. Should i count that as
progress? :)

B.

The results tab (with minor formatting):

LINE MESSAGES FOR db2ajgrt.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2arxcs.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2arxrr.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2arxur.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2arxrs.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2arxnc.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR db2clpcs.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clprr.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clpur.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clprs.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clpnc.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR db2uexpm.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uredp.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2urexp.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uimpm.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uimtb.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2ueiwi.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uigsi.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uiici.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uiict.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2ugtpi.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2pctsp.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2dropv.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2ucktb.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uqtpd.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uqtnm.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2ulxld.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uipkg.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2atld.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2uImpInsUpdate.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clipk.bnd
------ -------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

LINE MESSAGES FOR db2clist.bnd
------ ------------------------------------------------
SQL0061W The binder is in progress.
SQL0091N Binding was ended with "0" errors and "0" warnings.

Bind completed with errors and/or warnings.

[Dave Hughes]

Brian Tkatch wrote:

Mark A wrote:

"Brian Tkatch" <Ma***********@ThePentagon.com> wrote in message
news:11**********************@d71g2000cwd.googlegr oups.com...

How would this affect the other users of the database?

Right now, i am the only one upgrading, so i can start working
with .NET.

B.

Generally speaking, each version (or fixpack) of a DB2 client must
do the bind on the remote database (use the Configuration Assistant
on the client, bind option, and select all bind files). You can use
the instance owner id to do the bind. This only has to be done once
for each client version, and not for each client installed. But you
must do it for each remote database.

The client bind files stay with database server when the server is
upgraded, but the local DB2 client on server must be bound after an
upgrade (except on Windows where it is automatically done during
the install, mostly because the client version on the server must
be the same as the database server version in Version 8 on Windows).

In some cases, the DB2 client may not change from fixpack to
fixpack, so you can sometimes get away without the bind, but it is
a good idea to do it anyway.

OK, thanx, i ust tried this:

1) Opened Configuration Assistant
2) Right-clicked on the development alias
3) Chose Bind.
4) Bind File Location chose "C:\Program Files\IBM\SQLLIB\bnd" (already
there with files.
5) Under "Select Utilities or files to bind" i chose "Select All"
6) Left Bind Options alone. (BLOCKING All, SQLERROR CONTINUE)
7) Under "Enter Connection Information" the DBA came by and put in the
instance owner information.
8) Clicked Bind.
[results are below, two warnings, everything else was fine]
9) In the client (tried the still open one and terminated and tried a
new one. )
db2 => set schema [schema]
DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned:
SQL0551N "[user]" does not have the privilege to perform operation
"EXECUTE" on object "NULLID.SQLC2E07". SQLSTATE=42501

So, the errror message is slightly shorter. Should i count that as
progress? :)

[snip]

It's progress, but I think the problem is the BIND command was missing
the GRANT PUBLIC option. From the readme for the latest DB2 fixpak:

Binding to DB2 UDB databases

After applying fixes, you must issue one of the following command
sequences:

At a command prompt, enter:
db2 terminate
db2 CONNECT TO <dbname>
db2 BIND <path>/@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION
ADD
db2 terminate

or

At the DB2 command line, enter:
TERMINATE
CONNECT TO <dbname>
BIND <path>/@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD
TERMINATE

Where <dbname> represents the name of a database to which the utilities
should be bound, and where <path> represents the full path name of the
directory where the bind files are located, such as $HOME/sqllib/bnd
where $HOME represents the home directory of the instance for the
database server. db2ubind.lst and db2cli.lst contain lists of required
bind files used by DB2 UDB. Packages that are already bound will return
an SQL0719 error. This is expected.
HTH,

Dave.
--

[Brian Tkatch]

Dave Hughes wrote:

Brian Tkatch wrote:

Mark A wrote:

"Brian Tkatch" <Ma***********@ThePentagon.com> wrote in message
news:11**********************@d71g2000cwd.googlegr oups.com...
> How would this affect the other users of the database?
>
> Right now, i am the only one upgrading, so i can start working
> with .NET.
>
> B.
>

Generally speaking, each version (or fixpack) of a DB2 client must
do the bind on the remote database (use the Configuration Assistant
on the client, bind option, and select all bind files). You can use
the instance owner id to do the bind. This only has to be done once
for each client version, and not for each client installed. But you
must do it for each remote database.

The client bind files stay with database server when the server is
upgraded, but the local DB2 client on server must be bound after an
upgrade (except on Windows where it is automatically done during
the install, mostly because the client version on the server must
be the same as the database server version in Version 8 on Windows).

In some cases, the DB2 client may not change from fixpack to
fixpack, so you can sometimes get away without the bind, but it is
a good idea to do it anyway.

OK, thanx, i ust tried this:

1) Opened Configuration Assistant
2) Right-clicked on the development alias
3) Chose Bind.
4) Bind File Location chose "C:\Program Files\IBM\SQLLIB\bnd" (already
there with files.
5) Under "Select Utilities or files to bind" i chose "Select All"
6) Left Bind Options alone. (BLOCKING All, SQLERROR CONTINUE)
7) Under "Enter Connection Information" the DBA came by and put in the
instance owner information.
8) Clicked Bind.
[results are below, two warnings, everything else was fine]
9) In the client (tried the still open one and terminated and tried a
new one. )
db2 => set schema [schema]
DB21034E The command was processed as an SQL statement because it was
not a valid Command Line Processor command. During SQL processing it
returned:
SQL0551N "[user]" does not have the privilege to perform operation
"EXECUTE" on object "NULLID.SQLC2E07". SQLSTATE=42501

So, the errror message is slightly shorter. Should i count that as
progress? :)

[snip]

It's progress, but I think the problem is the BIND command was missing
the GRANT PUBLIC option. From the readme for the latest DB2 fixpak:

Binding to DB2 UDB databases

After applying fixes, you must issue one of the following command
sequences:

At a command prompt, enter:
db2 terminate
db2 CONNECT TO <dbname>
db2 BIND <path>/@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION
ADD
db2 terminate

or

At the DB2 command line, enter:
TERMINATE
CONNECT TO <dbname>
BIND <path>/@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD
TERMINATE

Where <dbname> represents the name of a database to which the utilities
should be bound, and where <path> represents the full path name of the
directory where the bind files are located, such as $HOME/sqllib/bnd
where $HOME represents the home directory of the instance for the
database server. db2ubind.lst and db2cli.lst contain lists of required
bind files used by DB2 UDB. Packages that are already bound will return
an SQL0719 error. This is expected.
HTH,

Dave.
--

From the readme for the latest DB2 fixpak:
Ok, ok, i get the point. :)

But the readme is so confusing to find what i need, so i'm a bit
reluctant to start dsearching it.
BIND <path>/@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD

So, i redid the BIND option in the Configuration Assistant. But (step 6
above) i did not leave "Bind Options" alone. I added ACTION=>ADD and
GRANT=>PUBLIC. This failed because the packages were already there, and
the CLP did not get any better. So, we changed ACTION=>REPLACE.

First time it gave an deadlock timeout error on one, so i exited my
existing db2 connection and tried again. Second time it hung after the
first one, so we killed it. Thrid time it seemed to have worked but
gave errors. Though, the CLP seems to work now.

I appreciate the help.

B.

(non-perfect) Results (most was left out):

LINE MESSAGES FOR db2arxnc.bnd
------ -----------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR db2clpnc.bnd
------ -----------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.
LINE MESSAGES FOR db2arxnc.bnd
------ -----------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR db2clpnc.bnd
------ -----------------------------
SQL0061W The binder is in progress.
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR db2ubind.lst
------ -----------------------------
SQL0061W The binder is in progress.
[no SQL0091N telling me its ok]
LINE MESSAGES FOR db2clpnc.bnd
------ -----------------------------
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526

LINE MESSAGES FOR db2arxnc.bnd
------ -----------------------------
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526

LINE MESSAGES FOR db2ubind.lst
------ -----------------------------
SQL0091N Binding was ended with "0" errors and "2" warnings.
LINE MESSAGES FOR ddcs400.lst
------ -----------------------------
SQL0061W The binder is in progress.
[no SQL0091N telling me its ok]
LINE MESSAGES FOR db2clpnc.bnd
------ -----------------------------
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526

LINE MESSAGES FOR db2arxnc.bnd
------ -----------------------------
SQL0595W Isolation level "NC" has been escalated to "UR".
SQLSTATE=01526

LINE MESSAGES FOR ddcs400.lst
------ -----------------------------
SQL0091N Binding was ended with "0" errors and "2" warnings.

LINE MESSAGES FOR dxxbind.lst
------ -----------------------------
SQL0061W The binder is in progress.
[no SQL0091N telling me its ok]
LINE MESSAGES FOR dxxcomp.bnd
------ -----------------------------
2026 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=01532

LINE MESSAGES FOR dxxbind.lst
------ -----------------------------
SQL0091N Binding was ended with "0" errors and "1" warnings.
LINE MESSAGES FOR dxxcomp.bnd
------ -----------------------------
SQL0061W The binder is in progress.
2026 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=01532
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR dxxMigv.bnd
------ -----------------------------
SQL0061W The binder is in progress.
3930 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4589 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4699 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4732 SQL0104N An unexpected token "ALLOW ADMINISTRATION" was
found following "HORIZATION = :H00022". Expected
tokens may
include: "<space>". SQLSTATE=42601
SQL0091N Binding was ended with "0" errors and "4" warnings.

LINE MESSAGES FOR dxxMigv.bnd
------ -----------------------------
3930 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4589 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4699 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
4732 SQL0104N An unexpected token "ALLOW ADMINISTRATION" was
found following "HORIZATION = :H00022". Expected
tokens may
include: "<space>". SQLSTATE=42601
LINE MESSAGES FOR dxxMigv81.bnd
------ -----------------------------
85 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
LINE MESSAGES FOR dxxMigv.lst
------ -----------------------------
SQL0091N Binding was ended with "0" errors and "5" warnings.
LINE MESSAGES FOR dxxMigv81.bnd
------ -----------------------------
SQL0061W The binder is in progress.
85 SQL0204N "DB2XML.XML_USAGE" is an undefined name.
SQLSTATE=42704
SQL0091N Binding was ended with "0" errors and "1" warnings.

LINE MESSAGES FOR mqxml.bnd
------ -----------------------------
SQL0061W The binder is in progress.
142 SQL0440N No authorized routine named "MQRECEIVE" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
239 SQL0440N No authorized routine named "MQRECEIVEALL" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
472 SQL0440N No authorized routine named "MQSEND" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
643 SQL0440N No authorized routine named "MQSEND" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
703 SQL0440N No authorized routine named "MQRECEIVE" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
786 SQL0440N No authorized routine named "MQRECEIVEALL" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
879 SQL0440N No authorized routine named "MQRECEIVECLOB" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
978 SQL0440N No authorized routine named "MQRECEIVEALLCLOB" of
type "FUNCTION" having compatible arguments was
found.
SQLSTATE=42884
1222 SQL0440N No authorized routine named "MQSEND" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
1411 SQL0440N No authorized routine named "MQSEND" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
1482 SQL0440N No authorized routine named "MQRECEIVECLOB" of type
"FUNCTION" having compatible arguments was found.
SQLSTATE=42884
1565 SQL0440N No authorized routine named "MQRECEIVEALLCLOB" of
type "FUNCTION" having compatible arguments was
found.
SQLSTATE=42884
SQL0091N Binding was ended with "0" errors and "12"
warnings.

B.