The types 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 types of database that you must configure.
It is possible that you would have more than one instance of these resources, and these can each be configured as separate
databases, or preferably, you can house them all in one single database. Using one single database has performance benefits;
for example, you can use the same database connection to access all resources
(datastores, region and cost-region databases)
stored in the same database; see
Database Connections for more information.
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
dbfhadmin -script command line utility, you can create script files to run against your database that create the new datastores. Once created,
you can upload existing files to the datastore.
Note: For all database types except Oracle, datastores can also be created implicitly if your application opens a data file specifying
a datastore that doesn't currently exist; however, it is good practice to create the required datastores explicitly beforehand,
using the script files or the
dbfhadmin -createdb command. For Oracle datastores, the underlying database for the datastore must already exist beforehand.
- 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. If your application was working correctly with the data files before they were moved to a database, your source code will
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"/>
|
- 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, its MFDBFH objects are dropped and recreated afresh.
- See
Configuring Region and Cross-Region Databases for each database type, 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 created
with
dbfhadmin -script.
- See
Configuring Region and Cross-Region Databases for more information.