By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,609 Members | 2,246 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,609 IT Pros & Developers. It's quick & easy.

db2icrt on Debian Sarge fails

P: n/a
Hi.

I am trying to get db2 PE up and running on Debian Sarge. I have installed
all rpms using alien. I added the licence and I can create the das, but if
I try to create an instance with

/opt/IBM/db2/V8.1/instance/db2icrt -d -u db2run1 db2inst1

and the log file in /tmp tells me

## call function updt_dbmcfg
Program name = db2idbm
Instance home dir = /var/db2/inst1, Sysadm group = db2inst
Instance type = 6, Auth type = SERVER

SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
Update DBM cfg SYSADM_GROUP errcode = 8
DBI1281E Die Konfigurationsdatei des Datenbankmanagers konnte
nicht initialisiert werden.

I have double checked the groups and directory permission, looks OK. How
can I find out, what -1390, Reason code: "3" and errcode 8 mean?

Any hints what is going on?

Thanx,
Joachim

Nov 12 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
On Thu, 15 Sep 2005 21:29:08 +0200, Joachim Zobel wrote:

SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
Update DBM cfg SYSADM_GROUP errcode = 8 DBI1281E Die Konfigurationsdatei
des Datenbankmanagers konnte
nicht initialisiert werden.


I have tracked down, that the command that fails is actually

db2 update database manager configuration using SYSADM_GROUP ${SysAdmGrp?}

but I am still searching for docs on code 3 et al.

Sincerely,
Joachim

Nov 12 '05 #2

P: n/a
Joachim Zobel wrote:
Hi.

I am trying to get db2 PE up and running on Debian Sarge. I have installed
all rpms using alien. I added the licence and I can create the das, but if
I try to create an instance with

/opt/IBM/db2/V8.1/instance/db2icrt -d -u db2run1 db2inst1

and the log file in /tmp tells me

## call function updt_dbmcfg
Program name = db2idbm
Instance home dir = /var/db2/inst1, Sysadm group = db2inst
Instance type = 6, Auth type = SERVER

SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
Update DBM cfg SYSADM_GROUP errcode = 8
DBI1281E Die Konfigurationsdatei des Datenbankmanagers konnte
nicht initialisiert werden.

I have double checked the groups and directory permission, looks OK. How
can I find out, what -1390, Reason code: "3" and errcode 8 mean?

Any hints what is going on?


Unfortunately, there are a number of environment issues that could give you
this error. And, even worse, you're on an officially unsupported platform,
which makes it really difficult to get IBM to look at it.

That said, message -1390 is "DB2INSTANCE not set or undefined." Without
that variable, DB2 can't figure out how to load the German version of the
message, and then throws an SQL10007 message up (in English, of course).
Unfortunately, DB2INSTANCE is set during db2icrt, which points to a deeper
environment problem.

If you were to have this problem on a supported platform, I'd suggest
calling IBM support.

If you haven't installed the latest fixpack (FP10, I believe), that may
help. Of course, you're going to have to do that manually, as well, since
DB2 doesn't support alien directly.

Good luck,
Nov 12 '05 #3

P: n/a
Joachim Zobel wrote:
Hi.

I am trying to get db2 PE up and running on Debian Sarge. I have installed
all rpms using alien. I added the licence and I can create the das, but if
I try to create an instance with

/opt/IBM/db2/V8.1/instance/db2icrt -d -u db2run1 db2inst1

and the log file in /tmp tells me

## call function updt_dbmcfg
Program name = db2idbm
Instance home dir = /var/db2/inst1, Sysadm group = db2inst
Instance type = 6, Auth type = SERVER

SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
Update DBM cfg SYSADM_GROUP errcode = 8
DBI1281E Die Konfigurationsdatei des Datenbankmanagers konnte
nicht initialisiert werden.

I have double checked the groups and directory permission, looks OK. How
can I find out, what -1390, Reason code: "3" and errcode 8 mean?

Any hints what is going on?

Thanx,
Joachim


Joachim,

I wrote an article on doing this for IDUG Solutions Journal in 2003.
Unfortunately the ISJ part of the IDUG website is "undergoing maintenance"
at the moment, so I can't give you an online link to the article.

