{"id":11089,"date":"2018-04-19T16:12:40","date_gmt":"2018-04-19T14:12:40","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/"},"modified":"2025-10-24T09:13:59","modified_gmt":"2025-10-24T07:13:59","slug":"another-surprising-journey-in-documentum-land","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/","title":{"rendered":"Another surprising journey in Documentum-land"},"content":{"rendered":"<h4>The journey begins<\/h4>\n<p>In a VM Oracle VirtualBox with Centos Linux 7.0, you install Documentum v7.3 and create a docbase dmtest\u00a0with its schema in a database on another VM running Oracle Linux. You start the newly created docbase and successfully connect locally to it from within iapi or idql. You smile with satisfaction and go on. It&#8217;ll be a walk in the park, you think.<\/p>\n<p>In another VM, a client, running under Ubuntu 16.0.3 (you like those different distributions, don\u2019t you ?), you install the Documentum 7.3 binaries too and configure the dfc.properties file. You then attempt to connect to the docbase above from within iapi or idql but the connection takes forever (more than 20 minutes) and finally terminates miserably with the error message:<br \/>\n<code><br \/>\n[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker \"dmtest:1489\" failed<br \/>\n[DM_SESSION_E_RPC_ERROR]error: \"Server communication failure\"<br \/>\njava.net.NoRouteToHostException: No route to host<br \/>\n\"<br \/>\n<\/code><br \/>\nSometimes the connection is immediate but most of the time is simply takes forever until it fails with the stupid error message above. You scratch your head and start rechecking the network interfaces, ping the hosts, verify the usual files \/etc\/hosts, \/etc\/resolv.conf, services.ora, server.ini and local dfc.properties, stop the firewalls on both machine and on the host O\/S, even disable the SELinux extensions, but to no avail. You activate DFC and RPC tracing on the client but no new log file is written. You check the logs on the server side but find nothing relevant.<br \/>\nClose to a nervous breakdown, you even try a local docbroker on the client VM and project the docbase to it, but the connection still hangs. You do that on the VM running Oracle Linux too and the result isn&#8217;t any better. At the very least, both distributions are consistent.<br \/>\nThose long time-outs and the java.net errors suggest something network-related may hang the program maybe right after it invokes some java stuff. Strangely enough, no JVM process is started on the client to interpret said java code. Thus, you restart the iapi command with system calls tracing on:<br \/>\n<code><br \/>\nstrace -o iapi.trc iapi -Udmadmin -Pdmadmin<br \/>\n<\/code><br \/>\nThe produced iapi.trc file is very detailed and contains lots of run-time calls. Excited, you jump to the last lines:<br \/>\n<code><br \/>\n\u2026<br \/>\nsocket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 68<br \/>\nioctl(68, SIOCGIFFLAGS, {ifr_name=\"enp0s3\", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0<br \/>\nclose(68) = 0<br \/>\nsocket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 68<br \/>\nioctl(68, SIOCGIFHWADDR, {ifr_name=\"enp0s3\", ifr_hwaddr=08:00:27:03:22:0d}) = 0<br \/>\nclose(68) = 0<br \/>\nsocket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 68<br \/>\nioctl(68, SIOCGIFFLAGS, {ifr_name=\"lo\", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0<br \/>\nclose(68) = 0<br \/>\n\u2026<br \/>\nioctl(68, SIOCGIFBRDADDR, {ifr_name=\"enp0s3\", ifr_broadaddr={AF_INET, inet_addr(\"192.168.56.255\")}}) = 0<br \/>\nioctl(68, SIOCGIFNETMASK, {ifr_name=\"enp0s3\", ifr_netmask={AF_INET, inet_addr(\"255.255.255.0\")}}) = 0<br \/>\nioctl(68, SIOCGIFINDEX, {ifr_name=\"enp0s3\", }) = 0<br \/>\nclose(68) = 0<br \/>\nsocket(<strong>PF_INET6<\/strong>, SOCK_DGRAM, IPPROTO_IP) = 68<br \/>\nopen(\"<strong>\/proc\/net\/if_inet6<\/strong>\", O_RDONLY) = 69<br \/>\nfstat(69, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0<br \/>\nread(69, \"fe800000000000000a0027fffe03220d\"..., 1024) = 108<br \/>\nread(69, \"\", 1024) = 0<br \/>\nread(69, \"\", 1024) = 0<br \/>\nclose(69) = 0<br \/>\n\u2026<br \/>\n<\/code><br \/>\nThis really looks like network stuff. You recognize the interface name and notice that IPv6 is mentioned and used too but our interface has an IP v4 address. Just to be sure, you deactivate IP v6 in both the client and server VMs for the relevant interfaces with the following commands:<br \/>\n<code><br \/>\nsudo sysctl -w net.ipv6.conf.all.disable_ipv6=1<br \/>\nsudo sysctl -w net.ipv6.conf.default.disable_ipv6=1<br \/>\n<\/code><br \/>\nbut this does not solve the problem at hand.<br \/>\nConfident, and a bit upset too, you start scrutinizing this trace file line by line from the bottom up until something d\u00e9j\u00e0 vu catches your sharp eyes at around the 15\u2019000th line:<br \/>\n<code><br \/>\n...<br \/>\nopen(\"<strong>\/dev\/random<\/strong>\", O_RDONLY) = 65<br \/>\nfstat(65, {st_mode=S_IFCHR|0644, st_rdev=makedev(1, 8), ...}) = 0<br \/>\nread(65, \"\\355\\347\\333\\217X;\", 20) = 6<br \/>\nread(65, \"\\24\\314\\305\\37JK\", 14) = 6<br \/>\nread(65, \"q\\5T\\23\\1\\250\", 8) = 6<br \/>\nread(65, \"331\", 2) = 2<br \/>\nread(65, \"`\\3\\256\\354\", 20) = 4<br \/>\nread(65, \"\\221\\302\\223\\270\\202\\205\", 16) = 6<br \/>\nread(65, \"\\213\\222e\\206j\\361\", 10) = 6<br \/>\nread(65, \"N+\\\"H\", 4) = 4<br \/>\nread(65, \"K\\215\", 20) = 2<br \/>\nread(65, \"\\355P1\\320\\312\\301\", 18) = 6<br \/>\nread(65, \"\\27\\232a\\32\\272\", 12) = 6<br \/>\nread(65, \"\\3055n\\221 '\", 6) = 6<br \/>\n\u2026<br \/>\n<\/code><br \/>\nIf you do a tail -f on the trace file, you notice unmistakenly that the execution is waiting repeatedly on read(65, &#8230;), i.e. a response from \/dev\/random. You heard lots of confusing tales about how this device is blocking and slows down the java stuff and how better it is to use its non-blocking counterpart <strong>\/dev\/urandom<\/strong> (see other blogs on this very site too). Could it be that this is the culprit eventhough you&#8217;re running non java executables ? How to force <strong>\/dev\/urandom<\/strong> to be used instead in our case ? You notice that the Documentum\u2019s environment setting script, dm_set_server_env.sh, defines DEVRANDOM=\/dev\/urandom and this variable has been set indeed, but obviously it has no effect here. You start googling for information and find wheelbarrows of it. Many middlewares have a way or another to choose the random number generator device, but for native programs the only way seems to be something like removing \/dev\/random and linking it to \/dev\/urandom. Instead of sym linking, someone (see references below) proposed a lower-level alternative consisting in using the same node as \/dev\/urandom to redirect the calls to the same kernel device:<br \/>\n<code><br \/>\nls \/dev\/*random<br \/>\ncrw-rw-rw- 1 root root 1, 9 Apr 7 14:52 \/dev\/urandom<br \/>\ncrw-r--r-- 1 root root 1, 8 Apr 7 20:23 \/dev\/random<br \/>\nrm \/dev\/random<br \/>\nmknod \/dev\/random c 1 9<br \/>\nll \/dev\/*random<br \/>\ncrw-rw-rw- 1 root root 1, 9 Apr 7 14:52 \/dev\/urandom<br \/>\ncrw-r--r-- 1 root root 1, 9 Apr 7 21:26 \/dev\/random<br \/>\n<\/code><br \/>\nAs nothing prevents you to do it on your toy machines, you go for it on the client VM (don&#8217;t do this in a production machine unless you know all the possible side-effects of this change !) and a little miracle happens: the response from the server arrives quickly but your spidey sense, along with the error message below, tells you something is still quite not right:<br \/>\n<code><br \/>\nConnecting to Server using docbase dmtest<br \/>\nCould not connect<br \/>\n[DFC_SESSION_DOCBASE_UNREACHABLE] Docbase \"dmtest\" is unreachable<br \/>\n<\/code><br \/>\nAgain, this is familiar stuff, or so you think, thus you check again the dobcase projections and run dmqdocbroker against the local docbroker (it too was impacted by the slowness and now it starts up swiftly too) on the client VM and notice that the test docbase is reported here as expected:<br \/>\n<code><br \/>\ndmadmin@dmclient:~\/documentum\/shared$ dmqdocbroker -i<br \/>\ndmqdocbroker: A DocBroker Query Tool<br \/>\ndmqdocbroker: Documentum Client Library Version: 7.3.0000.0205<br \/>\nTargeting current host<br \/>\nTargeting port 1489<br \/>\n---- dmqdocbroker: (TARGET HOST: dmclient.cec.com) ----<br \/>\np) Ping (test connectivity to) the docbroker<br \/>\nd) Get a docbase map<br \/>\ns) Get a server map<br \/>\nn) Get next largest docbase id<br \/>\nl) lookup a docbase id<br \/>\no) find all open servers for a docbase<br \/>\nh) Set the host name for the docbroker<br \/>\ne) exit<br \/>\nEnter an option (i.e. letter)&gt; h<br \/>\n<strong>Enter the host name for the Docbroker: dmtest -- make it point to the docbroker on the content server VM as defined in the \/etc\/hosts file; <\/strong><br \/>\n---- dmqdocbroker: (TARGET HOST: dmtest) ----<br \/>\np) Ping (test connectivity to) the docbroker<br \/>\nd) Get a docbase map<br \/>\ns) Get a server map<br \/>\nn) Get next largest docbase id<br \/>\nl) lookup a docbase id<br \/>\no) find all open servers for a docbase<br \/>\nh) Set the host name for the docbroker<br \/>\ne) exit<br \/>\nEnter an option (i.e. letter)&gt; p <strong>-- ping the remote docbroker;<\/strong><br \/>\n<strong>Successful reply from docbroker at host (localhost.localdomain) on port(1490) running software version (7.3.0000.0214 Linux64). &lt;------ hum hum ...<\/strong><br \/>\n---- dmqdocbroker: (TARGET HOST: dmtest) ----<br \/>\np) Ping (test connectivity to) the docbroker<br \/>\nd) Get a docbase map<br \/>\ns) Get a server map<br \/>\nn) Get next largest docbase id<br \/>\nl) lookup a docbase id<br \/>\no) find all open servers for a docbase<br \/>\nh) Set the host name for the docbroker<br \/>\ne) exit<br \/>\n<strong>Enter an option (i.e. letter)&gt; d -- what docbases project on that docbroker ?<\/strong><br \/>\n**************************************************<br \/>\n** D O C B R O K E R I N F O **<br \/>\n**************************************************<br \/>\n<strong>Docbroker host : localhost.localdomain -- hum hum ...<\/strong><br \/>\nDocbroker port : 1490<br \/>\n<strong>Docbroker network address : INET_ADDR: 02 5d2 c0a8380c localhost.localdomain 192.168.56.12 -- hum hum again<\/strong><br \/>\nDocbroker version : 7.3.0000.0214 Linux64<br \/>\n**************************************************<br \/>\n** D O C B A S E I N F O **<br \/>\n**************************************************<br \/>\n--------------------------------------------<br \/>\n<strong>Docbase name : dmtest -- our docbase is here indeed;<\/strong><br \/>\nDocbase id : 50000<br \/>\nDocbase description : test docbase<br \/>\nGovern docbase :<br \/>\nFederation name :<br \/>\nServer version : 7.3.0000.0214 Linux64.Oracle<br \/>\nDocbase Roles : Global Registry<br \/>\nDocbase Dormancy Status :<br \/>\n--------------------------------------------<br \/>\n<\/code><br \/>\nThe dfc trace file however tells another story:<br \/>\n<code><br \/>\njava.net.ConnectException: Connection refused<br \/>\n5.234 N\/A N\/A [main] .DEBUG: IPV4 Address is: 192.168.56.12<br \/>\n<strong> 5.242 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 1 servers found. 0 content servers found<\/strong><br \/>\n5.242 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 0 bad servers found.<br \/>\n<strong> 5.244 N\/A N\/A [main] .DEBUG: IPV4 Address is: 192.168.56.12<br \/>\n5.249 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 1 servers found. 0 content servers found<\/strong><br \/>\n5.249 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 0 bad servers found.<br \/>\n5.252 N\/A N\/A [main] .DEBUG: IPV4 Address is: 192.168.56.12<br \/>\n<strong> 5.258 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 1 servers found. 0 content servers found<\/strong><br \/>\n5.259 N\/A N\/A [main] .DEBUG: Updated Server Choices for 'dmtest'. 0 bad servers found.<br \/>\n<strong> 5.259 N\/A N\/A [main] .WARN: [DFC_SESSION_RETRYING_OPEN] Retrying session establishment to \"dmtest\". Error was \"[DFC_SESSION_DOCBASE_UNREACHABLE] Docbase \"dmtest\" is unreachable\"<\/strong><br \/>\n<\/code><br \/>\nIntriguing. The <strong>localhost.localdomain<\/strong> reported above several times by the docbroker looks weird and prone to confusion. Local relative to what ? The client&#8217;s or the server&#8217;s host ? It is likely that after the idql client receives this information from the docbroker, it attempts a connection locally, which obviously cannot work, unless there happens to be a local dmtest docbase there too (which may explain why this error does not occur on the server side). The solution is quite self-evident: shut down the docbase and its docbroker, give a proper hostname to the content server&#8217;s VM, restart the docbroker and the docbase and attempt a new connection from the client VM. Et voil\u00e0 ! This time the connection is established successfully and without delay.<br \/>\nYou check dmqdocbroker again to see if it reflects the change:<br \/>\n<code><br \/>\n---- dmqdocbroker: (TARGET HOST: dmtest.cec) ----<br \/>\np) Ping (test connectivity to) the docbroker<br \/>\nd) Get a docbase map<br \/>\ns) Get a server map<br \/>\nn) Get next largest docbase id<br \/>\nl) lookup a docbase id<br \/>\no) find all open servers for a docbase<br \/>\nh) Set the host name for the docbroker<br \/>\ne) exit<br \/>\nEnter an option (i.e. letter)&gt; p<br \/>\n<strong>Successful reply from docbroker at host (dmtest.cec) on port(1490) running software version (7.3.0000.0214 Linux64).<\/strong><br \/>\n---- dmqdocbroker: (TARGET HOST: dmtest.cec) ----<br \/>\np) Ping (test connectivity to) the docbroker<br \/>\nd) Get a docbase map<br \/>\ns) Get a server map<br \/>\nn) Get next largest docbase id<br \/>\nl) lookup a docbase id<br \/>\no) find all open servers for a docbase<br \/>\nh) Set the host name for the docbroker<br \/>\ne) exit<br \/>\nEnter an option (i.e. letter)&gt; d<br \/>\n**************************************************<br \/>\n** D O C B R O K E R I N F O **<br \/>\n**************************************************<br \/>\n<strong>Docbroker host : dmtest.cec -- good !<\/strong><br \/>\nDocbroker port : 1490<br \/>\n<strong>Docbroker network address : INET_ADDR: 02 5d2 c0a8380c dmtest.cec 192.168.56.12<\/strong><br \/>\nDocbroker version : 7.3.0000.0214 Linux64<br \/>\n**************************************************<br \/>\n** D O C B A S E I N F O **<br \/>\n**************************************************<br \/>\n--------------------------------------------<br \/>\nDocbase name : dmtest<br \/>\nDocbase id : 50000<br \/>\nDocbase description : test docbase<br \/>\nGovern docbase :<br \/>\nFederation name :<br \/>\nServer version : 7.3.0000.0214 Linux64.Oracle<br \/>\nDocbase Roles : Global Registry<br \/>\nDocbase Dormancy Status :<br \/>\n--------------------------------------------<br \/>\n<\/code><br \/>\nYou pat yourself on the back and go for a well-deserved coffee.<\/p>\n<h4>More details<\/h4>\n<p>When I write that idql is slow to connect with the remote docbase, I mean it:<br \/>\n<code><br \/>\ntime idql dmtest -Udmadmin -Pdmadmin &lt;&lt;EoQ<br \/>\nquit<br \/>\nEoQ<br \/>\n1&gt; 2&gt; Bye<br \/>\nreal 26m4.512s<br \/>\nuser 0m5.672s<br \/>\nsys 0m0.548s<br \/>\n<\/code><br \/>\nAnd so is dmqdocbroker:<br \/>\n<code><br \/>\ntime dmqdocbroker -i &lt;&lt;EoQ<br \/>\ne<br \/>\nEoQ<br \/>\nEnter an option (i.e. letter)&gt;<br \/>\nEnter an option (i.e. letter)&gt;<br \/>\nreal 26m3.085s<br \/>\nuser 0m5.286s<br \/>\nsys 0m0.364s<br \/>\n<\/code><br \/>\nNormally, a successful connection should not take much more than few seconds:<br \/>\n<code><br \/>\ntime idql dmtest -Udmadmin -Pdmadmin &lt;&lt;EoQ<br \/>\nquit<br \/>\nEoQ<br \/>\n1&gt; 2&gt; Bye<br \/>\nreal 0m5.535s<br \/>\nuser 0m5.294s<br \/>\nsys 0m0.110s<br \/>\n<\/code><br \/>\nNotice how the system is practically idle, even during the long execution: the command is simply waiting for something, probably some random values according to the call trace file.<\/p>\n<p>The hack with the \/dev\/(.)?random nodes may also be applied by the shorter command below:<br \/>\n<code>sudo cp -lf \/dev\/urandom \/dev\/random<\/code><br \/>\nHowever, besides the inherent uncertainty in such system tempering, it needs to be repeated after each reboot of the VM because the pseudo-devices behind \/dev\/.?random gets remapped to the filesystem at boot time. Although it could be added in the startup scripts, a more permanent and much cleaner solution is to instruct java (we know now that there is some java lurking behind the command-line tools) to use the non-blocking device as per the note from Oracle cited below. In short, edit the file <strong>$DOCUMENTUM\/shared\/java64\/1.8.0_77\/jre\/lib\/security\/java.security<\/strong><br \/>\ncomment the line:<br \/>\n<code>#securerandom.source=file:\/dev\/random<\/code><br \/>\nand add the line instead:<br \/>\n<code>securerandom.source=file:\/dev\/urandom<\/code><br \/>\nIn effect, since Documentum v6.x the commands iapi, idql and dmawk (which is invoked by dmqdocbroker) are just binary stubs that invoke the java back-end installed in $DOCUMENTUM\/shared\/java64. Fortunately, this slowness issue has been tackled since long for the java and the parameter <strong>securerandom.sourcefile<\/strong> has been introduced for this purpose. After the change has been applied, the trace file shows that this device is effectively used instead of \/dev\/random:<br \/>\n<code><br \/>\nopen(\"\/dev\/urandom\", O_RDONLY) = 65<br \/>\nfstat(65, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0<br \/>\nread(65, \"Q\\315s\\37\\35T\\243\\217\\216\\355Q\\250N.\\217\", 20) = 20<br \/>\n...<br \/>\n<\/code><br \/>\nAnd a tail -f on the trace file does not show any pause at the read() call any more.<br \/>\nAlso, here we cannot pass the property <strong>java.security.egd<\/strong> (an alternative solution) because we don\u2019t start the java subsystem ourselves; it is used invisibly behind the scene by the commands iapi and idql (actually, the library libdmcl.so they are linked with). Moreover, as said before, no JVM process gets started. Is there some sort of JIT compilation going on here ? This is a good question to ask OpenText Support.<br \/>\nIf the command-line tools passed along the environment variable $DEVRANDOM to the java layer with the effect to override the setting <strong>securerandom.sourcefile<\/strong> in the security file, the issue would be solved. This too is a good suggestion for OpenText.<\/p>\n<p>Interestingly, in my laptop&#8217;s VM with the Centos v7.0.1406 and the test docbase, a daemon rngd wakes up sometimes quite noisily:<br \/>\n<a href=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-22630\" src=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png\" alt=\"rngd\" width=\"300\" height=\"18\" \/><\/a><br \/>\nIts man page says it all:<br \/>\n<code><br \/>\nRNGD(8) System Manager's Manual NAME<br \/>\nrngd - Check and feed random data from hardware device to kernel random device<br \/>\n<\/code><br \/>\nLots of information are also available for this service on the web. If this daemon is stopped on the content server VM, the same issue as on the client VM raises its ugly head too. Again, \/dev\/random is read repeatedly with long pauses in between. Again, switching to \/dev\/urandom in $DOCUMENTUM\/shared\/java64\/1.8.0_77\/jre\/lib\/security\/java.security fixes it. The presence of this daemon explains why the issue was not encountered on the server although java was using the default \/dev\/random device. Could such a service be used in the client VM too to feed \/dev\/random and avoid it to block until it collects enough entropy ? As a matter of fact, yes. When this process is started by the following test command:<br \/>\n<code><br \/>\nsudo rngd -f -o \/dev\/random -v &amp;<br \/>\n<\/code><br \/>\nor installed from scratch on the client VM (remember, our client runs under Ubuntu, a Debian off-spring which explain why we are using apt-get instead of yum; also, the package installation automatically starts the rngd daemon):<br \/>\n<code><br \/>\nsudo apt-get install rng-tools<br \/>\n<\/code><br \/>\n\/dev\/random no longer blocks as it is visible in the command-line tools&#8217; trace file and through the command &#8220;cat \/dev\/random | od -A d4&#8221; for example.<br \/>\nClearly, the added overhead of setting up and running such a daemon vs. a simple parameter change in a configuration file is only acceptable in special cases, e.g. the application is not a java one, it has no choice but use \/dev\/random, the hack to make it point to \/dev\/urandom is a no-go, and it is affected by the blocking issue.<\/p>\n<p>The second error message, the <strong>DFC_DOCBASE_UNREACHABLE<\/strong>, is a puzzling one too. In the present case, it went away quite easily but later, after my test VMs were restarted, it came back and it took me hours to expunge it. The VM with the content server was still using the default hostname &amp; domain <strong>localhost.localdomain<\/strong>. Documentum recommends to give the host a proper name and domain. After this correction was made on the Centos VM using the command below:<br \/>\n<code><br \/>\nsudo sysctl -w kernel.hostname=myhost<br \/>\n<\/code><br \/>\nand verified with:<br \/>\n<code><br \/>\nsysctl -n kernel.hostname<br \/>\n<\/code><br \/>\nor simply:<br \/>\n<code><br \/>\nhostname<br \/>\n<\/code><br \/>\nand the docbase restarted, remote connections were possible again. The used command &#8220;sudo hostname dmclient&#8221; does not save the hostname into \/dev\/hostname so the change only lasts until the next reboot. Either edit that file manually or use the sysctl command under Centos. So, make sure that all the system changes be permanently saved otherwise they will be lost at the next reboot.<\/p>\n<p>Admittedly, the two issues discussed here are very unlikely to occur in most organizations where the machines are properly set up by trained staff, from the O\/S, the network and up to the java layer. It&#8217;s a different situation with local VMs, especially ones with default configurations.<\/p>\n<p>Interestingly, this \/dev\/random issue does not occur with the old, all binary, non java version of Documentum, e.g. v5.3: it is able to connect to a v7.3 docbase right away, no question asked, which confirms that the issue is a java one. It is still helpful to have one such old release handy for those hard to diagnose cases !<\/p>\n<h4>References<\/h4>\n<p><a title=\"Force use of \/dev\/urandom\" href=\"https:\/\/security.stackexchange.com\/questions\/14386\/what-do-i-need-to-configure-to-make-sure-my-software-uses-dev-urandom\" target=\"_blank\">https:\/\/security.stackexchange.com\/questions\/14386\/what-do-i-need-to-configure-to-make-sure-my-software-uses-dev-urandom<\/a><br \/>\n<a title=\"Oracle note java.security\" href=\"https:\/\/docs.oracle.com\/cd\/E13209_01\/wlcp\/wlss30\/configwlss\/jvmrand.html\" target=\"_blank\">https:\/\/docs.oracle.com\/cd\/E13209_01\/wlcp\/wlss30\/configwlss\/jvmrand.html<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The journey begins In a VM Oracle VirtualBox with Centos Linux 7.0, you install Documentum v7.3 and create a docbase dmtest\u00a0with its schema in a database on another VM running Oracle Linux. You start the newly created docbase and successfully connect locally to it from within iapi or idql. You smile with satisfaction and go [&hellip;]<\/p>\n","protected":false},"author":40,"featured_media":11090,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[525],"tags":[],"type_dbi":[],"class_list":["post-11089","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-content-management"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.4) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>Another surprising journey in Documentum-land - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Another surprising journey in Documentum-land\" \/>\n<meta property=\"og:description\" content=\"The journey begins In a VM Oracle VirtualBox with Centos Linux 7.0, you install Documentum v7.3 and create a docbase dmtest\u00a0with its schema in a database on another VM running Oracle Linux. You start the newly created docbase and successfully connect locally to it from within iapi or idql. You smile with satisfaction and go [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-04-19T14:12:40+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-24T07:13:59+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png\" \/>\n\t<meta property=\"og:image:width\" content=\"2505\" \/>\n\t<meta property=\"og:image:height\" content=\"151\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Middleware Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Middleware Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/\"},\"author\":{\"name\":\"Middleware Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\"},\"headline\":\"Another surprising journey in Documentum-land\",\"datePublished\":\"2018-04-19T14:12:40+00:00\",\"dateModified\":\"2025-10-24T07:13:59+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/\"},\"wordCount\":1865,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/rngd.png\",\"articleSection\":[\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/\",\"name\":\"Another surprising journey in Documentum-land - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/rngd.png\",\"datePublished\":\"2018-04-19T14:12:40+00:00\",\"dateModified\":\"2025-10-24T07:13:59+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/rngd.png\",\"contentUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/rngd.png\",\"width\":2505,\"height\":151},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/another-surprising-journey-in-documentum-land\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Another surprising journey in Documentum-land\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d8563acfc6e604cce6507f45bac0ea1\",\"name\":\"Middleware Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"caption\":\"Middleware Team\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/middleware-team\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Another surprising journey in Documentum-land - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/","og_locale":"en_US","og_type":"article","og_title":"Another surprising journey in Documentum-land","og_description":"The journey begins In a VM Oracle VirtualBox with Centos Linux 7.0, you install Documentum v7.3 and create a docbase dmtest\u00a0with its schema in a database on another VM running Oracle Linux. You start the newly created docbase and successfully connect locally to it from within iapi or idql. You smile with satisfaction and go [&hellip;]","og_url":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/","og_site_name":"dbi Blog","article_published_time":"2018-04-19T14:12:40+00:00","article_modified_time":"2025-10-24T07:13:59+00:00","og_image":[{"width":2505,"height":151,"url":"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png","type":"image\/png"}],"author":"Middleware Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Middleware Team","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/"},"author":{"name":"Middleware Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"headline":"Another surprising journey in Documentum-land","datePublished":"2018-04-19T14:12:40+00:00","dateModified":"2025-10-24T07:13:59+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/"},"wordCount":1865,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png","articleSection":["Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/","url":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/","name":"Another surprising journey in Documentum-land - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png","datePublished":"2018-04-19T14:12:40+00:00","dateModified":"2025-10-24T07:13:59+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/rngd.png","width":2505,"height":151},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/another-surprising-journey-in-documentum-land\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Another surprising journey in Documentum-land"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1","name":"Middleware Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","caption":"Middleware Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/middleware-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11089","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=11089"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11089\/revisions"}],"predecessor-version":[{"id":41163,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11089\/revisions\/41163"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/11090"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=11089"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=11089"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=11089"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=11089"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}