It seems that a few people (myself included) have had the inevitable problems with installing this initial release of D6. Many of the problems seem to relate to the packaging of weblogic as the new app server for the JMS (previously Tomcat).
It is useful to look for a few log files when trying to troubleshoot this problem. The logs for the weblogic install go in %DM_HOME%\logs\install (at least on a Windows install) and the file structure for a successful installation looks like this:
If you click on the weblogic folder you should get the following structure:
I would first of all check the file install.log in the weblogic folder. It should show some thing like:
STDOUT: Extracting 0%…………………………………………………………………………………………..100%
Clearly the first step the installer takes is to extract/unzip the weblogic installation package. The extraction appears to occur to the current working directory. When I tried invoking the installation from a network drive without write permission the installation proceeded happily until the weblogic installation. Then it just hung around for ages showing a progress bar that crept up to 100% and then went no further. Viewing the weblogic/install.log showed only:
STDOUT: Extracting 0%
which is what makes me think that the extraction was targetted at the non-writable network drive resulting in failure.
Assuming the installation gets this far but you still have problems then it is worth examining the other log files, probably in the date /time order you see on the directories here.
I’ve just been testing Xense Session Manager version 1.0.2 against Documentum 6 and it appears that it doesn’t work with DFC 6. Xense Session Manager will happily connect to a D6 repository when running with a pre-D6 DFC but of course don’t go installing an old DFC directly onto the Content Server (or any other machine that has DFC 6 installed). I’ll get Xense Session Manager working against DFC6 at some point – I’ll post the details here as they arise.
In my review of Documentum Content Fundamentals I made the comment that the section describing how a DFC-based client communicates with the Content Server was wrong. It turns out that that passage of the book was based on a section in the Documentum System Development Guide, in fact Pawan Kumar has helpfully posted the relevant passage on his website. I thought I would use this post to expand on what I think is wrong with both the explanation given in the System Development Guide and in Pawan’s book.
First of all I think it would be helpful to define exactly what I mean when I am referring to the DMCL (Documentum Client Library) and the DFC (Documentum Foundation Classes). The DMCL consists of a DLL (windows) or shared library (Unix) plus a configuration file dmcl.ini. The DLL is called dmcl40.dll and the shared library has a number of names depending on the OS but usually something like libdmcl40.so.
The DFC is a set of JAR files, principally dfc.jar but also a number of others contained in c:\Program Files\Documentum\shared (windows) or DOCUMENTUM_SHARED (Unix). In addition there are a number of configuration files such as dfc.properties and dbor.properties. Documentum hasn’t had a separate release of the DMCL files for quite a while now and it will only be installed as part of the DFC installation. Just to complicate matters Documentum 6 no longer has a native code implementation of the dmcl, it is all implemented in Java, and DFC and DMCL are all bundled together.
No Server-side DMCL
If you look at the description of the communication process given in the System Development Guide you will see it talks about there being a DMCL receiving communications on the server-side. This is not correct. It is pretty easy to see that no DMCL code is loaded or invoked in the Content Server process so it can’t be that DMCL is receiving communications. Of course there may be another process running as an intermediary on the server-side that is running a ‘server-side’ DMCL. However it is again easy to see that the communications are direct client to server by using netstat to view the network endpoint connections.
If you look at the functions involved in stack traces both on the client and in the content server it can be seen that Documentum uses a fairly standard RPC mechanism to present Content Server functionality to the outside world (ie anything outside of the Content Server process). The DMCL implements the official Content Server API, a set of 150 or so functions that utilise the RPC functions implemented by the Content Server.
No server-side DFC
The description in the System Development Guide only talks about a server-side DMCL but the accompanying diagram shows a server-side DFC component. The server-side DFC is not shown as taking part in the communication process but it may have been the catalyst for Pawan to extrapolate the description of the communication process to include a server-side DFC. In his description the communication is client-DFC -> client-DMCL -> server-DMCL -> server-DFC. Again this does not seem to be an accurate model of what happens. DFC was conceived as an object-oriented wrapper around the DMCL and it doesn’t really make sense for there to be a server-side DFC component to the communication.
So the description in the System Development Guide is not quite accurate. But does it matter? There are a couple of reasons I think it does.
- It is essential when troubleshooting systems to understand what components are involved and how they communicate. The idea that dmcl is involved as part of the server-side processing can and has mislead some people into believing that changing dmcl.ini parameters on the server can influence and change Content Server processing. Methods and other processes running on the server but external to the content server process act as client programs using the DMCL but Content Server code does not appear to use the DMCL library or the dmcl.ini configuration parameters
- Architecting systems for performance and performance tuning relies on understanding the pattern of communication
I hope that EMC Documentum will look at revising the section in the System Development Guide to avoid the confusion it causes.
I was very pleased to see that Packt Publishing have started producing Documentum books (they also have released ‘Web Content Management with Documentum’). There really is a crying need for good quality Documentum books to help explain what is often a complicated suite of products.
This book is styled as a Study Guide for ‘EMC Proven Professional Certification Exam E20-120′. In addition it is intended to act as ‘a handy guide and a quick reference’ to the technical fundamentals of Documentum. So how well does it achieve these goals?
The book follows a typical certification exam study guide format of each chapter starting with text explaining concepts followed by typical test questions. The text is highly readable and is accompanied by clear and useful diagrams. At the end of the book there are 2 Practice tests that cover all the material (answers to these tests and the chapter tests are provided at the end of the book). My impression was that the questions are well thought out and effectively tested understanding of the concepts. The only improvement here would be to have even more test questions. Actually Pawan also maintains a website (http://www.dmcram.org) where further test questions can be found along with tips and resources to support the book.
Occasionally I thought that it would be useful to have more worked examples. For example object security in Documentum is reasonably complicated when first encountered and a wider range of example scenarios would help to make the subject matter stick. One area that doesn’t seem to be covered at all is Jobs and Methods. I would be surprised if this wasn’t tested at all in the exam and someone using just this book would be underprepared in this area.
Most of the technical information in the book seems to be accurate and I was certainly surprised by how many little details I didn’t know (e.g. the rather confusing way Documentum numbers branched versions). There is one major error in chapter 4 which looks at the Architecture of a Documentum system and how the components interact. The fundamental communication pattern describes DFC on the client communicating with DFC on the Content Server. This is just wrong – there is no server-side DFC involved. Yes, DFC will be installed on the Content Server but it is there for clients running on the server. If you removed DFC from the Content Server, remote DFC clients would still work in the same way. Even more confusingly the diagram that accompanies the description shows a communication pattern involving both DMCL and DFC on the Content Server. Perhaps it is best to refer to my description of the Communication Pattern. However this was the only significant error I found.
[Update 13 Sept 2007: Pawan has pointed out that the book text is based on the diagram and description contained on p52-53 of the Documentum System Development Guide. That is certainly true. The only thing I can say is to repeat the following advice given to Cary Millsap by his father at the beginning of every school year
'There are two answers to every question your teachers will ask you while you're in school. There's the correct answer, and there's the answer that the teacher wants. I expect you to know them both.'
(taken from Optimizing Oracle Performance, Cary Millsap with Jeff Holt);]
All in all I would recommend this as a useful aid to someone studying for the exam. Well done to Pawan and Packt Publishing for producing this book; let’s hope that Packt will invest in a further improved and extended edition and indeed further Documentum books; and let’s hope that this encourages other publishers into the sector.
Update: you can check out any corrections or updates on the Packt Publishing site at http://www.packtpub.com/support
Loads of D6 documentation is appearing on Powerlink. I’m going through the Content Server Admin Guide over the next few days and I’ll pick out some of the stuff that looks interesting. The first thing that caught my eye was that Tracing and Logging has its own chapter. Previously this was all lumped into the Tools chapter. A very timely revision.
2 important changes here, first sqltrace is now on by default. This means that all the SQL being generated from a DQL command (very often there is a 1-to-many relationship between DQL and SQL) is output to the content server session log. I think this is a great improvement from the troubleshooting and performance tuning aspect.
Secondly there is a new server tracing option called rpctrace. The documentation states ‘Turns on tracing of RPC calls’. I will be having a look at the tracing format and the information being dumped by this trace option as again it is potentially very useful.
The release notes for Documentum 6 Content Server have just been released (!?!) on PowerLink. D6 is going to be a huge change, comparable with the moves from 3 to 4 or 4 to 5. Here are some interesting snippets from the release notes:
In new repositories, all date values are stored as UTC (Coordinated Universal Time) format. Repositories upgraded from prior releases continue to store date values in server local time. This could be an interesting gotcha if you trying to reproduce behaviour from an upgraded repository in a newly created repository. In fact there is a whole section in the release notes (in Limitations section, ‘Client applications accessing Content Server located in a different time zone’) about the semantics of reading/writing date and time attributes with D5 and D6 clients. You should definitely read this section to ensure you don’t get tripped up. I can forsee many forum questions on this subject.
Documentum 6 introduces major enhancements for supporting distributed configurations. Certain configurations that previously supported only read operations now support write operations as well. Accelerated Content Server (ACS) and Branch Office Caching Server (BOCS) now get the long awaited write support (in D5 BOCS only supported read-caching). Interestingly ACS is said to support both synchronous and asynchronous writing. Synchronous will write the content back to the content server immediately. Asynchronous requires the support of yet another new component Documentum Messaging Server (DMS). I haven’t seen any details yet but once I have I’ll try and put together a piece on how these components all fit together and suggest some strategies for their use.
An improvement in this release notes is the Content Server OS/Database version requirements section. This is now a matrix (OS v DB) rather than a flat listing.