But I should have a copy lying about on my hard drive somewhere, if you want
to email me offlist (teamdbaATNOSPAMscotdb.com).

One thing I do recall is that there are different packages for the various
language files, and you may have issues with these.

I do know that I had DB2 running for a long while on Debian Sid, so it
should be possible.

Phil
Nov 12 '05 #4

P: n/a
On Fri, 16 Sep 2005 03:20:29 +0000, Darin McBride wrote:
Unfortunately, there are a number of environment issues that could give
you this error. And, even worse, you're on an officially unsupported
platform, which makes it really difficult to get IBM to look at it.
I am doing this on my laptop (not a production system :), since I want to
try out the WITH clause and learn about db2 in general.
That said, message -1390 is "DB2INSTANCE not set or undefined." Without
that variable, DB2 can't figure out how to load the German version of
the message, and then throws an SQL10007 message up (in English, of
course). Unfortunately, DB2INSTANCE is set during db2icrt, which points
to a deeper environment problem.


This is weird. The script is doing:

#-----------------------------------------------------------------------
# Set the environment for the instance we are running as.
#-----------------------------------------------------------------------
set_instenv

#-----------------------------------------------------------------------
# Update the database manager configuration file to set SYSADM_GROUP to
# the specified group. Check for SQL6031N message.
#-----------------------------------------------------------------------
errmsg=`db2 update database manager configuration using SYSADM_GROUP ${SysAdmGrp?} 2>&1 `

and set_instenv looks as if it can not fail, at least if the instance name
is passed correctly. And using -d tells me it is passed.

Calling db2 manually gives the same error, even if I do an export
DB2INSTANCE=db2inst before. So -1390 seems to be used as a general "Uh,
there is no instance" error.

Probably I am not fully groking the IBM spirit yet.

Sincerely,
Joachim

Nov 12 '05 #5

P: n/a
Joachim Zobel wrote:
On Fri, 16 Sep 2005 03:20:29 +0000, Darin McBride wrote:
Unfortunately, there are a number of environment issues that could give
you this error. And, even worse, you're on an officially unsupported
platform, which makes it really difficult to get IBM to look at it.
I am doing this on my laptop (not a production system :), since I want to
try out the WITH clause and learn about db2 in general.


I'm hoping to try DB2 out on my gentoo box, too, but I'm not that
adventurous yet ;-)
That said, message -1390 is "DB2INSTANCE not set or undefined." Without
that variable, DB2 can't figure out how to load the German version of
the message, and then throws an SQL10007 message up (in English, of
course). Unfortunately, DB2INSTANCE is set during db2icrt, which points
to a deeper environment problem.


This is weird. The script is doing:

#-----------------------------------------------------------------------
# Set the environment for the instance we are running as.
#-----------------------------------------------------------------------
set_instenv

#-----------------------------------------------------------------------
# Update the database manager configuration file to set SYSADM_GROUP to
# the specified group. Check for SQL6031N message.
#-----------------------------------------------------------------------
errmsg=`db2 update database manager configuration using SYSADM_GROUP
${SysAdmGrp?} 2>&1 `

and set_instenv looks as if it can not fail, at least if the instance name
is passed correctly. And using -d tells me it is passed.


Right - DB2INSTANCE *is* set. Thus, the problem is actually deeper than
that. Usually, this is related to improper permissions to the home
directory, a directory above the home
directory, /etc/services, /usr, /usr/bin, /bin, ... it's not really
entirely clear to me.
Calling db2 manually gives the same error, even if I do an export
DB2INSTANCE=db2inst before. So -1390 seems to be used as a general "Uh,
there is no instance" error.


As long as you're playing with the scripts at all, you could go into the
script where it calls db2idbm, and just forcefully set rc=0 afterwards. It
will proceed to completion, but the instance's dbm cfg won't be set up
properly. And you'll probably still get the same error should you try -
but at least you'll have an instance. Not a very useful instance, mind
you... ;-) There may be more detail left in ~/sqllib/db2dump/db2diag.log

Let's see ...

/etc/passwd

* Check to make sure there is no # or blank lines in it.

# Make sure you use '-' when doing the 'su'. Ex: "su - db2inst1"
# Make sure the machine name is listed in its hosts file.
# Make sure to log on directly to root. ie: do not su to root from another
user. (su - may be ok.)
# Make sure there is no instance created already (find / -name sqllib)
# Check that the instance password has not expired
# Make sure the name of the instance is not too long.
# Check that defaults were not changed to disallow group and others to write
to /dev/null
* -> set the /dev/null permissions to crw-rw-rw-

(This is just based on problems others have had getting this error.)
Nov 12 '05 #6

P: n/a
On Fri, 16 Sep 2005 19:09:25 +0000, Darin McBride wrote:
As long as you're playing with the scripts at all, you could go into the
script where it calls db2idbm, and just forcefully set rc=0 afterwards.
It will proceed to completion, but the instance's dbm cfg won't be set up
properly. And you'll probably still get the same error should you try -
but at least you'll have an instance. Not a very useful instance, mind
you... ;-) There may be more detail left in ~/sqllib/db2dump/db2diag.log

Let's see ...


I did this so I could play around to find out why db2 did not work. This
is what I found.

db2inst1@asus:~$ export LANG=de_DE.utf8
db2inst1@asus:~$ db2 update database manager configuration using
SYSADM_GROUP db2inst DB20000I
Der Befehl UPDATE DATABASE MANAGER CONFIGURATION wurde erfolgreich
ausgeführt.

So it is some NLS stuff. I will do further research.

Sincerely,
Joachim

Nov 12 '05 #7

P: n/a

How is the language set for a db2 installation- I remember that to get
german messages I symlinked some de_DE file. This was probably not the
correct way to do this. How is ist done?

Thx,
Joachim
Nov 12 '05 #8

P: n/a
Joachim Zobel wrote:
How is the language set for a db2 installation- I remember that to get
german messages I symlinked some de_DE file. This was probably not the
correct way to do this. How is ist done?


Installation or instance? To run the db2setup wizard in German, you can
either set your LANG to some value that DB2 recognises as German, which
probably includes "de_DE", "de_DE.utf8", and possibly even "Deutsch" (I'm
probably not spelling that last one correctly) or, oddly enough,
"German"... or you can pass in a "-i de" parameter to db2setup.

For the instance part of the question, whether that's instance management
(db2icrt, db2iupdt, etc.) or using an instance (db2 udpate dbm cfg, db2
select, db2cc, etc.), only the LANG setting is used.

You should not need to create any symlinks. DB2 v8 is smart enough to map
your LANG setting to the internal form that DB2 uses.
Nov 12 '05 #9

P: n/a
Joachim Zobel wrote:
On Fri, 16 Sep 2005 19:09:25 +0000, Darin McBride wrote:
As long as you're playing with the scripts at all, you could go into the
script where it calls db2idbm, and just forcefully set rc=0 afterwards.
It will proceed to completion, but the instance's dbm cfg won't be set up
properly. And you'll probably still get the same error should you try -
but at least you'll have an instance. Not a very useful instance, mind
you... ;-) There may be more detail left in ~/sqllib/db2dump/db2diag.log

Let's see ...


I did this so I could play around to find out why db2 did not work. This
is what I found.

db2inst1@asus:~$ export LANG=de_DE.utf8
db2inst1@asus:~$ db2 update database manager configuration using
SYSADM_GROUP db2inst DB20000I
Der Befehl UPDATE DATABASE MANAGER CONFIGURATION wurde erfolgreich
ausgeführt.

So it is some NLS stuff. I will do further research.


I'm not sure that you have enough evidence here to tell me it's NLS stuff -
if you set your LANG to C or en_US, does it magically start working? I
doubt it has anything to do with your language.

Nov 12 '05 #10

P: n/a
On Sun, 18 Sep 2005 16:18:48 +0000, Darin McBride wrote:
Joachim Zobel wrote:
On Fri, 16 Sep 2005 19:09:25 +0000, Darin McBride wrote:
As long as you're playing with the scripts at all, you could go into
the script where it calls db2idbm, and just forcefully set rc=0
afterwards. It will proceed to completion, but the instance's dbm cfg
won't be set up properly. And you'll probably still get the same error
should you try - but at least you'll have an instance. Not a very
useful instance, mind you... ;-) There may be more detail left in
~/sqllib/db2dump/db2diag.log

Let's see ...


I did this so I could play around to find out why db2 did not work. This
is what I found.

