I had planned to start running all of my “Tips” posts in the EMC Developer Network, but I wanted to editorialize a little in this Tip, so I’ve decided to throw it up here.  This issue arose when I installed a new repository into an existing environment.  It is a documented issue, though the Support guys need to read that documentation a little more closely.

The Time Warp

As you may have guessed from the title, I recently ran into an issue regarding the Timestamp in the Documentum Content Server.  We were looking at an update to a system and we noticed that the times in our little Data Shack were wrong, by about 5 hours.  We looked in the source Audit Trail in Documentum and we saw that both the time_stamp field and the time_stamp_utc field in the dm_audittrail_s table had the same value.

I had the team open a case with EMC Support and they quickly got nowhere.

After a few days, and a little thought, I browsed through some documentation and found this nugget in the Content Server Administration Guide:

By default, date values are stored as follows:

• As UTC (Coordinated Universal Time) time in new repositories (Documentum 6 and later).
• As the Content Server’s local time in repositories that are upgraded from before version 6.

This made sense.  We had rebuilt our development repository recently to clean it up, and so the date handling had changed.  Mystery solved! Time to call it a day?

No.

The problem was that in every other environment, there was an existing repository that already handled dates in local time. The plan was to create a new repository for a specialized type of content.  That repository would have the new rule, but the repository dates wouldn’t match, making reporting a little nightmarish.

Support had told us that everything was working as intended and closed the case without so much as a by-your-leave. My thought was that if two repositories running the same version of the software can behave in two different manners, there has to be a flag. The Administration Guide mentioned a field titled r_normal_tz.  What was this field and where was it?

So the search was on.  After a bit of digging, a support note was uncovered. Support Note #98383, Dates stored in Content Server V6.0 original install incorrectly calculate UTC time component offset in storing dates. Does not occur if content server was upgraded from 5.3 to 6.0, explained how the setting could be changed.  The value is in stored the docbase_config object.  The documentation says that the field should not be changed if the value is not 0. I tend to agree with this assessment as it will probably throw things out of synch.

Lucky for me, the problem was that the field was set to 0.  I just had to issue a simple DQL (Update dm_docbase_config Object Set r_normal_tz = -18000) to update the value for the Eastern Time Zone (-5*60*60 as the value store the differential in seconds). This value was also confirmed in the existing repositories.  After the change, we just had to restart the repository.

Wallah! It worked and now all is well.  After writing some documentation to capture the knowledge, we called it a day.

EMC Support Note Odds and Ends

One thing that I realized when researching this issue was that the Support Note numbering system was about to break the 100,000 mark. I decided to find the first note with a 6-digit number.  Using the URL format, https: //solutions.emc.com/emcsolutionview.asp?id=esg######, I started at 100,000 and on my fourth attempt, found the first PUBLIC note…

Support Note 100,003: Documentum Composer fails to install value assistance when the value assistance for a parent type attribute has been overridden. Written 25 September 2008, it outlines a bug that is fixed by upgrading Composer to 6.0 sp1. It isn’t a particularly useful note at this point, but worth commemorating.

I just hope I never see Support Note 1,000,000.