Problem:

Enterprise Server fails to start and the console.log shows these kinds of messages:

     061120 00163142      17405 ESDEMO   CASSI4005I Retrieving ES configuration from MFDS

  <console.log.200611210751>

     061121 00165393      26607 ESDEMO   CASSI4003W Error (NO_SUCH_OBJECT)

  <console.log.200611210755>

     061121 07561106      23747 ESDEMO   CASSI4003W Error (NO_SUCH_OBJECT)

  <console.log.200611210825>

     061121 07561101 CASSI4005I Retrieving ES configuration from MFDS (127.0.0.1:86)

  <console.log.maki1121>

     061121 07561106      061121 07561101 23747 ESDEMO   CASSI4003W Error (NO_SUCH_OBJECT)

   retrieving ES configuration from MFDS

When the repository directory is checked, some of the files in the repository directory are renamed by adding "1" at the beginning of the name like 1pkg.dat,  whereas .tmp is appended at the end of the name of others, for example pkg.dat.tmp:

$COBDIR/etc/mfds

...

-rw-r--r--   1 root     other        824 11/21  00:15 1ccs.dat

-rw-r--r--   1 root     other       1644 11/21  00:15 1lis.dat

-rw-r--r--   1 root     other     160080 11/21  00:15 1pkg.dat

-rw-r--r--   1 root     other       1611 11/21  00:15 1rqh.dat

-rw-r--r--   1 root     other       1078 11/21  00:15 1srv.dat

-rw-r--r--   1 root     other     107941 11/21  00:15 1svc.dat

-rw-r--r--   1 root     other          0 11/21  00:15 1xrm.dat

drwxr-xr-x   4 root     root         512  5/20/2005 IVP

-rw-r--r--   1 root     other        824 11/21  00:15 ccs.dat.tmp

-rw-r--r--   1 root     other       1644 11/21  00:15 lis.dat.tmp

-rw-r--r--   1 root     other     160080 11/21  00:15 pkg.dat.tmp

-rw-r--r--   1 root     other       1611 11/21  00:15 rqh.dat.tmp

-rw-r--r--   1 root     other       1078 11/21  00:15 srv.dat.tmp

-rw-r--r--   1 root     other     107941 11/21  00:15 svc.dat

-rw-r--r--   1 root     other          0 11/21  00:15 xrm.dat.tmp

Resolution:

The message "CASSI4003W Error (NO_SUCH_OBJECT)" in console.log is due to not being able to find the enterprise server configuration information in srv.dat. If you attempt a casstart -r[name] and there is no corresponding [name] entry in srv.dat then "CASSI4003W Error (NO_SUCH_OBJECT)" will be the consequence.

The Micro Focus Directory Server (MFDS) is renaming the files ("1" or ".tmp" addition) when it writes to the repository. It writes to the repository every time there is a change in any of the values of the configuration items it maintains (e.g. server status, listener status, etc.).  Most often this occurs when an enterprise server instance is starting up, or shutting down. The sequence is as follows:

1) Write the current, changed information to [tid]*.dat files, so both the old and updated dat files now exist in parallel, but the old .dat files are still the ones that would be used if MFDS is re-started.

2) Rename the existing *.dat files to [tid]*.dat.tmp so that if MFDS was re-started now, it would not be able to find the *.dat repository file.

3) Rename the new [tid]*.dat files to *.dat so that the updated .dat files have replaced the old .dat files, and these are the ones that would be used if MFDS was re-started.

4) Remove the now redundant [tid]*.dat.tmp files in an effort to clean up the files.

In normal operation you should not see [tid](.dat or [tid]*.dat.tmp files. If the MFDS process is terminated somewhere in the above sequence, the repository write cannot completed. You will need to take recovery action (see below).

The usual reason for this state of affairs is if MFDS is killed externally (say, by using "kill") and enterprise servers are still active and changes are being made to the server configuration within MFDS.  Care should be taken to not shutdown MFDS while servers are starting or stopping, and preferrably not while they are otherwise active (although they would not normally be causing repository writes in that case, the MFDS Server Monitor will intermittently check whether a started server is responsive or not, and may switch the state to "Started" or "Not Responding", and this can cause a repository write).

The MFDS GUI "Shutdown" option should stop MFDS cleanly, and in the upcoming Net Express 5.0 WS02 there will be an "mfds -s" command line option which also requests a clean MFDS (and any started Enterprise Servers) shutdown.

If you currently use an automated MFDS shutdown that uses some sort of process-killing method then you need to ensure that all the started enterprise server are shutdown first, and are in a stopped state, before terminating MFDS.  The stop-gap method of doing this is just ensuring that sufficient time elapses between issuing the casstop and the MFDS shutdown, a much better way is to ensure the CAS processes have actually shut down, either by some sort of process monitoring or using MLDAP-enabled tools (e.g. mdump) that query MFDS as to the state of the enterprise server instances.

One method of recovery is renaming the files in the repository directory to the correct names. Another method is restoring a backup of the repository (a backup should be made whenever significant changes are made that should not be lost).