Dump File Manifests

I have used Documentum’s Dump/Load facility many times during my career and have written about it at some length, for example, in this migration paper . I have done all sorts of things with it trying to make it easier to use like writing GUI wrappers around it, writing automated scripts, and studying it to understand its inner workings. One thing that has always bothered me about Dump files (and DocApps and DAR files, but that’s a different topic), is that you don’t know what they contain until you install them. It seems to me that there should be a utility that could read a dump file and produce a manifest of its contents before you install it. I have tried for years with no success to get Documentum engineering to give me the format of the Dump file so I could write such a utility. I have been able to scrape together some information for various support notes and such, but not enough to put together a utility application yet.

So, I haven’t solved this problem yet, but I have come up with an alterative that will work in some cases. I have encapsulated this solution into a Java class you can find here . I will highlight some of the code below, but first a little tutorial on how Dump/Load work.

To initiate a Dump, you create and save a dm_dump_record object. This is usually accomplished using an API script. I used the one below to test this solution. Note the script should dump a single cabinet object named “dump” that contains a single PDF file — two objects, that’s it.


As the script creates the dump.dmp file, it creates objects of type dmi_dump_object_record for each object appended to the file.  So, on the source repository, after a Dump file is created, you should be able to determine all of the objects appended to a particular Dump file by querying this object.

The first thing you will need is the r_object_id of the dm_dump_record object like this:

select r_object_id dm_dump_record where file_name = ‘\<the name of the dump file in the API script\>’

And with the dm_dump_record's r_object_id, find all of the objects that were appended to the dump file. That DQL would look like this:

select object_id from dmi_dump_object_record where dump_object = ‘\<r_object_id of the dm_dump_record\>’

I encapsulated these queries into the above mentioned Java class and tried to extract some meaningful information from each object to create a manifest of the Dump file’s contents.  As you can see from the following snippet, some objects lend themselves to the extraction of meaningful details and some don’t.  You can easily extend this code to meet your specific needs.

270000018000019f dm_format
060000018002318a dmr_content
090000018002453f dm_document xPlore_1.0_Deployment_Guide.pdf /dump 688407 pdf
0c00000180000194 dm_cabinet Integration /Integration
0b0000018000019e dm_folder Esignature /Integration/Esignature
0b0000018000019f dm_folder Templates /Integration/Esignature/Templates
4f00000180000324 dm_nls_dd_info
58000001800004d9 dmi_expr_code /System/DataDictionary 0
510000018000032e dm_aggr_domain
2e0000018000017b dmi_type_info
0600000180002158 dmr_content
09000001800001a8 dm_esign_template Default Signature Page Template /Integration/Esignature/Templates 46255 pdf
450000018000010e dm_acl dm_450000018000010e
0c00000180000118 dm_cabinet Templates /Templates
27000001800001ac dm_format
0600000180000114 dmr_content
09000001800001b2 dm_document Blank PowerPoint Pre-3.0 Presentation /Templates 14848 powerpoint

I find it very interesting the things Documentum thinks it needs to include for the dump a single cabinet and a single document. This dump file is 75MB in size, the PDF is 700KB.

This solution works well as long as you generate the manifest before you delete the dm_dump_record object from the source system — best practice dictates you should delete it as soon as you have created the dump file. Note that deleting the dm_dump_record object deletes all of the associated dmi_dump_object_records also.

If anyone knows of a utility that creates manifests dump files I’d love to hear about it. I would also be interested in the structure of the dump file if you know it.


About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

One Response to Dump File Manifests

  1. Pingback: Links to All of My Source Code | dm_misc: Miscellaneous Documentum Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: