remote bind error

James Campbell

remote bind error
FYI - I revoked all authorities for the user and re-granted the needed
authorities and all now works. Got me why as the SYSIBM.%AUTH$ tables
look the same as they did before I went through the revoke grant
process.

Thank all of you for your input....

Happy Holidays

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: Campbell, Jim
Sent: Wednesday, December 12, 2007 12:53 PM
To: 'DB2 Database Discussion list at IDUG'
Subject: RE: [DB2-L] remote bind error

It's a valid id but not one you can log into TSO with.

This is curious.

Thanks all for the help

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of P K Ganapathy
Sent: Wednesday, December 12, 2007 12:44 PM
To: [login to unmask email]
Subject: Re: [DB2-L] remote bind error

The value used in the OWNER keyword has to be a valid TSO RACF id (not a

secondary auth) on the remote system for a remote Bind. I don't think
DB2 is
able to look up the secondary authorizations on the remote system.

Not sure if this was how IBM intended for this to work.

Ideally, DB2 should be able to look up the RACF and the secondary auth
before
attempting to bind on the remote system, not just the primary RACF. A
probable PMR for IBM...

If you can logon to the remote system and do a local bind using the
secondary
auth, why not on a remote bind using the secondary auth?

-PK.Ganapathy

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information, and much more.
If you have not yet signed up for Basic Membership in IDUG, available at
no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

James Campbell

Re: remote bind error
(in response to James Campbell)
Steve,

I wish I knew what the exact problem was. When I looked at all the
SYSIBM.%AUTH% tables for the database and compared it to all the other
databases we have and the flags were identical.

Since it was a hot issue and could not wait for a resolution from IBM.
After discussing the issue with my fellow DBA's We came to the
conclusion that since this database was accessed only by dynamic SQL
since our upgrade to V8 and now its purpose changed to using static SQL
it may have something to do with the conversion from V7 so we never
noticed this issue.

I revoked only those authorities associated with the database (PACKADM,
CREATE IN, BINDADD Etc..) not the individual tables, then re-granted
them. That solved our issue with binds.

After the grants we confirmed we looked at the resulting %AUTH% tables
and they looked the same as before the revoke but all works now???

It still has us stumped but it works now so we are not going to spend
any more time on this issue. I have a copy of the catalog before the
issue cropped up and will take a deeper look at it as time permits.

I Thank ALL for your assistance on this...

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
1206 S. Quince St. Olympia, WA 98501
360-704-4015 (voice plus voice-mail)
360-586-8869 (fax)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]

Sent: Thursday, December 13, 2007 9:03 PM
To: Campbell, Jim
Subject: RE: [DB2-L] remote bind error

