The daily edition.

Scope and Architectural Overview

This article covers resource serialization and cluster locking in Rocket Enterprise Developer / Enterprise Server 12.0 for Linux/UNIX.

In traditional Enterprise Server clusters, cross-region resource locking and concurrency control were managed by a Global Lock Manager (GLM)—a dedicated server region tasked with arbitrating global lock requests. Operating a GLM required configuring Intersystem Communication (ISC) links between all participating server regions.

When an enterprise environment transitions to hosting catalogs, spool queues, and data files within a relational database using the Rocket Database File Handler (DBFH), the locking architecture fundamentally shifts. The GLM and its underlying ISC links are replaced by the LOCKDB feature, as detailed in Enterprise Server LOCKDB. Under LOCKDB, lock serialization (ENQs and DEQs) across CICS, JES, and IMS workloads is coordinated directly at the RDBMS layer by MFDBFH, eliminating the operational overhead and single-point-of-failure risk of a dedicated GLM region.

The Division of ENQ Scope: Region DB vs. Cross-Region DB

To support high-throughput concurrency without cross-system deadlocks or lock corruption, DBFH divides resource locking across two distinct database abstractions documented in Resource Locking:

1. Region Database (type="region.cas"): Dedicated to a specific enterprise server region. It processes all step-scoped and system-scoped ENQ requests originating within that server instance.
2. Cross-Region Database (type="crossregion.cas"): Shared across multiple regions within the cluster. It facilitates cluster-wide synchronization by processing system-scoped ENQ requests.

This dual-tier structure is essential for batch and online workload coordination:

• It permits batch jobs sharing identical job names to execute concurrently across different regions without collision.
• It prevents concurrent access conflicts on datasets allocated with exclusive or modifying dispositions (DISP=OLD, DISP=NEW, or DISP=MOD) across JCL streams executing in separate regions.

Configuration Workflow: mfdbfh.cfg and Environment Variables

Configuring a LOCKDB cluster requires coordinating database definitions inside the DBFH configuration file (mfdbfh.cfg) with runtime environment variables outlined in Database File Handling Environment Variables.

The configuration file must define a <server> block containing one shared cross-region database DSN and a distinct region database DSN for each region participating in the cluster:

<?xml version="1.0" encoding="utf-8" ?>
<!-- DBFH server and database configuration -->
<datastores usevault="false">
    <server name="MYSERVER" type="db2" access="odbc">
        <dsn name="CrossRegion" type="crossregion.cas" dbname="REGNDEV" connect="db=REGNDEV;uid=myuser;pwd=mypassword" />
        <dsn name="Region1" type="region.cas" region="DEVL1" dbname="REGNDEV" feature="all" connect="db=REGNDEV;uid=myuser;pwd=mypassword" />
        <dsn name="Region2" type="region.cas" region="DEVL2" dbname="REGNDEV" feature="all" connect="db=REGNDEV;uid=myuser;pwd=mypassword" />
        <dsn name="Region3" type="region.cas" region="DEVL3" dbname="REGNDEV" feature="all" connect="db=REGNDEV;uid=myuser;pwd=mypassword" />
        <dsn name="VSAM" type="datastore" dsname="VSAM" connect="db=VSAM;uid=myuser;pwd=mypassword" />
    </server>
</datastores>

Each enterprise server region in the cluster must define three core environment variables:

• ES_DB_FH=Y: Activates the Database File Handler layer.
• ES_SERVER=MYSERVER: Specifies the database server block from mfdbfh.cfg that houses the region and cross-region databases.
• ES_LOCKDB=<region-db>: Identifies the specific region database instance assigned to handle locking for that server. The parameter must be alphanumeric; otherwise, Enterprise Server rejects the setting.

In a 3-region deployment using the configuration above:

• Region 1 sets ES_SERVER=MYSERVER and ES_LOCKDB=DEVL1
• Region 2 sets ES_SERVER=MYSERVER and ES_LOCKDB=DEVL2
• Region 3 sets ES_SERVER=MYSERVER and ES_LOCKDB=DEVL3

Operational Nuances, Startup Sequencing, and Tooling

Operating a LOCKDB cluster introduces several critical behaviors that differ sharply from legacy setups:

1. Why Region Databases Cannot Be Shared

A region database is cold-started whenever the enterprise server that references it is started. During this cold start, the database engine drops and reinstalls all associated DBFH database objects. If two running regions were configured with the same ES_LOCKDB value, the startup of the second region would wipe out active locks held by the first. To prevent silent lock corruption, Enterprise Server enforces uniqueness during initialization: if a region detects that its assigned region database is already active on another server, startup fails immediately and logs an error to the console.

2. Strict Startup Sequencing

In a LOCKDB group, the very first enterprise server region must be cold-started to establish the shared database tables:

casstart -rLOCKDB1M -S:C

Subsequent cluster members must then be started normally without cold-start switches:

casstart -rLOCKDB2M

Executing a cold start on subsequent regions destroys active locks and leads to unexpected runtime failures.

3. Administrative and Monitoring Changes

• CASLOCK Command Deprecation: The legacy CASLOCK command line tool cannot be used to monitor or manipulate locks in a LOCKDB group.
• ESCWA Live Region Locks: Active lock status must be verified using Region Monitor and Control (RMC) within Enterprise Server Common Web Administration (ESCWA) via the Live Region Locks interface.
• Resource Name List (RNL): Support for RNL is preserved to identify SYSZDSN lock scope, and the RNL definition file itself can be hosted in the database.
• VSAM Shareoptions: VSAM file shareoptions remain fully supported within a LOCKDB group.

4. Behavior in Performance and Availability Clusters (PAC)

In a Performance and Availability Cluster (PAC), LOCKDB management is handled implicitly by the PAC infrastructure. All regions within a PAC share a single region database for ENQs. Setting ES_LOCKDB in a PAC environment is unnecessary and triggers console warning CASSI1458W MFDBFH LOCK management support is implicit in the PAC, ES_LOCKDB bypassed., where the runtime automatically bypasses the explicit variable.

Documentation Takeaway

In Rocket Enterprise Server clusters using DBFH, cross-region resource locking replaces the GLM by assigning step- and system-scoped ENQs to dedicated per-region databases and cluster-wide system ENQs to a shared cross-region database; because cold starting drops and reinstalls region database objects, each region requires a distinct ES_LOCKDB assignment, only the cluster's first region may be cold-started, and all active lock inspection shifts from CASLOCK to ESCWA's Live Region Locks.