I know that I owe a post on SharePoint and EMC World. I just keep getting sidetracked with these simple, easy, yet relevant topics. As much as I may wish it, project work continues even as we are prepping for the future of the Documentum world. In addition, it has been a while since I posted a Documentum Tips article.

This issue is something that, while not necessarily new in D6, is more relevant in the D6+ world that we are living in these days.

What is the DFC Registry?

To quote the dfcfull.properties file:

On Windows clients, DFC uses the system registry to keep track of files checked out or exported to the client machine. On Unix systems, DFC keeps this information in a file on file system. DFC sets this mode automatically.

Essentially, when you interact with content on your system with a local DFC client, the information is tracked locally to optimize communications between the DFC client and the Content Server. The key setting, dfc.registry.mode, determines if the registry information is store in the Windows Registry, windows, or locally in the file system, file.

If you are in a non-Windows machine, like Solaris and AIX, then this issue may not impact you as you will always have the file-based registry in operation.

No Installation Needed

One of the nice features of D6 is the ability to deploy Documentum applications without installing any Documentum software. The most work that I have had to do is modify the dfc.properties file to point to the proper DocBroker. That is, until today when we saw this message:

Exception in thread “main” java.lang.UnsatisfiedLinkError: no DfRegistryWin32 in java.library.path

Initial research directed us to some artifacts that screamed pre-D6. I was about to break down and just install the DFC client locally on the system when it hit me. The Registry! I had seen the setting in dfc.properties and decided to try changing it. The following two lines were placed, as is, in our configuration:

dfc.registry.file = ${dfc.data.user_dir}/documentum.ini
dfc.registry.mode = file

That did the trick! Not hard, once you know what to do.

What Had Happened?

The next question was, Why did we have to do this now? We quickly determined the reason. Every previous machine that had run this particular application, and most of our applications for that matter, had previously been installed with some version of the Documentum DFC. As such, the base Windows registry entries had already been placed in the Windows registry. In addition, the DLL used to interface between the JVM and the Windows operating system was also present.

So when the DFC had tried to write to the Windows registry, everything was in place. When we placed the application onto a “pristine” machine, without changing our DFC Registry Mode, we hit the error.

Now we know. We will most likely install the DFC on all Production servers so we can use the Windows registry instead of a flat file approach.

If you have different experiences, leave a comment and let everyone know.