Database Management and Recovery

Use the dbfhadmin command-line tool to recover resources from region, cross-region, and datastore databases in the event of a system failure.

If an enterprise server process terminates abnormally, database resources used by the process (for example, resource locks, open file handles, and record locks) may not get freed up correctly.

In the case of region and cross-region databases, use the -list option with the -casprocess action to display all processes currently registered in a CAS cross-region database. Any processes displayed with an "In doubt" status need to be recovered. Processes get registered when an enterprise server process (for example: casmgr and cassi) initialise use of a region database. Processes get de-registered when an enterprise server process terminates normally. If a process is killed, or abnormally terminates, its associated process record in the cross-region database does not get removed. When the processes are listed, all active ones (i.e. registered, but not yet terminated) have an "Ok" status, whereas any process that has been killed, or abnormally terminated, will have an "In doubt" status. Any process with an "In doubt" status could potentially still be owning region database resources.

Similarly, you can use the -list option with the -region action to display a list of resource locks for a specified region or entire database server instance. If any files are erroneously locked (that is, not recovered correctly after a system failure), you can free them using the -recover action.

For database-hosted data files, use the -list action to display any data files still open. After ensuring that the host machine or (if specifying a process id) the process is no longer running, use the -recover option on any files that are still open. When files are forced closed, their file handles are removed from the datastore database and any associated record locks released.

You can also use the dbfhadmin command-line tool to manage the column types that correspond to the primary and alternate keys of your indexed files. This management is required when creating indexed data files independently of COBOL programs (for example, when using the CFCR CICS transaction or using the JCL MFJAMS utility), as there is no mechanism to generate the key type definitions, and so when those files are created in the datastore, each column type is binary. The -keytypes action of dbfhadmin enables you to inject different key types for a file's indexed keys. You will also need to use dbfhadmin to define key type definition if your indexed files were created via COBOL programs that were not compiled with the IXNUMKEY Compiler directive.

Upgrading datastores: Periodically, MFDBFH may need to upgrade an existing datastore to fix a problem, or provide the necessary support for new functionality. In most circumstances, the upgrade occurs automatically when a new version of MFDBFH detects that the datastore that it is running with does not support the latest level of functionality. However, it is possible that the upgrade process may fail if the currently connected user does not have sufficient database privileges to perform the operation. When this happens, MFDBFH outputs the following message to the console, indicating that a manual upgrade is required:

DBFH00034S MFDBFH failed to upgrade the datastore. Manual upgrade required. Use 'dbfhadmin -upgrade -datastore <datastore-url>' to generate an upgrade script and run the script as a user with sysadmin privileges