Old dqMan against Documentum 16.7+

The old fme dqMan 6.x desktop client often fails to connect after Content Server 16.7+, typically with a blank Error dialog and no stack. This note is that 32-bit Swing client, not the current commercial product at dqman.com.

Typical working set

dqMan 6.x is a 32-bit Java app talking DFC/DMCL. A 64-bit JRE, a DFC that does not match the repository, or a missing native library produces a silent Error box rather than a useful message. What usually works:

• 32-bit JRE 8 at %JRE32_HOME% — not a 64-bit JDK, not a later Java that dropped the old plugin layout.
• DFC jars that match the target repository (same major as the Content Server you are logging into).
• dfc.properties in the dqMan config directory (under %DQMAN_HOME%), with dfc.docbroker.host / port and dfc.globalregistry pointed at that repo — not a leftover from another machine.
• java.ini (same config dir) setting java_library_path at the 32-bit jvm.dll (typically %JRE32_HOME%\bin\client or ...\bin\server).
• Classpath in that ini including dfc.jar, dctm.jar, and the config directory itself so dfc.properties is on the path.

%DOCUMENTUM% still needs a usable DFC layout if that is how the machine was installed; some shops copy a matching DFC tree next to dqMan instead of relying on a full Content Server client.

DMCL DLL

A few environments stopped loading dmcl40.dll after the 16.7 native stack change and instead placed an older dmcl.dll beside the dqMan install (or on PATH ahead of the 16.7 client). That is a compatibility hack, not a supported configuration. If you try it, keep the 32-bit JRE and the matching DFC jars; mixing a 64-bit jvm.dll with a 32-bit DMCL is the usual blank-dialog path.

Not the current dqMan

fme’s old 6.x desktop build is what this note describes. A separate commercial dqMan exists at dqman.com with its own installer and licensing. Do not treat paths, dialogs, or version numbers from that product as interchangeable with 6.x.