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"/>
|
- 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.