Occasional -30082 after an SQL1024

[shorti]

Hello,

I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:

SQL30082N Attempt to establish connection failed with security reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001

SQLSTATE 08001: The application requester is unable to establish the
connection.

Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the security
error is described by the <reason-codeand corresponding
<reason-stringvalue.

19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.

For one, we have no 'remote' database. The database is local...so why
this error? Second, the userid seems valid in all other cases.

Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.

I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.

Any ideas?

I am running v8.2 on AIX 5.3.

Thanks!

[klh]

We've had similar issues in the Windows environment. Usually it
relates to the ID that is used to start up the instance. This ID has
to have permissions to be able to authenticate the user when a
connection attempt is made.

For us we were having the issue whenever a "group policy" change was
made that took away some of the inherent rights that the start up ID
needs. In the Windows environment these are things like "replace a
token level process", "run as a batch job", etc. I don't know what
they'd be in an AIX environment.

Another question would be, how is your security set up? Is it through
AIX or something else? If the security relies on netwrok connectivity
is there a possibility that a network glitch could temporarily affect
the start up ID's ability to authenticate a user? Which would explain
why a second connection attempt might be successful if the network was
available again, or would be unsuccessful with the error shown if the
network was still not available.

HTH,
klh

shorti wrote:

Hello,

I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:

SQL30082N Attempt to establish connection failed with security reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001

SQLSTATE 08001: The application requester is unable to establish the
connection.

Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the security
error is described by the <reason-codeand corresponding
<reason-stringvalue.

19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.

For one, we have no 'remote' database. The database is local...so why
this error? Second, the userid seems valid in all other cases.

Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.

I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.

Any ideas?

I am running v8.2 on AIX 5.3.

Thanks!

[shorti]

Thanks,

No...all processes are local. No networking involved. The only other
security would be the normal instance userid/psword. All of these
particular processes are already (previously) authenticated and
connected. They have application IDs and have already obtained a
context. They seem to be running along, doing reads and updates, then
suddenly an open cursor or fetch will fail with a -1024. This is
after, only milleseconds before, it did a successful read or update.

Like I said earlier, most attempts to reconnect are successful (maybe
99%) but once in a while a -30082 will come up after an attempt to
reconnect.

I was thinking we might have some configuration too low but Im not sure
what to look at. I would think that if it was a db2 config we would
spit out a different sql code (like exceeded maxagents or something
similar) but no other error is seen. We are dumping AIX and DB2 config
info after we hit an error but I dont see anything that looks like it
may cause a problem. I have checked things like the number of agents
and number of processes up at the time of the error.

Are there times that DB2 would disable or suddenly restrict the userid?
Is the description on the -30082 regarding "connect to remote
database" incorrect or is DB2 confused (or are we confusing db2 in some
way)?

klh wrote:

We've had similar issues in the Windows environment. Usually it
relates to the ID that is used to start up the instance. This ID has
to have permissions to be able to authenticate the user when a
connection attempt is made.

For us we were having the issue whenever a "group policy" change was
made that took away some of the inherent rights that the start up ID
needs. In the Windows environment these are things like "replace a
token level process", "run as a batch job", etc. I don't know what
they'd be in an AIX environment.

Another question would be, how is your security set up? Is it through
AIX or something else? If the security relies on netwrok connectivity
is there a possibility that a network glitch could temporarily affect
the start up ID's ability to authenticate a user? Which would explain
why a second connection attempt might be successful if the network was
available again, or would be unsuccessful with the error shown if the
network was still not available.

HTH,
klh

shorti wrote:

Hello,

I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:

SQL30082N Attempt to establish connection failed with security reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001

SQLSTATE 08001: The application requester is unable to establish the
connection.

Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the security
error is described by the <reason-codeand corresponding
<reason-stringvalue.

19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.

For one, we have no 'remote' database. The database is local...so why
this error? Second, the userid seems valid in all other cases.

Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.

I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.

Any ideas?

I am running v8.2 on AIX 5.3.

Thanks!

[klh]

Do you have any kind of "thread time out" limits in effect? Or are you
using the db2 governor to restrict the amount of cpu time a thread
could get? If you do, it might explain why a thread might all of a
sudden not be connected to a database. However, that doesn't really
explain why you wouldn't immediately get reconnected.

klh
shorti wrote:

Thanks,

No...all processes are local. No networking involved. The only other
security would be the normal instance userid/psword. All of these
particular processes are already (previously) authenticated and
connected. They have application IDs and have already obtained a
context. They seem to be running along, doing reads and updates, then
suddenly an open cursor or fetch will fail with a -1024. This is
after, only milleseconds before, it did a successful read or update.

Like I said earlier, most attempts to reconnect are successful (maybe
99%) but once in a while a -30082 will come up after an attempt to
reconnect.

