ITEM: S6664L
Can't connect to databases in db2 license problem
Problem: CALLER CAN'T CONNECT TO DATABASES IN DB2 :SQL8001N
ENV: AIX 3.2.5
DB2/6000 V1.2
Desc: This is a continuation of what was thought to be a nodelock
problem. After some effort the customer was able to get a new
nodelock and still he cannot connect to the databse. In short,
Yesterday night he could connect, now the database starts but when a
connect is issused the SQL8001n reason code -100 returns. The original
nodelock was supposed to be for an indefinite time period. I have no
idea what could be causing this since the nodelock and file seem to be
correct. I had the customer place a trace of the connect error in
testcase.boulder.ibm.com under /ps/toibm/db2/s6664.6000.trace. I have
verified that the trace is valid. There system is down at present.
As indicated in the guide, a reason code 100 indicates an "unexpected"
error has occurred. If the license itself had expires, a very different
reason code would have been displayed.
.The rc = -100 usually occurs when permissions/owners have changed
on files/directories/executeables related to the netLS licensing.
.Please verify that the permissions and owner are correct for the
db2licd and nodelock files as well as the directories leading to these
files...
Desc: The permissions and the file are fine. I went to Phil and Jeff
for further assistance. What they found was that the dblicd daemon
was not start correctly. After looking further into this they
discovered that many of the files and directories in the instance
owners subtree were screwed up.
Action: To try and restart the daemon we did the following:
$ db2stop
$ db2licd end
$ date
$ db2start
$ db2 list tables
The daemon failed to become active. This is when we checked and found
a missing sticky bit on the daemon. We reset the permissions to 4555
and started the process over getting to a sql1224n. From here we
started checking other permissions and found more errors. In an
effort to speed up the permission solutions we decided to recreate the
instance. First, we backed up the old instance:
$ cd ddsn
$ mv sqllib sqllib_old
Then recreate the instace:
\# /usr/lpp/db2_01_01_0000/instance/db2instance ddsn
Now we tried to speed up the recovery of the database by moving
significant files from the old instance back to the new after checking
the permissions to make sure they would not reintroduce the problem.
$ cp -R sqllib_old/sqldbdir/* sqllib/sqldbdir/.
$ cp -R sqllib_old/sqlnodir/* sqllib/sqlnodir/.
$ cp sqllib_old/db2system sqllib/db2system
Next we had the customer try to connect to the database. This time he
had no troubles. After running a "list tables for all" he was able to
find everything.
Next: CC
Support Line: Can't connect to databases in db2 license problem ITEM: S6664L
Dated: June 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:36
Comments or suggestions?
Contact us