Types of Database

Attention: This feature is in Early Adopter Product (EAP) release status. We will continue the development of additional features and provide additional interfaces via patch updates and future releases. Please contact Micro Focus SupportLine if you require further clarification.

The type of information that you plan to store within a database when utilizing the Micro Focus Database File Handler (MFDBFH) or enterprise server region management determines the type of database that you must configure. It is likely that you would have more than one of these configured simultaneously.

The table below shows the types of database available, and when you are likely to use them:

Datastore database

A datastore database is designed to store any of the following data file types: KSDS, RRDS, ESDS, line-sequential, and fixed- and variable-length sequential files.

Using the dbfhdeploy command line utility, you can create new datastores, and then upload existing files to the datastore.

Note: Datastores can also be created implicitly if your application opens a data file specifying a datastore that doesn't currently exist; although, it is good practice to create the required datastores explicitly, using dbfhdeploy.

Refer to the Configuring Datastores section for details on how to place new and existing data files in a database, and then depending on the type application that is to use the files, refer to Configuring CICS Applications for Native Database File Handling and Configuring the JCL Environment for Native Database File Handling. Regardless of the type of application, your source code does not need to be altered/recompiled to be able to use datastore files.

However, if your applications are transactional, an additional XA resource is required to interact with the datastore. If you have COBOL applications that also use the same database (that contains the datastore), you'll need to configure multiple XA resources and then ensure the correct XAR is used in the correct scenario - refer to Working with Multiple XARs for details on how to handle such situations.

Region database

A region database contains tables and stored procedures that support certain features of a particular enterprise server region. The feature attribute, specified in the <dsn> element of the configuration file, determines the features currently being supported by the region database. (Resource locking - that is, ENQ/DEQ processing - is currently the only feature available.)

The following table shows the features that you can enable/disable within the configuration:

Value	Description	Example
all	All available region features	<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="all"/>
none	No region features	<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="none"/>
[+\|-]reslocking	Enable/disable database resource locking	<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="none +reslocking"/> <dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="all -reslocking"/>

Value

Description

Example

all

All available region features

<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="all"/>

none

No region features

<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="none"/>

[+|-]reslocking

Enable/disable database resource locking

<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="none +reslocking"/>

<dsn name="SS.CAS.ESDEMO" type="region.cas" region="ESDEMO" feature="all -reslocking"/>

If you omit the feature attribute from the <dsn> element, feature=all is assumed.

Features are stored as tables and stored procedures within the region database. There is no visible change to the data processing or operation of a region that is configured to use such a database.

Once configured, you are required to cold-start the region, where the region database will be created on startup. If the database already exists, it is dropped and recreated afresh.

See Configuring Region and Cross-Region Databases for more information.

Cross-region database

A cross-region database facilitates functionality that is used across more than one enterprise server region. This can include such things as support for systems-scoped ENQ requests and recovery processing.

A cross-region database is required if you have also configured a region database, and must be configured on the same database server. If it does not already exist, it is created when the enterprise server region specified in your region database configuration is cold started; although, it is preferable that you create the database ahead of time, using database script files.

See Configuring Region and Cross-Region Databases for more information.