Inside Documentum

The poor old Documentum Client Library (DMCL) gets blamed for a lot of things. The suggestion to delete the dmcl cache to avoid a multitude of problems has now entered the realm of myth. I’m sure that for many problems this is the correct solution. However, as you will need to shutdown the application using DMCL before deleting the cache, in many cases the simple act of restarting the application may have resolved the problem anyway. Still, since you can never be sure, a quick delete of the cache is no big deal if you are going to restart an application anyway.

However the finger of blame sometimes gets pointed at the DMCL even when it is unlikely to have any connection with the problem in hand. An example is internal processing failures of the Content Server process. I have seen people (including Documentum support) suggest dmcl cache clearing even for problems that arise inside Content Server processes. One of the keys to troubleshooting is using an understanding of how applications are architected to rule out certain explanations for the error.

The figure below shows a typical Documentum technology stack. This particular example is for a web browser accessing WebPublisher but you will see a similar picture for other client applications. The key here is that DMCL is a client library. Content Server exposes all its functionality via a set of (undocumented) server functions that are accessed via a Remote Procedure Call (RPC).

The DMCL is a linked library inside the client application – a DLL in windows, shared library in Unix. The DMCL takes documented API calls made by the client application and maps them to Server RPC functions that can be executed by the Content Server. Once the call has arrived inside the Content Server process the processing is no longer affected by the DMCL environment. In fact the DMCL thread that made the call will simply be sleeping awaiting the results of the processing from the server.

The really confusing part is that DMCL is included with the Content Server installation. The reason is that much of the functionality that is associated with the Content Server is actually implemented in external methods. In these cases the external method is a client of the Content Server and will utilise DMCL (via the API) to do its work. So really you need to be clear where the error is originating from. Does it arise from the external method code or does it arise from processing inside the content server?