Error STU00104 for BOXI 3.1 installation on AIX server with DB2 v8.2

[Former Member]

Hi All,

I am getting the following error after I enter the DB2 database and user ID for the BO CMS Repository

Failure to validate the database credential has a potential to crash the database at a later stage. Enter the correct information. (STU00104)

I have verified that the remote DB2 database can be connected and has been cataloged locally on the BOXI server. Also have tried creating user temporary table spaces with 4k and 8k pages, but still encounter the error. I have ensured that the database credentials are correct. Is there anyway to get a descriptive log for the main cause of this error?

Any inputs to help resolve the issue are appreciated,

Thanks

[former_member142702 · Accepted solution]

Is this 64bit AIX?

Regards,

Stratos

[Former Member · Accepted solution]

Yes, AIX 5.3 64 bit and DB2 v8 FP18 64 bit database instance too.

[former_member142702 · Accepted solution]

Make sure that BOBJ uses the 32bit DB2 driver to access the repository database. You can do this by adding the path to the 32bit libraries into the LIBPATH variable for the user that runs the BOBJ services.

Regards,

Stratos

[Former Member · Accepted solution]

Would like to highlight that the BOXI server DB2 client is 32 bit, whereas the remote DB2 database instance is a 64 bit instance. Could there be a compatibility issue? Haven't found any compatibility related text in the installation guide though.

Currently the LIBPATH points to the DB2 32 bit libraries on the BOXI server. I tried with exporting both the 32 bit & 64 bit DB2 libraries in the LIBPATH env variable, but still getting the same error.

[former_member142702 · Accepted solution]

Hi

I have such a configuration working in one of my customers. Still if you want to get an official statement about the usage of 32bit drivers with a 64bit database I would recommend to contatc IBM itself.

Have you tried if the conection works (DB2 connect) when you login on your AIX server with your BOBJ user?

Regards,

Stratos

[Former Member · Accepted solution]

Yes. I have been able to connect to the remote DB2 instance from the BOXI server. DB2 can connect and perform all required operations / SQLs remotely from a 32 bit client to a 64 bit database instance.

[former_member142702 · Accepted solution]

Can you confirm that a USER TEMPORARY tablespace with more than 4K page size not just a TEMPORARY tablespace exists and that the user you use for the DB connection is able to acces it?

You can for example try to create a temporary user table using the DB2 client on your BOBJ server.

Regards,

Stratos

[Former Member · Accepted solution]

Thanks Stratos .. some headway in the installation.

Ensured that the user temporary tablespaces "USE" privilege is granted to the BOXI admin user. So the CMS database selection went ahead without further hiccups.

However, got the same error with the audit database in the next section. I've ensured the tablespace privileges this time around for the audit database, which is again a DB2 database. FYI ... using the same BOXI admin id credentials for the audit database.

[Former Member · Accepted solution]

Was able to install in custom mode by skipping the audit database part. Also updated the DB2 client to FP18 to avoid any compatability issues. Will configure the audit database later, once the BOXI setup is up.

However, after starting the CMS and checking getting following error:

./ccm.sh -display -cms

Creating session manager...

Logging onto CMS...

err: ERROR Couldn't logon to CMS (STU00152)

err: Error description: Enterprise authentication could not log you on. Please make sure your logon information is correct. (FWB 00008)

Edited by: Dedy Sodikin on May 4, 2010 3:54 PM

[former_member142702 · Accepted solution]

Start the SIA (./ccm.sh -start sia) and try to login over the InfoView as Administrator with the password you have provided during the installation.

Regards,

Stratos

[Former Member · Accepted solution]

Managed to verify the CMS service is up and running with explicitly mentioning the administrator user name and password

./ccm.sh -display -cms <hostname>:<port> -username <username> -password <pwd>