The dGB software uses a mechanism to access data involving an Object Management System (OMS). This system manages the information needed to access data in the dGB_DATA directories or from other data stores. This access information is stored in a separate "meta"-datastore.

The OMS uses a flat file approach to store this access information. Compared to a 3rd party database this has the advantage of simplicity, independence of extra systems to manage, and transparency. On the downside, however:

- The UNIX file permissions must be right; users of the software must have read and write access to the survey directories and files.

- The system is probably less robust in the presence of file system trouble.

In the case of file system trouble, one or more of the information storage files '.omf' in the survey directory, or in one of the survey's subdirectories may be damaged. If the main .omf is damaged, you will usually not even be able to reach Grid, Seismics, etc. subdirectories from within the software. If a subdirectory's .omf is damaged, you may be unable to reach a type of object.

In any case, you'll have to find out which .omf causes the trouble. In general, if something damages your .omf, you'll have to put a backup back in place. in V2.7.2 and higher you may first try to rename .omf to .omf.damaged ('mv .omf .omf.damaged'). the OMS will try to read a .omf, and if there is none it will try the back-up '.omb' . If it finds that, it will proceed as if nothing happened.

Because the .omf in the survey root is so important, you may want to give extra protection to its .omf if know you are not going to create more Dictionaries and/or Frameworks. Then you can make .omf read-only:

chmod -w .omf