RPC 116 and ORA-03113

March 22, 2007 at 4:33 pm | Posted in Documentum and Oracle, Troubleshooting | Leave a comment

You may have encountered this error
[DM_SESSION_E_RPC_ERROR] RPC error 116.
It is returned by the DMCL to a Documentum client (like DFC, WDK, Webtop and so on) when the DMCL RPC client stub has encountered an error whilst waiting for a response from the server. Now this could be due to all sorts of things such as:

  • Network problems
  • Content Server session server crash
  • resource problem on the content server

Despite the text that usually returns with the error, network problems are the least likely source of this problems for most environments. More often than not the Content Server process/thread handling the RPC has hit some sort of problem (possibly a bug) and had to ‘bail out’ with an RPC error message ending up with the client.

The first place to look for information is the docbase log file ($DOCUMENTUM/dba/log) and the session logs ($DOCUMENTUM/dba/log/[docbaseid]/[username]). Often these will contain further error messages that reveal the real source of the problem. A support call to Documentum is often in order at this point particularly if it is a recurring issue.

ORA-03113 is really the Oracle counterpart of the Documentum RPC 116 error which is why I have put them together in this post. When an Oracle client (which for Documentum users means the Content Server) creates a session with Oracle it is connected to a process/thread in the Oracle server. Should this process encounter a problems that causes it to abort the client process receives a ORA-03113 error. Again this could be network problems but, particularly for Documentum Content Server setups where the Content Server is on the same machine as Oracle, this is less likely than other explanations.

I have encountered these problems in WebPublisher when running an ‘apply presentation’ command on a large number of files. In this particular case this turned out to be an Oracle bug which was resolved by upgrading from 9.2.0.1.0 to 9.2.0.6.0. The general approach is to look for process errors in the Oracle cdump log directory and if necessary raise a case with Oracle via metalink.

a last point: even though I have said network problems are the least likely source of problems, keep an open mind!

Advertisements

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.

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