Validate Store

Syntax

validate store STORE_NAME |file FILENAME                                                |;
                          |fcsfileexist [prefix PREFIXNAME] [file FILEFILE] [indexmode] |
                          |fcsorphanfileexist [prefix PREFIXNAME]                       |
                          |fcsorphanfiledelete [prefix PREFIXNAME]                      |

For more information, see validate Command.

Validate Store Using an Input File

For multiple directory stores/locations (the default for captured and hashed stores), the input file can be created from the captured store directory using the following command from the store directory on Unix:

find -type f -print

For example, your file might look like:

./00/b3/00b30d7774254606.b27 
./0036a01d.6ff 
./01/11/01119e1b826a714e.0fb

From a DOS prompt on Windows, the input file can be created from the output of:

dir /s /b /a-d 

And to send the output to a file:

dir /s /b /a-d  > c:\temp\files.txt

On Windows you need to remove the drive and store directory from each file listed. For example, for a store named “distribs” you might have output similar to:

D:\distribs\00\b3\00b30d7774254606.b27 
D:\distribs\0036a01d.6ff 
D:\distribs\01\11\01119e1b826a714e.0fb

You would need to search on “D:\distribs\” and delete.

Once the input file is created, System Administrators can use the following command:

validate store NAME file FILENAME;

• NAME is the name of a captured store.
• FILENAME is an input file that lists all files in a captured store or location directory.

The validate store command creates a file called FILENAME.out (the same name as was used for the input filename, except with a file extension of .out), which lists files that are not associated with business objects. You can then cleanup the store or location directory by deleting these files.

Validating That a File Exists in the FCS

You can use the Validate Store command to verify that a file exists.

validate store STORE_NAME fcsfileexist [prefix PREFIXNAME] [file FILENAME]  [indexmode];

• STORE_NAME is the store to check.
• PREFIXNAME narrows the scope of the operation.
• FILENAME is the name of the file to validate.
• indexmode can be one of these values:
  • noindex - (default) the command executes the file existence check without using a file index.
  • index - the command process the file index if it exists and if it is valid. If the file index does not exist, processing with using an index.
  • forceindex - the command allows processing only if the file exists and is valid.

Validating Orphan Files in FCS

Orphan files could sometimes exist due to an unsuccessful delete. You can search for the orphan files, and you can delete those files. This command does not operate of files less than 24 hours old to avoid problems with newly checked-in files that do not yet have a database record.

validate store STORENAME fcsorphanfileexist [prefix PREFIXNAME];
validate store STORENAME fcsorphanfiledelete [prefix PREFIXNAME];

• The fcsorphanfileexist keyword generates a list of files that have no database reference.
• The fcsorphanfiledelete keyword finds, displays, and removes files that have no database reference.
• The PREFIXNAME narrows the scope of the operation.

Monitoring Disk Space

As a System Administrator, you should monitor the disk space available to your stores carefully. If disk space is running low, you could simply change the path or host of the store, but then you would have to move all checked-in files to the new directory, or users would receive errors when trying to access the files. A better solution is to change the store that the policies use.

To replace an existing store:

1. Use the following MQL command:

   modify store STORE_NAME lock;

2. Create a new store with a host and path that has ample disk space.
3. Determine which policies use the store that needs to be replaced.
   1. In MQL, run the following command:

      list policy * select name store dump |;

      The results will look something like:

      CMM|ObjectModel|ProductCritical Report|SubmissionIncident|Submission2Sequencer
      |ObjectMedia|ProductTask|ObjectMarketing Documents|DocumentKit|Product
      ...

   2. Copy the list and paste it into a text editor.
   3. Create a table and sort by the policy column.
4. Modify the policies that use the filled up store to use the newly defined store.
5. Unlock the original store.

New files checked into objects governed by these policies will be put in the new store. Files that were checked in previously can still be checked out and opened for view, but if new files are checked in, the new store is used. For more information, see Implications of Changing Stores.