DA Irritation

March 2, 2007 at 10:58 pm | Posted in Performance | 2 Comments

Have a look at this screen from DA:

mail method properties screen

It’s the properties screen for a method. I haven’t changed anything from the values initially presented so what will happen when I click OK?

Well unfortunately this will render a major component of my installation inoperable. The problem is that this method, which is stored in the docbase as a dm_method object named ‘mail’ needs the method_type attribute to be blank. But the DA properties screen doesn’t allow a blank. So it puts the first valid value (dmbasic) in its list into the field on the screen. And then if you click OK it updates the dm_method object!

So what’s the impact of this? If I have a dm_method object like this:

object_name : my_method
method_verb : ./my_program.exe
method_type :

then when I execute the method the content server will execute ./my_program.exe as a new process. But if DA has changed my dm_method object to look like this:

object_name : my_method
method_verb : ./my_program.exe
method_type : dmbasic

then the content server will try to execute a process with the following command line and it will fail:

dmbasic -f ./my_program.exe

When I try and execute the method I get a DM_METHOD_E_INVALID_MTHD_VERB error:

mail method execution error

If you need to fix this problem then DQL like the following will do the trick (nb that’s a space between the single quotes):

UPDATE dm_method OBJECT
SET method_type = ' '
WHERE object_name = 'mail'

This is actually just an instance of a general problem with DA that has existed in various forms since its inception with Documentum 4i. Other examples are the way the Target Server field in the dm_job object are automatically filled with the current attached server name and also the way early versions of DA 4 used to truncate java method_verbs if they were too long; too long for DA but not too long for the method_verb field in the dm_method object.

This strikes me as exceptionally sloppy design for a fundamental component of the Documentum system and I find it very irritating that this problem is still with us after 7 years. How can EMC|Documentum expect us to rely on DA if ‘careless’ use can have such catastrophic effects on the systems the software is supposed to manage. I have now decided to log every issue like this as a bug, if enough people follow suit maybe we can get this problem addressed once and for all.

The issue above comes from 5.2.5sp5 – I haven’t check 5.3 yet for the same problem, but I will post an update when I have.

Advertisements

2 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Nice find!!!
    I tried this on 5.3 SP5, but Documentum still hasn’t fixed this.

  2. Thanks, ashish you saved me the trouble.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Create a free website or blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: