Removing temporary data : -When installing Maximo Base Services 7.5 or Base Services Fixpack 7.1 you get an error: CTGIN2489E.

Removing temporary data

If you have modified the Maximo database since you installed another product or component, make sure all of your changes are completed before you begin a new upgrade or installation procedure.

All changes must be committed to the database before you can upgrade an existing product or install a new product or component. Tables whose names begin with "XX" are temporary tables that must be dropped before installing. If these tables exist, you will see error CTGIN2489E when you run an upgrade or installation procedure.

Temporary data can exist in your database in these situations:

• You are upgrading an existing product after configuring and using it.
• You are installing a new product or component in an environment where you have already installed another product, and configured and used that product.
• You are using the installer to add a feature or function that you did not implement when you first installed your product.

If you are in one of these situations, check whether you have any uncommitted changes or temporary tables in your database.

1. To confirm that all changes have been committed, run the following SQL query against the Maximo database:

   SELECT count(*) from maxobjectcfg where changed != 'N'

   'N' indicates that a change has been committed. For this query, if entries are returned with a value of 0 instead of N, you must commit those changes. Follow these steps to commit the changes:
   1. Click Go To > System Configuration > Platform Configuration > Database Configuration.
   2. From the Select Action menu, click Manage Admin Mode.
   3. Click Turn Admin Mode ON.
   4. Click OK, then wait for a few minutes for the change to take effect.
   5. From the Select Action menu, click Apply Configuration Changes. Monitor the process to completion.
   6. From the Select Action menu, click Manage Admin Mode.
   7. Click Turn Admin Mode OFF.
   8. Stop the MXServer.
   9. On the administrative Workstation, open a command prompt. Change to the directory c:\ibm\smp\maximo\tools\maximo.
   10. Run the following commands:

       configdb.bat
       dropbackup.bat
       dropbackup.bat

       The dropbackup.bat command is run twice. This should complete the commitment of all database changes.
2. Determine whether any temporary tables exist in your database, using the command appropriate to your database:

   DB2®

   select count(*) from sysibm.systables where name like 'XX%' and 
   creator = 'MAXIMO'

   Microsoft SQL Server

   SELECT count(*) FROM sysobjects WHERE xtype = 'U' AND name like 'XX%'

   Oracle

   SELECT count(*) from all_tables where table_name like 'XX%'

   If the returned value is not 0, follow these steps to drop the temporary tables:
   1. On the administrative Workstation, open a command prompt. Change to the directory c:\ibm\smp\maximo\tools\maximo.
   2. Run the following commands:

      configdb.bat
      restorefrombackup.bat
      dropbackup.bat
      dropbackup.bat 

      The dropbackup.bat command is run twice. This should drop all the temporary tables in the database.

Now you can proceed with your upgrade or installation procedure.

Integrity Checker reports BMXAA0494E errors on table COMMLOG.

Problem

After upgrading a Maximo 6.2 database to 7.1, several columns on table COMMLOG do not match the way that the columns are defined in Maximo.

Issue

In Integrity Checker report:
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.BCC, Maximo definition is CLOB, Database column is VARCHAR2(4000)
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.CC, Maximo definition is CLOB, Database column is VARCHAR2(4000)
BMXAA0443E -- ERROR -- BMXAA0494E -- The Maximo definition of this column does not match the actual column:
BMXAA6841I - COMMLOG.SENDTO, Maximo definition is CLOB, Database column is VARCHAR2(4000)

Resolving the problem

1. For each column, add to table COMMLOG a new column with data type CLOB. For example:
Alter Table commlog Add bccnew CLOB;
2. Copy the original column to the new column. For example:
Update commlog Set bccnew = bcc ;
3. Drop the original column. For example:
Alter Table commlog Drop Column bcc ;
4. Rename the new column to the original name. For example:
Alter Table commlog Rename Column bccnew To bcc ;
5. Run Integrity Checker again to verify that the errors are no longer reported.

Upgrade to Maximo 7.5 fails in UpdateDB script V7500_343.

Problem(Abstract)

When upgrading the Maximo database to 7.5.0.x, UpdateDB can fail in script V7500_343.dbc:


BMXAA7025E -- Script failed while running.;

A statement failed to execute inside a freeform statement;

sql#1407;
ORA-01407: cannot update ("INVENTORY"."COSTTYPE") to NULL

-- BEGINUPDATEDBERROR

-- Product: Tivoli's process automation engine
-- Error running file: V7500_343
-- UPDATEDBFILE:V7500_343.dbc

Symptom

The V7500_343 freeform statement that fails is:

update inventory set inventory.costtype = case
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'COSTFROMASSET' and maxvars.siteid = inventory.siteid ) = '1'
and ( select item.rotating from item where item.itemnum = inventory.itemnum and item.itemsetid = inventory.itemsetid ) = 1
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'ASSET' and synonymdomain.defaults = 1 )
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) = 'AVGCOST'
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'AVERAGE' and synonymdomain.defaults = 1 )
when ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) = 'STDCOST'
then ( select value from synonymdomain where synonymdomain.domainid = 'COSTTYPE' and synonymdomain.maxvalue = 'STANDARD' and synonymdomain.defaults = 1 )
else ( select maxvars.varvalue from maxvars where maxvars.varname = 'DEFISSUECOST' and maxvars.siteid = inventory.siteid ) end

If the Maximo database was originally built using MAXDEMO data, rows can exist in the Inventory table that do not have a valid SiteID. As UpdateDB populates new column Inventory.CostType, the invalid SiteID values prevent the script from determining values to populate CostType for these old MAXDEMO records.

Upgrade 7.1 to 7.5.

Diagnosing the problem

If this query returns any values, then your database contains Inventory records with invalid SiteIDs:

Select siteid From inventory Where siteid Not In (Select siteid From maxvars Where varname In
('COSTFROMASSET', 'DEFISSUECOST') ) ;

Resolving the problem

Since these Inventory records are old MAXDEMO data, they serve no purpose and should be removed from your database. Replace XX in the following statement with any invalid SiteID values returned from the query above:

Delete From inventory Where siteid='XX'

Restore your database to pre-upgrade 7.1, remove the bad rows from the Inventory table, and run UpdateDB over again.

Using the middleware installation program to install DB2 9.7 on a Red Hat v6 system results in an error related to missing prerequisites

Problem(Abstract)

Using the middleware installation program to install DB2 9.7 on a Red Hat v6 system results in the following error:

CTGIN9080E: libaio.so.1, libstdc++.so.5 and libstdc++.so.6 packages are
required for DB2.

This error can occur even if the prerequisite checking tool was used to verify prerequisites on the system.

Resolving the problem

The problem is solved by installing libstdc++-4.4.4-13.el6.i686.rpm

which installs /usr/lib/libstdc++.so.6 and /usr/lib/libstdc++.so.6.0.13.

Error CTGIN9053E reported when using the middleware installation program

Problem(Abstract)

When using the middleware installation program, an error similar to the following is displayed:

CTGIN9053E: The partition /data has 100618240 bytes free space, but the
deployment plan requires 1073741824 bytes free space on that partition.
Increase available space in /data.

In this scenario, the middleware installation program was launched from the /data directory, but was not selected as the destination directory for the installation.

Resolving the problem

This error occurs when the middleware installation program is started from a directory that does not include the free space required to install the middleware selected. This error will be reported even if you select a different file system to install the middleware into that does have sufficient space.

The solution to this error is to start the middleware installation program from the same partition as the default home location for users. For example, /home.

The middleware installation program crashes during the WebSphere installation step for the authentication service on Red Hat v6 platforms.

Problem(Abstract)

The middleware installation program crashes during the WebSphere installation step for the authentication service.

Symptom

The middleware installation program crashes. The following error is reported in the console window where the middleware installation program was started:

./mwi_zlinux.bin: line 1965: 13290 Killed -Djava.io.tmpdir=?/tm? -Dtemp.dir=?/tmp? -Dis.jvm.home=?/tmp/istemp/_bundlesJRE_? -Dis.jvm.tmp=?1? -Dis.media.home=?? -Dis.launcher.file=?/mwi_zlinux.bin -Dis.jvm.file=?/tmp/istmp/_bundledJRE_/jvm? -Dis.externel.home=?? run 1>&1 2>&1

Resolving the problem

1. Start the middleware installer and choose the partial undeploy option to undeploy the J2EE server.

2. Once the J2EE server (WebSphere) undeployment is successful, start the middleware installer again and proceed with the Restart the plan option.

If the middleware installer crashes again during installation of the authentication service, restart the middleware installer and proceed with the Restart the plan option, which will result in a successful deployment.