Defining, Generating, and Punching a DMCL

The DMCL is the runtime component that describes one or more physical databases. The DMCL:
The DMCL is the runtime component that describes one or more physical databases. The DMCL:
  • Designates which physical databases are accessible at runtime
  • Describes the files used to journal database activities
  • Specifies buffers for database and journal files
  • Designates which areas are to be shared across members of a data sharing group
  • Specifies attributes that affect data sharing operations
What a DMCL Contains
A DMCL contains the following component definitions:
Database buffers
Hold database pages in memory while CA IDMS/DB accesses information on the pages.
Journal buffer
Maintains information to be written to journal files, which are used for recovery operations. One and only one journal buffer must be defined for a DMCL.
Journal files
Log database activity. You can define either disk and archive journal files or a tape journal file.
Contain the areas of the database and the files to which those areas map.
DMCL Area/File Overrides
A DMCL definition can also override area and file definitions in the segments added to the DMCL.
Designating Areas as Shared
The DMCL indicates which areas are eligible to be shared for update across members of a data sharing group. Sharability can be specified for an entire segment or for an individual area through an area override.
DMCL Identifies Database Name Table
A DMCL also identifies the database name table to be used at runtime. The database name table provides logical names for one or more segments associated with the DMCL.
Order of Component Definition
To define a DMCL and its components, issue the following statements in the listed order:
  4. Either:
  5. Or
  6. ALTER DMCL, adding segments and optionally, any area and file overrides
DMCL Used Under the Central Version
All applications that execute under the central version use a single DMCL.
DMCL Used in Local Mode
An application that uses local mode database services may use the same DMCL used under the central version or a DMCL tailored for local mode operations. You can define as many local DMCLs as you wish. However, generally a local mode DMCL should be created only for the following reasons:
  • To execute a local mode update application with journaling activated
  • To reduce core requirements in your local mode address space by reducing the number of segments in the DMCL
  • To use a different page reserve or buffer size for special processing such as load operations
Differences Between Central Version and Local Mode DMCLs
The table below highlights the main differences between a DMCL used under the central version and a DMCL used only in local mode:
DMCL used under CV and in local mode
Local mode-only DMCL
Buffer size
Typically large for central version operations to accommodate concurrent processing and small for local mode operations to accommodate 1 application
Typically small, to accommodate 1 application
Journal files
2 or more disk journal files and 1 or more archive files
1 tape journal file
DMCL Defined in Shared and Memory Cache
Shared cache can only be used under the central version, but not for local mode processing. 
Memory cache can be used for both central version and local mode processing. 
Under the central version, if both shared and memory cache are specified, shared cache is chosen. If the shared cache open fails, no attempt is made to open memory cache.
DMCLs Used for Data Sharing
In a data sharing environment, more than one central version may share the same DMCL. If all members of a data sharing group are identical with respect to the data that they access, then they should share the same DMCL. This type of group is referred to as a homogeneous group.
If members of a group share access to only a subset of data, they may use different DMCLs. This type of group is referred to as a heterogeneous group.
The choice of whether members of a data sharing group use the same DMCL is a matter of convenience and does not affect the operation of the group. However, if different DMCLs are used, they should all specify the same data sharing attributes.
Stored as a Load Module
Because the DMCL is a runtime component, its definition must be generated and stored as a load module, and then punched and link-edited to a load library.
Identifying the DMCL to the Runtime System
You must identify the DMCL to be used in the runtime system:
  • Under the central version, specify the name of the DMCL to be used as a startup parameter for the DC/UCF system. See the 
    Administrating section
     for information on startup parameters.
  • In local mode, if the name of the DMCL is not IDMSDMCL, specify the name in the SYSIDMS parameter file.