I was thinking we might have some configuration too low but Im not sure
what to look at. I would think that if it was a db2 config we would
spit out a different sql code (like exceeded maxagents or something
similar) but no other error is seen. We are dumping AIX and DB2 config
info after we hit an error but I dont see anything that looks like it
may cause a problem. I have checked things like the number of agents
and number of processes up at the time of the error.

Are there times that DB2 would disable or suddenly restrict the userid?
Is the description on the -30082 regarding "connect to remote
database" incorrect or is DB2 confused (or are we confusing db2 in some
way)?

klh wrote:

We've had similar issues in the Windows environment. Usually it
relates to the ID that is used to start up the instance. This ID has
to have permissions to be able to authenticate the user when a
connection attempt is made.

For us we were having the issue whenever a "group policy" change was
made that took away some of the inherent rights that the start up ID
needs. In the Windows environment these are things like "replace a
token level process", "run as a batch job", etc. I don't know what
they'd be in an AIX environment.

Another question would be, how is your security set up? Is it through
AIX or something else? If the security relies on netwrok connectivity
is there a possibility that a network glitch could temporarily affect
the start up ID's ability to authenticate a user? Which would explain
why a second connection attempt might be successful if the network was
available again, or would be unsuccessful with the error shown if the
network was still not available.

HTH,
klh

shorti wrote:

Hello,
>
I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:
>
SQL30082N Attempt to establish connection failed with security reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001
>
SQLSTATE 08001: The application requester is unable to establish the
connection.
>
Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the security
error is described by the <reason-codeand corresponding
<reason-stringvalue.
>
19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.
>
For one, we have no 'remote' database. The database is local...so why
this error? Second, the userid seems valid in all other cases.
>
Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.
>
I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.
>
Any ideas?
>
I am running v8.2 on AIX 5.3.
>
Thanks!

[Knokmans]

Don't know if this problem is EXACTLY the same like we had (we also
sometimes were not able to login in DB2), but you might try this:

db2set DB2_NUM_CKPW_DAEMONS=0
and then restart the instance

It worked at our machines also running DB2 on AIX5.3
Problem is "specially" for AIX5.3, does not occur on e.g. AIX5.2

Knokmans

"klh" <kh******@yahoo.comwrote in message
news:11********************@b28g2000cwb.googlegrou ps.com...

Do you have any kind of "thread time out" limits in effect? Or are you
using the db2 governor to restrict the amount of cpu time a thread
could get? If you do, it might explain why a thread might all of a
sudden not be connected to a database. However, that doesn't really
explain why you wouldn't immediately get reconnected.

klh
shorti wrote:

>Thanks,

No...all processes are local. No networking involved. The only other
security would be the normal instance userid/psword. All of these
particular processes are already (previously) authenticated and
connected. They have application IDs and have already obtained a
context. They seem to be running along, doing reads and updates, then
suddenly an open cursor or fetch will fail with a -1024. This is
after, only milleseconds before, it did a successful read or update.

Like I said earlier, most attempts to reconnect are successful (maybe
99%) but once in a while a -30082 will come up after an attempt to
reconnect.

I was thinking we might have some configuration too low but Im not sure
what to look at. I would think that if it was a db2 config we would
spit out a different sql code (like exceeded maxagents or something
similar) but no other error is seen. We are dumping AIX and DB2 config
info after we hit an error but I dont see anything that looks like it
may cause a problem. I have checked things like the number of agents
and number of processes up at the time of the error.

Are there times that DB2 would disable or suddenly restrict the userid?
Is the description on the -30082 regarding "connect to remote
database" incorrect or is DB2 confused (or are we confusing db2 in some
way)?

klh wrote:

We've had similar issues in the Windows environment. Usually it
relates to the ID that is used to start up the instance. This ID has
to have permissions to be able to authenticate the user when a
connection attempt is made.

For us we were having the issue whenever a "group policy" change was
made that took away some of the inherent rights that the start up ID
needs. In the Windows environment these are things like "replace a
token level process", "run as a batch job", etc. I don't know what
they'd be in an AIX environment.

Another question would be, how is your security set up? Is it through
AIX or something else? If the security relies on netwrok connectivity
is there a possibility that a network glitch could temporarily affect
the start up ID's ability to authenticate a user? Which would explain
why a second connection attempt might be successful if the network was
available again, or would be unsuccessful with the error shown if the
network was still not available.

HTH,
klh

shorti wrote:
Hello,

I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why
this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:

SQL30082N Attempt to establish connection failed with security
reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001

SQLSTATE 08001: The application requester is unable to establish the
connection.

Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the
security
error is described by the <reason-codeand corresponding
<reason-stringvalue.

19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.

For one, we have no 'remote' database. The database is local...so
why
this error? Second, the userid seems valid in all other cases.

Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.

I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.

Any ideas?

I am running v8.2 on AIX 5.3.

Thanks!

[shorti]

Ok..will look into the DB2_NUM_CKPW_DAEMONS but if this only occurs
when first trying to log in then it would not be the same. We are
already in but some threads seem to suddenly lose connection and are
refused reconnect. We are currently looking into why we lose
connection sometimes in the first place but not being able to reconnect
is puzzling especially since it seems that maybe db2 is disabling the
userid. The db2diag log does show an error stating :

2006-08-01-11.32.09.047259+000 I171143C249 LEVEL: Severe
PID : 131404 TID : 1
FUNCTION: DB2 Common, Security, Users and Groups, secLogMessage,
probe:20
DATA #1 : String, 44 bytes
check password failed with rc = -2146500316

The timestamp, however occurs half a second AFTER the -1024/-30082
error so I was thinking it is a result of the problem and maybe not the
cause. Also, the PID 131404 is not the same process ID that originally
received the -1024/-30082 error. Does the " FUNCTION: DB2 Common,
Security, Users and Groups, secLogMessage, probe:20" give an indication
on who received this error?

Last, no thread timeout that would be affect this and there doesnt seem
to be any long hangs that would trigger a mutex timer for the threads
that are getting the connect error.

Knokmans wrote:

Don't know if this problem is EXACTLY the same like we had (we also
sometimes were not able to login in DB2), but you might try this:

db2set DB2_NUM_CKPW_DAEMONS=0
and then restart the instance

It worked at our machines also running DB2 on AIX5.3
Problem is "specially" for AIX5.3, does not occur on e.g. AIX5.2

Knokmans

"klh" <kh******@yahoo.comwrote in message
news:11********************@b28g2000cwb.googlegrou ps.com...

Do you have any kind of "thread time out" limits in effect? Or are you
using the db2 governor to restrict the amount of cpu time a thread
could get? If you do, it might explain why a thread might all of a
sudden not be connected to a database. However, that doesn't really
explain why you wouldn't immediately get reconnected.

klh
shorti wrote:

Thanks,

No...all processes are local. No networking involved. The only other
security would be the normal instance userid/psword. All of these
particular processes are already (previously) authenticated and
connected. They have application IDs and have already obtained a
context. They seem to be running along, doing reads and updates, then
suddenly an open cursor or fetch will fail with a -1024. This is
after, only milleseconds before, it did a successful read or update.

Like I said earlier, most attempts to reconnect are successful (maybe
99%) but once in a while a -30082 will come up after an attempt to
reconnect.

I was thinking we might have some configuration too low but Im not sure
what to look at. I would think that if it was a db2 config we would
spit out a different sql code (like exceeded maxagents or something
similar) but no other error is seen. We are dumping AIX and DB2 config
info after we hit an error but I dont see anything that looks like it
may cause a problem. I have checked things like the number of agents
and number of processes up at the time of the error.

Are there times that DB2 would disable or suddenly restrict the userid?
Is the description on the -30082 regarding "connect to remote
database" incorrect or is DB2 confused (or are we confusing db2 in some
way)?

klh wrote:
We've had similar issues in the Windows environment. Usually it
relates to the ID that is used to start up the instance. This ID has
to have permissions to be able to authenticate the user when a
connection attempt is made.

For us we were having the issue whenever a "group policy" change was
made that took away some of the inherent rights that the start up ID
needs. In the Windows environment these are things like "replace a
token level process", "run as a batch job", etc. I don't know what
they'd be in an AIX environment.

Another question would be, how is your security set up? Is it through
AIX or something else? If the security relies on netwrok connectivity
is there a possibility that a network glitch could temporarily affect
the start up ID's ability to authenticate a user? Which would explain
why a second connection attempt might be successful if the network was
available again, or would be unsuccessful with the error shown if the
network was still not available.

HTH,
klh

shorti wrote:
Hello,
>
I was wondering if anyone knows why this error is occurring. Every
once in a while I will get an sql -1024 (we are looking in to why
this
occurs in the first place). I automatically do a DB2 CONNECT and it
reconnects without a problem. Occasionally, however, the reconnect
will fail with an sql -30082 with reason code 19. This error doesnt
make sense since the description says:
>
SQL30082N Attempt to establish connection failed with security
reason
"19"
("USERID DISABLED or RESTRICTED"). SQLSTATE=08001
>
SQLSTATE 08001: The application requester is unable to establish the
connection.
>
Explanation:
The attempt to connect to the remote database server was rejected due
to invalid or incorrect security information. The cause of the
security
error is described by the <reason-codeand corresponding
<reason-stringvalue.
>
19 (USERID DISABLED or RESTRICTED)
The userid has been disabled, or the userid has been restricted from
accessing the operating environment at this time.
>
For one, we have no 'remote' database. The database is local...so
why
this error? Second, the userid seems valid in all other cases.
>
Since the userid seems to work other times, I would assume it is
somehow being 'disabled'.
>
I noticed other database activities going on after this without a
problem (this is a multi-process/multi-threaded environment) so it
leads me to believe we are not having a true database connection
issue...maybe something going on with the calling process.
>
Any ideas?
>
I am running v8.2 on AIX 5.3.
>
Thanks!