Last month, I ran into an error.  You know the type, vague, irritating, and an r_object_id that I didn’t recognize. (Okay, I never “recognize” an id given the complexity, but usually I can figure things out from the first two digits.)  The error basically said that the r_object_id “53…” did not exist.

Anyway, a quick look didn’t reveal anything. I determined that it wasn’t derived by dm_sysobject by doing a quick query on the table. I decided to throw the question out to Twitter and see what happened.

Okay fearless #Documentum hackers, what object type begins its r_object_id with a ’53’?

I got two replies, one from Lee Dallas (@ldallasBMOC) and another from David Matheson (@davidfmatheson).

@piewords #Documentum 53 is dm_literal_expr – if you are asking-you need to run data dictionary publish,clear caches restart app svrs

@piewords #Documentum @ldallasBMOC beat me to it, I would add you can check IDfId for the full list of what’s what in any version of DFC.

So Lee gave me the fix, which had already been executed, but he told me why the restart of the client application worked. (The Data Dictionary runs regularly in our environment, so it had already run). David taught me how to answer the question in the future.  I also found another way to make the determination as well.  I’m going to share them both now.

The DFC Javadocs

This is where David sent me.  The Javadocs are simple enough to navigate.  Open up the Javadocs and select IDfId from the left-hand panel.  You will see a list of constants.  Click on any of them, DM_ACL is first, and it will take you to the definition.  It doesn’t give you the value here, but if you click that link for Constant Field Values, you will be taken to a table of values.

We aren’t done as there is one final step that David overlooked.  The constants are all base 10 decimals.  The two character object type tag is hexadecimal (base 16).  So if I convert my 53 from hexadecimal (using this nice little converter), I get 83.  When I search the table, I find dm_literal_expr, the very answer that Lee sent me.

If you ever need to reverse the process and work from the table (decimal) to the object type tag, you can use the reverse conversion (available from the same source) to get your hexadecimal value.

The Object Reference Manual

So a day or two later, I was looking something else up in the documentation.  I then noticed that the answer was staring me in my face.  I was looking in the Object Reference Manual that is part of the core Content Server documentation and there it was, Object type Tag: XX.

So rather than navigating the DFC Javadocs for the answer, I can open that manual and search on Object type tag: 53 and get my answer.  It is faster and now I have two options.

Extra Side Notes

A few random lessons/observations came about from this effort, so I wanted to share them.

1. It is impossible to learn everything in Documentum, so don’t even try. Just learn where everything is written down. I learned two new places while solving this problem.
2. I found all sorts of Documentum documentation online while looking for other items.  Not sure if it allowed to be up there, but it has been posted by James Azarja on Scribd.  The Object Reference Manual for 6.5 is up there as of this writing.
3. Twitter is pretty useful for getting some quick answers. It can be faster than the forums on EDN, though EDN is the perfect place for more detailed Q&A.
4. The error in question arose when a Composer project was installed.  Only one thing was updated in the project, but everything was version, even with no changes.  This may turn into a separate post on best practices around Composer (aside from using Application Builder instead).