Hi Jim,
sorry for the late reply, particularly as you have fixed the
problem
8-( I just wondered if it was one of the 'AT ALL LOCATIONS' bits that
caused your problem? I know it seems to be a bind authority error but I
have a niggling thought that it may be connected to the table
authorities.

Did you by any chance revoke all of those table/view authorities
and
regrant them AT ALL LOCATIONS?

Regards,

Steve T

-----Original Message-----
From: Campbell, Jim [mailto:[login to unmask email]
Sent: Thursday, 13 December 2007 10:12
To: [login to unmask email]
Subject: Re: [DB2-L] remote bind error


FYI - I revoked all authorities for the user and re-granted the needed
authorities and all now works. Got me why as the SYSIBM.%AUTH$ tables
look the same as they did before I went through the revoke grant
process.

Thank all of you for your input....

Happy Holidays

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: Campbell, Jim
Sent: Wednesday, December 12, 2007 12:53 PM
To: 'DB2 Database Discussion list at IDUG'
Subject: RE: [DB2-L] remote bind error

It's a valid id but not one you can log into TSO with.

This is curious.

Thanks all for the help

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of P K Ganapathy
Sent: Wednesday, December 12, 2007 12:44 PM
To: [login to unmask email]
Subject: Re: [DB2-L] remote bind error

The value used in the OWNER keyword has to be a valid TSO RACF id (not a

secondary auth) on the remote system for a remote Bind. I don't think
DB2 is
able to look up the secondary authorizations on the remote system.

Not sure if this was how IBM intended for this to work.

Ideally, DB2 should be able to look up the RACF and the secondary auth
before
attempting to bind on the remote system, not just the primary RACF. A
probable PMR for IBM...

If you can logon to the remote system and do a local bind using the
secondary
auth, why not on a remote bind using the secondary auth?

-PK.Ganapathy

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information, and much more.
If you have not yet signed up for Basic Membership in IDUG, available at
no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list
archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site,
you
can also access the IDUG Online Learning Center, Tech Library and Code
Place, see the latest IDUG conference information, and much more. If
you
have not yet signed up for Basic Membership in IDUG, available at no
cost,
click on Member Services at http://www.idug.org/lsms

************************************************************************
IMPORTANT:

* This transmission is intended for the use of the addressee only and
might contain sensitive or legally privileged information. If you are
NOT the intended recipient, you are notified that any use or
dissemination of this communication is strictly prohibited. If you
receive this transmission in error, please notify the author immediately
by telephone and delete all copies of this transmission together with
any attachments.

* The Australian Customs Service DOES NOT AUTHORISE the recipient to
further disclose this email or its contents without permission of the
originator.

* Unsolicited commercial emails MUST NOT be forwarded to the originator
of this transmission unless prior consent has been given.


***********************************************************************

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Gerard LE ROY

Re: remote bind error
(in response to James Campbell)
Hello the List,
Some months ago, we had a similar problem (DB2 V7) with 2 IDs.
I discovered that these IDs had more than 245 groups connected and therefore
some secondary ID were ignored by DSN3ATH exit.
If it can help.
Regards
Gerard


-----Message d'origine-----
De : DB2 Data Base Discussion List [mailto:[login to unmask email] De la part
de Campbell, Jim
Envoyé : vendredi 14 décembre 2007 17:12
À : [login to unmask email]
Objet : Re: remote bind error

Steve,

I wish I knew what the exact problem was. When I looked at all the
SYSIBM.%AUTH% tables for the database and compared it to all the other
databases we have and the flags were identical.

Since it was a hot issue and could not wait for a resolution from IBM.
After discussing the issue with my fellow DBA's We came to the
conclusion that since this database was accessed only by dynamic SQL
since our upgrade to V8 and now its purpose changed to using static SQL
it may have something to do with the conversion from V7 so we never
noticed this issue.

I revoked only those authorities associated with the database (PACKADM,
CREATE IN, BINDADD Etc..) not the individual tables, then re-granted
them. That solved our issue with binds.

After the grants we confirmed we looked at the resulting %AUTH% tables
and they looked the same as before the revoke but all works now???

It still has us stumped but it works now so we are not going to spend
any more time on this issue. I have a copy of the catalog before the
issue cropped up and will take a deeper look at it as time permits.

I Thank ALL for your assistance on this...

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
1206 S. Quince St. Olympia, WA 98501
360-704-4015 (voice plus voice-mail)
360-586-8869 (fax)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]

Sent: Thursday, December 13, 2007 9:03 PM
To: Campbell, Jim
Subject: RE: [DB2-L] remote bind error

Hi Jim,
sorry for the late reply, particularly as you have fixed the
problem
8-( I just wondered if it was one of the 'AT ALL LOCATIONS' bits that
caused your problem? I know it seems to be a bind authority error but I
have a niggling thought that it may be connected to the table
authorities.

Did you by any chance revoke all of those table/view authorities
and
regrant them AT ALL LOCATIONS?

Regards,

Steve T

-----Original Message-----
From: Campbell, Jim [mailto:[login to unmask email]
Sent: Thursday, 13 December 2007 10:12
To: [login to unmask email]
Subject: Re: [DB2-L] remote bind error


FYI - I revoked all authorities for the user and re-granted the needed
authorities and all now works. Got me why as the SYSIBM.%AUTH$ tables
look the same as they did before I went through the revoke grant
process.

Thank all of you for your input....

Happy Holidays

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: Campbell, Jim
Sent: Wednesday, December 12, 2007 12:53 PM
To: 'DB2 Database Discussion list at IDUG'
Subject: RE: [DB2-L] remote bind error

It's a valid id but not one you can log into TSO with.

This is curious.

Thanks all for the help

Jim Campbell
Sr. Database Administrator
Administrative Office of the Courts (AOC)
[login to unmask email]

To know that we know what we know, and to know that we do not know what
we do not know, that is true knowledge.

-----Copernicus

The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you receive
this in error, please contact the sender and delete or destroy this
message and any copies.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of P K Ganapathy
Sent: Wednesday, December 12, 2007 12:44 PM
To: [login to unmask email]
Subject: Re: [DB2-L] remote bind error

The value used in the OWNER keyword has to be a valid TSO RACF id (not a

secondary auth) on the remote system for a remote Bind. I don't think
DB2 is
able to look up the secondary authorizations on the remote system.

Not sure if this was how IBM intended for this to work.

Ideally, DB2 should be able to look up the RACF and the secondary auth
before
attempting to bind on the remote system, not just the primary RACF. A
probable PMR for IBM...

If you can logon to the remote system and do a local bind using the
secondary
auth, why not on a remote bind using the secondary auth?

-PK.Ganapathy

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information, and much more.
If you have not yet signed up for Basic Membership in IDUG, available at
no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list
archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site,
you
can also access the IDUG Online Learning Center, Tech Library and Code
Place, see the latest IDUG conference information, and much more. If
you
have not yet signed up for Basic Membership in IDUG, available at no
cost,
click on Member Services at http://www.idug.org/lsms

************************************************************************
IMPORTANT:

* This transmission is intended for the use of the addressee only and
might contain sensitive or legally privileged information. If you are
NOT the intended recipient, you are notified that any use or
dissemination of this communication is strictly prohibited. If you
receive this transmission in error, please notify the author immediately
by telephone and delete all copies of this transmission together with
any attachments.

* The Australian Customs Service DOES NOT AUTHORISE the recipient to
further disclose this email or its contents without permission of the
originator.

* Unsolicited commercial emails MUST NOT be forwarded to the originator
of this transmission unless prior consent has been given.


***********************************************************************

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site, you
can also access the IDUG Online Learning Center, Tech Library and Code
Place, see the latest IDUG conference information, and much more. If you
have not yet signed up for Basic Membership in IDUG, available at no cost,
click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms