Wednesday, 14 July 2010

GLPCTL010E Failed to start database manager for database instance: 'dsrdbm01'

Having managed to locate the right 32-bit version of Tivoli Directory Server 6.2, I then found that the installation barfed with: -

(Jul 14, 2010 3:05:51 PM), null, com.ibm.ldap.install.beans.PanelDefaultInstancePanel$NullWriterDefinst, dbg, line read from idsdefinst script is GLPCTL010E Failed to start database manager for database instance: 'dsrdbm01'.

I'd previously installed DB2 UDB 9.1.0.9: -

DB21085I  Instance "dsrdbm01" uses "32" bits and DB2 code release "SQL09019"
with level identifier "020A0107".
Informational tokens are "DB2 v9.1.0.9", "s100326", "MI00323", and Fix Pack "9".
Product is installed at "/opt/ibm/db2/V9.1".

and, more importantly, had allowed the DB2 installer to create a default instance ( db2inst1 ) and was able to start/stop DB2, create the sample database ( db2sampl ) etc. so I knew that DB2 was OK.

However, the fact that I'd created an instance turned out to be the problem - looking at this Technote: -

DB2 V9.1 FP5+ is now supported with Tivoli Directory Server V6.x

http://www-01.ibm.com/support/docview.wss?rs=767&uid=swg21314966

I quickly realised that the db2inst1 instance was the default, meaning that the TDS installer was seeing a conflict as I was trying to start the new dsrdbm01 instance.

The solution was simple - from the shell in which I was running the TDS configuration tool ( /opt/IBM/ldap/V6.2/sbin/idsxcfg ), I needed to set the DB2INSTANCE variable BEFORE running the configuration tool: -

export DB2INSTANCE=dsrdbm01
/opt/IBM/ldap/V6.2/sbin/idsxcfg

This then allowed me to configure/create/start the DB2 instance, and carry on with the rest of the TDS installation.

Easy when you know how ....

No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...