Segmentation Fault while installing DB2 ESE 9.7 on RHEL

I created an RHEL 6.2 VM and started the DB2 Installation process.  However once it got going, it suddenly crashed, leaving the db2inst1 user being the only thing (apparently) created.  After a bit of searching I found the following article:

http://stackoverflow.com/questions/15270161/db2-9-7-fails-to-install-with-segmentation-fault

So the crux of the solution is that the installation process requires that the hostname is linked to the 127.0.0.1 (loopback) address.

Snapshot of the /etc/hosts file.

Once this was fixed, I deleted the existing user via system-config-users and restarted the installation process.  This time all went through successfully.

I'm working on some MDM 10.1 installation tasks so I'll likely be updating this blog again with a few of the lessons-learned.

Unresolved Proxy Error Message

I received this error message when importing projects from another location into a fresh MDM workspace:

The solution was to give the name ("MDM") to the Hub in the MDM EAR Project, then open each affected project and hit "Validate Model".  It validated with no errors and the messages went away.

Extending the Privacy Preference Entity Table

At my current client we are tasked with extending the PPREFENTITY table.   I encountered some challenges and have recorded the solutions in this article.

You can see the extended entity is the EntityPrivPref, which corresponds to the to the TCRMEntityPrivPrefBObj.  Since we are working with the TCRMPersonBObj (and thus, desire to have the extended entity privacy preference object included in the request & response for the TCRMPersonBObj), we expect the TCRMPartyPrivPrefBObj to be the working object.

I included our extended object in the request XML for TCRMPersonBObj, including the XPartyPrivPrefBObj in the TCRMExtensionBObj for TCRMPartyPrivPrefBObj, and got the following error:

DWLDocumentHandlerHelper ... com.td.mdms.extensions.component.XPersonBObjExt; method = setObject; class = com.td.mdms.extensions.component.XPartyPrivPrefBObjExt

Above is a portion of the error message.  So it turns out that the generated object is not suitable and needs to be modified.

This is the class diagram of the key classes.

We extend the Entity Privacy Pref via the workbench (middle class) but want the Party Privacy Preference (Bottom Class).

I turns out that since TCRMPartyPrivPrefBObj (desired) is a child of the extended entity, we can easily move our object to extend it.

1.  Properties files.  Change them to refer to TCRMPartyPrivPrefBObj as in the below image.

NOTE: I had to copy the properties entries to both term_extension.properties & DWLCommon_extension.properties.

2. Modify the extension class itself (*.component.* package) to extend TCRMPartyPrivPrefBObj instead of TCRMEntityPrivPrefBObj.

And that's it - rebuild, restart, republish.  You will be able to include the extended entity in your XML.  Apparently there are a number of classes that require similar intervention - generally those that utilize an "ENTITY_NAME" field such as CONTACT, etc.

Installing DB2 Express 10.1

I accidentally installed DB2 Express-C 10.1, mistakenly thinking it would work for MDM Workbench.  It will not!  Not in Workbench 10.0, at least.  However, I didn't want to dispose of the data so here is another article.

Ok, let's prepare to install DB2.  First, we must create the users.  Let's create a user, db2admin, as an Administrator.  I am assuming a basic, non-AD install (on my local network I use AD and will detail its usage in a later article).

Adding db2admin with a simple password

 Add the user to the administrators group by right-clicking the user, selecting properties, then adding to a group.  Type "Administrator" in the box and select "Check Names".  It should create something like the below image.

Adding the user to the local Administrators group

Ok, that's about it.  Since we're dealing with Windows instead of *nix, we don't have to set any kernel parameters (although this would be the time for it), so we can proceed with the install.  I am using DB2 Express-C Windows X64 since I haven't done that before.  It's a free download from IBM's external web site.  The version as of this writing is 10.1.  One thing I try to do is install every IBM program to C:\IBM instead of C:\Program Files\IBM (or whatever the default is).  This will be reflected in every step including this one.  Note: ALWAYS run this as Administrator (which may require you to do a right click-> Run as Administrator).

Downloading DB2 Express-C from the IBM Website using DownloadDirector

Starting installation 

Using the db2admin local user (no AD) 

It installed successfully, but I saw no need to capture that screen shot.  Don't do anything further at this point.

Parties not merging in MDM 10 (with Initiate Matching)

I have a default MDM 10 instance with the Initiate engine turned on, which I am using for a demo (as discussed in a previous entry).  I added three very similar parties, with suspect processing enabled, and they did not merge as expected using default matching rules (they have identical SSNs and addresses, and similar names).

I ran createSuspects using the IVT - no dice.  No suspects were generated.  So I went to the version 10 developers guide for the party domain, and did some investigation.  In order to properly perform suspect processing, the Initiate engine and MDM need to be kept in sync.  In fact, a new transaction "synchronizeeMe" was included for this very purpose.  I also found that the Evergreen Console from v9 has been updated to include this transaction (so I can run all parties through standardization, synchronization, create suspects, and collapse).

This accomplished what I was looking for - my parties created suspects and collapsed into one.  The Initiate engine tables were populated with values for future matching.  However, what if I want the synchronization step to be automatic?  I can perhaps understand why I might want the sync step controllable if I am running a batch load with many threads, and the synchronization might affect performance adversely.  But for a demo, where we want to show off features as simply as possible, I wanted it to be automatic.

Fortunately, the developers' guide has a solution for this as well via the CONFIGELEMENT table.

update configelement set value='true',last_update_dt = current_timestamp where name = '/IBM/DWLCommonServices/DerivedDataSynchronization/enabled';

Once I updated this value and recycled MDM, I emptied my database of operational data and re-ran the batch.  All parties merged!  

Note that only 1 party is in the contact table.  I inserted 3 records, so we wound up with the desirable result: 1 add and 2 updates.

By the way, don't forget to clean out the Initiate tables (EME_RECBKTD, EME_RECCMPD, EME_RECHEAD) when you are cleaning operational data from your system.  You will otherwise get an error if the deleted parties match with any new ones.

MDM 10 - DSUI Can Add But Not View Parties / getParty issues

I have been working on a VM for a Demo for my company lately and encountered this issue.  We installed MDM 10 (with Initiate Matching Engine) along with the DSUI on an RHEL instance on a VM.  DB2, MQ, and WAS ND are present as well with all security options turned on.

I can add a party just fine, but when I go to read or search for parties, I get an error.

In the above picture you can see the screen after hitting submit on Add.  The DSUI, under the covers, does an addParty and a subsequent getParty.  The addParty was successful (I turned on XML tracing to verify).

I traced the results to the OTS in the default v10 installer.  I never found out exactly what the issue was but was able to turn off OTS and have successful getParty calls.

To do this, open up tcrm_extension.properties and modify the optimized.sql property so it says "false".

I'm interested in finding out what was wrong with the OTS but this allowed me to continue.

Content Is Not Allowed In Prolog

I have gotten this error many times, and most of the time the issue comes from some accidental leading characters in the XML request to MDM.  However today, while migrating from one database to a brand new one, I got the error.  However, I validated my XML was clean.

Here is what the debug log:







From the logs, you can see that the configuration piece is not working (messages like getConfigItem: Item Name /IBM/DWLCommonServices/MultiTimeZoneDeployment/enabled cannot be found!).  It turns out when I did my export/import of the configuration tables from the old database (APPSOFTWARE, CONFIGELEMENT, APPDEPLOYMENT), the LOB(s) in APPSOFTWARE did not come in.

I used the .del format in my original import and changed to use .ixf

C:\CONFIGDATA>db2 export to appsoftware.ixf of ixf lobfile lob1 select * from ap
psoftware
SQL3104N  The Export utility is beginning to export data to file
"appsoftware.ixf".

SQL3105N  The Export utility has finished exporting "1" rows.


Number of rows exported: 1

{{CONNECT TO THE NEW DATABASE}}

C:\CONFIGDATA>db2 import from appsoftware.ixf of ixf insert into appsoftwar
SQL3150N  The H record in the PC/IXF file has product "DB2    02.00", date
"20120717", and time "121406".

SQL3153N  The T record in the PC/IXF file has name "appsoftware.ixf",
qualifier "", and source "            ".

SQL3109N  The utility is beginning to load data from file "appsoftware.ixf"

SQL3110N  The utility has completed processing.  "1" rows were read from th
input file.

SQL3221W  ...Begin COMMIT WORK. Input Record Count = "1".

SQL3222W  ...COMMIT of any database changes was successful.

SQL3149N  "1" rows were processed from the input file.  "1" rows were
successfully inserted into the table.  "0" rows were rejected.


Number of rows read         = 1
Number of rows skipped      = 0
Number of rows inserted     = 1
Number of rows updated      = 0
Number of rows rejected     = 0
Number of rows committed    = 1
--------------

Note, I had to delete configelement & appinstance before adding these rows, then add them back due to foreign key dependencies.

Things seem to work fine now.