nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Docbase cloning.

nick985

I recently cloned my QA system to the development system:

CS version : 6.5

DA: 6.5

and then upgrade the development CS to :

CS version : 6.7

OUR QA system (which is 6.5) is still up and did not shutdown while cloning...both are on same network.

Now I Installed DA (6.5) for QA server.

I see something very wierd that even though DA (6.5) for QA server points to docbroker on QA system in dfc.properties file, it is connecting to the docbase on development environment.

There is no reference to host name or docbroker info related to development server on QA environment, then how is it finding the dev docbase on DA (for QA environment)

Is there any corruption happening because of running both the systems after cloning

Thanks

Find more posts tagged with

Comments

Hartmut_Clausen

It looks like the cloned environment is projecting itself to the docbroker on the originating system. You should check the two places where the projection is configured:

server.ini in $DOCUMNTUM/dba/config/<repo> on the new host where the cloned docbase is running
dm_server_config in the cloned repository (attribute projection_targets and related attributes)

dnvhariprasad

after cloning, did you change the dfc.properties in the target repository?

nick985

Hartmut,

Projection in target server.ini is correct which pertains to development server.

dm_server_config in source dows not have projection_targets values and if I add that and re-start the docbase, it cause errors while re-starting the docbase.

Once I logging to the QA - DA and look at the admin tab, on the right side there is a row where its shows content server information:

Server version : Version of target content server (67)

hostname is the target host name --- DEV host name

connection broker host information is correct which is source docbroker

How is this happening? How is the CS host name showing as development host name and docbroker host is QA host name?

Do you have dfc property file which has all the attributes in UNIX environment for the DA.

Regards,

Hartmut_Clausen

If you want to know to which host the DA is connected, execute these API commands in Menu --> Tools --> API Tester:

getservermap,c

dump,c,<ID from previous command>

It could be that your dm_server_config object was not updated during the cloning and the database still has the old value in the r_host_name attribute. The command above will give you the "server map", a non-persisting object that is generated in the current session from the "real" connection data.

As for the dfc.properties: there are no special UNIX properties. All properties are available on all platforms. You can have a look at the dfcfull.properties file, which is located in the same directory as the dfc.properties in DA. It is for reference only and most of the properties you will never need, however you can find all possible values there.

nick985

Below is the error I got while running the API :

getservermap,c

Error processing command:com.documentum.fc.client.DfNoServersException: The DocBroker running on host (1489:1489) does not know of a server for the specified docbase ()

nick985

Forgot to mention that the I am setting up on a server which has the QA docbase installed on it.. Seems like this DA is somehow connecting to docbroker on the development server ... How can I check which config file or dfc.properties it is using...?

nick985

Forgot to mention that the I am setting up DA on a server which has the QA docbase installed on it.. Seems like this DA is somehow connecting to docbroker on the development server ... How can I check which config file or dfc.properties, DA on QA environment using...?

Hartmut_Clausen

Sorry, the command should be

getservermap,c,<repository name>

nick985

This give me correct host name in the dump... It is having the correct values...

Hartmut_Clausen

If the host name in the server map is correct, then it looks like the dfc.properties, the server.ini and the docbroker are OK. I guess, the the r_host_name attribute of dm_server_config was not updated during the cloning.

nick985

I see that the r_host_name for the dm_server_config for the target docbase is correct.. I verified it both on docbase level and database level. Any other ideas?

nick985

I just set up the QA documentum admin on my local machine and it was able to connect to the correct docbase.

but on the server, the DA is not behaving properly... QA documentum admin is pointing to dev docbase...

Julien.Fontaine

Have a look to the DFC Properties of your DA installation.

Hartmut_Clausen

Check which dfc.properties is used by the DA. Go to Menu --> Tools --> API Tester and execute this API command:

get,c,apiconfig,dfc.config.file

Check the settings of that file.

Hartmut_Clausen

This is the decompiled code that is used to populate the display:

IDfTypedObject serverConfigObject = session.getServerConfig();

server.setLabel(serverConfigObject.getString("object_name"));

serverVersion.setLabel(serverConfigObject.getString("r_server_version"));

host.setLabel(serverConfigObject.getString("r_host_name"));

It reads the "r_host_name" attribute from the dm_server_config object of the server to which the current session is connected.

nick985

Yes this helped me correcting the issue. Thanks.

nick985

Hello Hartmut,

How can I specify the path in the dfc.properties for logs to be loaded in a specific directory. Currently logs are going to default documentum directory under application server. Below is my dfc property file:

dfc.codepage=UTF-8

dfc.data.dir=C\:/documentumUser/da

dfc.tokenstorage.dir=${dfc.data.dir}/apptoken

dfc.cache.dir =${dfc.data.dir}/cache

dfc.data.export_dir=${dfc.data.dir}/export

dfc.data.local_dir=${dfc.data.dir}/local

dfc.tokenstorage.dir=${dfc.data.dir}/apptoken

dfc.checkout.dir=${dfc.data.dir}/checkout

dfc.docbroker.host[0]=xyz

dfc.docbroker.port[0]=1489

documentum.logs does not save under C\:/documentumUser/da

Any help is appreciated.

Hartmut_Clausen

Hi Nick,

you cannot specify the path to log files in the dfc.properties. You need to do this in the log4j.properties.

In the standard installation of the DA there is a log4j.properties in .../webapps/da/WEB-INF/classes. It will direct the logs to ${user.dir}/documentum/logs/documentum.log

The ${user.dir} variable will resolve to root directory of Tomcat ($CATALINA_HOME) or to $CATALINA_HOME/bin depending on the configuration of the Tomcat. If you want to have the log file in a different location or use a different file name you have to change the following line in the log4j.properties, e.g.:

log4j.appender.FILE.File=C\:/documentumUser/da/da.log

nick985

Thanks Hartmut,

This helped. Thanks.

How about setting up the path for the below folders:

Viewed

Temp

presets

contentXfer

I saw that these are not getting created in the above specified directory (C\:/documentumUser/da)

Thanks

nick985

Another problem is , even though i have specified a checkout directory in the dfc.properties (dfc.checkout.dir=C\:/documentumUser/da/checkout), the checkout of document happens to a default directory which is under c:/Documentum/checkout

Viewed directory is also not getting created under : C\:/documentumUser/da

dfc.data.dir=C\:/documentumUser/da

dfc.tokenstorage.dir=${dfc.user.dir}/apptoken

dfc.cache.dir=${dfc.user.dir}/cache

dfc.data.export_dir=${dfc.user.dir}/export

dfc.data.local_dir=${dfc.user.dir}/local

dfc.checkout.dir=${dfc.user.dir}/checkout

dfc.registry.mode=windows

dfc.tokenstorage.enable=false

dfc.docbroker.host[0]=abc

dfc.docbroker.port[0]=1489

How about setting up the path for the below folders:

Viewed

Temp

presets

contentXfer

I saw that these are not getting created in the above specified directory (C\:/documentumUser/da)

Hartmut_Clausen

Normally you do not configure all the directories. It is sufficient to have the "dfc.data.dir", all the other directories are per default relative to that directory. Also the variable "dfc.user.dir" is not defined, that might cause some of the problems.

If you checkout something with DA (or Webtop or any other WDK based client) the file is not copied to the machine where the Tomcat runs (the user would not be able to access the file there). Instead you are using the UCF applet. This will put a checked out file on the machine where the browser runs. The UCF configuration is completely independent of the dfc.properties.