db2inst1@asus:~$ export LANG=de_DE.utf8 db2inst1@asus:~$ db2 update
database manager configuration using SYSADM_GROUP db2inst DB20000I
Der Befehl UPDATE DATABASE MANAGER CONFIGURATION wurde erfolgreich
ausgeführt.

So it is some NLS stuff. I will do further research.


I'm not sure that you have enough evidence here to tell me it's NLS stuff
- if you set your LANG to C or en_US, does it magically start working? I
doubt it has anything to do with your language.


DBI1070I Das Programm db2icrt wurde erfolgreich
beendet.

As tradition requires, I do the engineers victory dance.

It is not exactly NLS stuff, but LANG has to be set. I realized that much
earlier and set LANG for root. However the stuff that failed (db2idbm) is
executed as the instance user (db2inst1). The LANG enviroment variable has
to be set for this user too, that is what was missing.

Thanx,
Joachim

Nov 12 '05 #11

P: n/a
I'm glad to hear you got it working, but I find this requirement for
LANG to be set very strange -- it does not match with my own
experiences.

I wrote the Gentoo install instructions in the DB2 HOWTO
(http://tldp.org/HOWTO/DB2-HOWTO/index.html), run DB2 on Gentoo at
home, gave the PHP developer who created and tested the PHP driver for
PHP Data Objects (PDO) that supports DB2 (PDO_ODBC driver) an account
on my Gentoo box where he successfully built and tested the driver
against DB2... all without ever setting LANG.

Just to confirm that LANG is not set, when I run the locale command, I
get:

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

So, unless it just happens to work for me because I installed only the
English messages (always a possibility in this anglo-centric world), I
suspect there is some other force at work in your environment.
Personally, I strongly suggest running

.. /home/db2inst1/sqllib/db2profile

to set your environment rather than trying to manually set individual
environment variables.

An aside to Darin -- shame on you for being too unadventurous to
install DB2 on your Gentoo box! The HOWTO has documented it for almost
8 months now... get with the times, man! :)

Dan

Nov 12 '05 #12

P: n/a
Dan Scott wrote:
I'm glad to hear you got it working, but I find this requirement for
LANG to be set very strange -- it does not match with my own
experiences.
Actually, my understanding of Joachim's remarks was that he /reset/ LANG, as
in, LANG is normally set for him to be German, so by changing LANG to
English, he got it working. Which also does not match my own experiences -
db2icrt should work in any language.
I wrote the Gentoo install instructions in the DB2 HOWTO
(http://tldp.org/HOWTO/DB2-HOWTO/index.html), run DB2 on Gentoo at
Hmmm - you haven't been keeping me up to date with your changes... ;-)
An aside to Darin -- shame on you for being too unadventurous to
install DB2 on your Gentoo box! The HOWTO has documented it for almost
8 months now... get with the times, man! :)


One step at a time, my good sir. I'm just happy I've managed to get Gentoo
working to the point that I can do what I need with it: VPN (you do know
that Gentoo is not an officially supported distribution for the Cisco VPN
server, right?), vnc (the latest tightvnc client doesn't agree with the
tightvnc server that comes with SLES, so I had to downgrade here), rdesktop
(never got Notes running under Wine, though I admit to not trying very
hard ;->), sametime, and basically anything else I need to get my job done
and/or anything I need to enjoy having this piece of equipment in my home
(email, postfix, etc.). Interestingly, DB2 isn't one of these. ;-)

I do hope to install Viper on this box when it comes out. I think Viper
will be much more gentoo-friendly. ;-)

Nov 12 '05 #13

P: n/a
On Wed, 21 Sep 2005 01:23:14 +0000, Darin McBride wrote:
Dan Scott wrote:
I'm glad to hear you got it working, but I find this requirement for
LANG to be set very strange -- it does not match with my own
experiences.


Actually, my understanding of Joachim's remarks was that he /reset/ LANG,
as in, LANG is normally set for him to be German, so by changing LANG to
English, he got it working. Which also does not match my own experiences
- db2icrt should work in any language.


No, on my box, there is no LANG in the profile, if I do not explicitely
set it:

ike@asus:~$ env | grep LANG
ike@asus:~$

Sincerely,
Joachim

Nov 12 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.