How to change a single attribute to repeating

There's no direct way to change a single attribute to repeating in your custom types, so this task is not trivial if you already have objects with metadata that should be preserved: a temporary attribute must be used.

The safe way is to perform the following steps:

1. Ensure no objects of your type are locked: select * from my_type where r_lock_owner <> ' ' (if you have locked objects, you should unlock them - see how to unlock).

2. Create a temporary single attribute fake_attr: alter type my_type add fake_attr char(100) publish

3. Copy all the values from your single attribute to the temporary one: update my_type objects set fake_attr=my_attr

4. Remove the single attribute: alter type my_type drop my_attr publish

5. Add the repeating attribute: alter type my_type add my_attr char(100) repeating publish

6. Copy back the metadata: update my_type objects append my_attr=fake_attr

How to restart correctly the repository (Content Server services)

A typical Content Server contains 3 types of services: Docbroker, Docbase and JavaMethodServer. The correct restart procedure is:

Change the startup type to 'Disabled' and stop the services:

1. JMS service

1a Check for java.exe process (use ProcessExplorer): if found, ensure it's related to JMS and kill it (sometimes it hangs and doesn't terminate when you stop JMS).

2. Docbase(s) service(s) (if there are more than 1 Docbase, stop them one by one, the global repository must be the last).

3. Docbroker(s) service(s).

4. Clean the JMS cache ([JBOSS]\server\DctmServer_MethodServer\work\) and DFC(BOF) cache (DM_HOME\dfcdata\cache)

Change startyp type to 'Auto' (or Manual) and start the services:

5. Docbroker(s)

6. Docbases (if you have more, start the global repository first, then the others)

6a Check each started docbase log for errors

7. JMS

7a Check JMS logs ([JBOSS]server\DctmServer_MethodServer\log): boot.log and server.log

How to create and modify an ACL with API

An ACL can be created using Composer, DFC code, or an API command. Here's a sample of creating and modifying an ACL with API:

create,c,dm_acl

set,c,l,object_name

sample_name

set,c,l,owner_name

dm_dbo

set,c,l,description

Sample ACL

grant,c,l,dm_world,6

grant,c,l,dm_owner,7

grant,c,l,sample_groupA,3

save,c,l

If you wand to modify an existing ACL, you can use:

retrieve,c,dm_acl where object_name = 'sample_name'

revoke,c,l,sample_groupA

grant,c,l,sample_groupB,3

grant,c,l,sample_groupC,7

save,c,l

How to unlock an object in Documentum

When a user makes a checkout on a sysobject (opens to edit), Documentum automatically applies a lock on the object, preventing other users from modifying it. Only the lock owner or a superuser can unlock the object by making a checkin or cancel the checkout. As sometimes users forget to unlock documents, you might need to do this as a superuser.

You can unlock an object in 2 ways:

DQL:

update dm_document object set r_lock_owner='', set r_lock_machine='', set r_lock_date=date('nulldate') where r_object_id='[OBJECT_ID]'

API:

unlock,c,[OBJECT_ID],F

The last argument is a boolean flag specifying if a mail notification will be sent to the lock owner.

xPlore Index Agent login failure

If you are using Documentum xPlore for fulltext search, you might face the following issue: after starting the Index Agent process, you have to start the Index Agent from the Administration page (http://URL:port/IndexAgent/login_dss.jsp), but the login fails with the message:
User is not an Admin User!
even if your user is a superuser

The cause is a bug in the login_dss.jsp code:
IDfUser userObject = doc_session.getUserByOSName(uname, domain_name);
…
if (userObject != null)
isSysAdmin = userObject.isSysAdmin();

The bug here is that if the userObject is null (was not found), the flag isSysAdmin remains false, so the error message doesn’t say that the user was not found, instead you have the message above telling it’s not an Admin user.

Now why the userObject can happen to be null? (Note: at this point of code the user is already logged in against the repository). It’s because the user is searched using getUserByOSName(uname, domain_name) method. So if the user_os_domain is not set in the dm_user object and the Documentum repository runs in domain required mode (dm_docbase_config.auth_protocol='domain_required') : if you don’t specify the domain on login page – login doesn’t succeed, if you specify it – the userObject is not found – thus null.

To solve this issue it's enough to modify the login_dss.jsp page substituting the getUserByOSName(uname, domain_name) method with getUserByLoginName(uname, domain_name) or getUser(uname), or you could just set the user_os_domain in the dm_user object (however first option is preferred).

Change repository owner password in Documentum

If the Database user password used for the Documentum repository is modified, you can update it accordingly in Content Server by following the steps:

1) Stop the repository service(s) (and all dependant services, ie: app servers)

2) Go to $DM_HOME/dba/config/

3) Create a copy of the file dbpasswd.txt

4) Edit the dbpasswd.txt and replace the old (encrypted) password with the new password, as plain text (not encrypted)

5) Save dbpasswd.txt

6) Go to $DM_HOME/bin and run the following command: dm_encrypt_password -docbase -rdbms -encrypt

7) Open the dbpassword.txt file (created at step 4-5) and check if the password has been encrypted

8) Restart repository service(s) (and other dependant services)

9) Check the repository log if it started successfully