Sunday, 5 December 2010

Lotus Connections 3.0 - Profiles Population Never Completes

*CAVEAT* This workaround worked for me - it may not necessarily work for you. If in doubt, please raise a PMR with IBM Support, and get a format response *CAVEAT*

Not sure for why, but the Profiles Population Wizard never seems to complete. It runs for ever, without any obvious error.   I'm using TDI v7.0.5 on Red Hat Enterprise Linux 5.5, going from Domino 8.5.2 to DB2 UDB

The problem isn't with the PULL from Domino, as I can see that collect.dns is being created/populated correctly.

The problem does appear to be with the PUSH into DB2, as I see the same symptoms when I run the script - The database tables were created using the DB Wizard.   I've also checked db2diag but to no avail.

Again, I'm not seeing any particular error messages.

Anyone else seeing anything similar ?

*UPDATE 13/12/2010*

Looks like I have a workaround to this problem: -

I navigated to: -


and edited ibmdisrv ( having first backed it up ) - note that this doesn't have a .sh extension.

I then changed: -


to: -


Having added the -Xnojit option, I then re-ran the Profiles Population script ( ), with Domino LDAP and DB2 started, and, lo and behold, four new DNs got pushed into my Profiles DB ( PEOPLEDB ), as evidenced by the SQL query db2 "select * from empinst.employee".

Job done :-)

It's also worth noting that the Lotus Connections 2.5 documentation also recommends adding the -Xms256M and -Xmx1024M to same command e.g.

"$TDI_JAVA_PROGRAM" $TDI_MIXEDMODE_FLAG -Xms256M -Xmx1024M -Xnojit -cp "$TDI_HOME_DIR/IDILoader.jar" "$LOG_4J" "$@"

but I've not yet tried this.

I imagine that an IBM Technote will be released to further document this workaround.

*CAVEAT* This workaround worked for me - it may not necessarily work for you. If in doubt, please raise a PMR with IBM Support, and get a format response *CAVEAT*


Otto Foerg said...

I have similar problems using the Connections 3 populationWizard with Windows 2003 Server. It pulls everything from Domino but the import into PEOPLEDB fails.

The wizard ends with:

CLFRN0027I: After iteration, success records is 0, duplicate records 0, failure records is 114, last successful entry is null

I have checked the logs, the only useful hint is in ibmdi.log, but I do not know what do to with it:] - Bad grammer exception public abstract java.lang.String throws[0]: LA_IDX_STATE) SqlMapClient operation; bad SQL grammar []; nested exception is com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in com/ibm/lconn/profiles/internal/service/store/sqlmapdao/sql/ProfileConstants.xml.
--- The error occurred while applying a parameter map.
--- Check the ProfileConstants.getValue-InlineParameterMap.
--- Check the statement (query failed).

For me this looks like a bug in the product. I never had any problems with the populationwizard of Connections 2.0, and 2.5.

I'm also using TDI 7.0.05 and DB2

- Otto

Dave Hay said...

@Otto - thanks, I don't see quite the same problem as you, because I never actually see an error message.

One thing that you may wish to try is to enable JDBC tracing, by changing: -


to: -


in: -


Try that, and see whether you get any additional data.

I'm using the same JDBC driver as you ( 3.59.81 ) said...

Hi, had ssame issue with the following configuration:

openSUSE 11.1 32bit
WebSphere Application Server
TDI v7.0.5
Microsoft Active Directory Server 2003

Adding the Xnojit argument helped !

Dave Hay said...

@Bernhard - thanks for the feedback. I had the same problem on Ubuntu 10.10, regards, Dave

Graham Bucknell said...

Dave!!! Champion and saviour! This tip saved me after a day of messing about. I am on RHEL 6. Sounds like it's a glibc vs. java mismatch or something, given we've all failed on newer OSes that aren't supported. Care to speculate?

Dave Hay said...

@Graham - not 100% sure, but disabling JIT does the job :-)

Unknown said...

SQLSTATE=42501 is no access. I had the same when I used db2admin to sync profiles. I used lcuser and it worked OK.

Grokking grep

A colleague was tinkering with grep  and, thanks to him, I discovered a bit more about the trusty little utility. I had not really explored ...