IN FOCUSES_LOCKDB Is Per Region in a Typical Cluster—but Shared Across a PAC
Rocket Enterprise Server 12.0 on UNIX replaces GLM-style locking with MFDBFH region and cross-region databases. Typical clusters require a unique ES_LOCKDB region database per server because cold start rebuilds its objects, while PAC uses a single region database for all member regions. [1] [2]
Read the full briefing
Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX; MFDBFH-backed resource locking for enterprise server regions.
When catalog and spool queues are stored in a database, database-backed locking replaces the Global Lock Manager model. The division of responsibility is specific: region databases process step- and system-scoped ENQs, while a cross-region database processes system-scoped ENQs. This supports controls such as allowing same-named jobs on different regions while preventing concurrent access to JCL data sets allocated with DISP=OLD, NEW, or MOD (Resource Locking).
For a typical cluster, each region must point ES_LOCKDB at its own region database defined in the active MFDBFH configuration file. A three-region configuration therefore uses three region.cas entries, with settings such as:
Region DEVL1: ES_LOCKDB=DEVL1
Region DEVL2: ES_LOCKDB=DEVL2
Region DEVL3: ES_LOCKDB=DEVL3
ES_SERVER=MYSERVERES_SERVER identifies the MFDBFH server entry that owns those region databases. The uniqueness requirement is operational, not merely organizational: a region database is cold-started when its associated server starts, and that cold start drops and reinstalls its database objects. If another server shared that region database, its locks could be lost. Enterprise Server checks for this conflict at startup; a non-unique region database causes startup to fail and records the failure in the console log. A PAC is the documented exception: all regions in a Performance and Availability Cluster require only one region database for their step- and system-scoped ENQs (Resource Locking).
The broader LOCKDB feature routes CICS, JES, IMS, and other ENQs through MFDBFH, and its members do not need the ISC links formerly required by GLM configurations. For a LOCKDB group, the first region must be cold-started—for example, casstart -rLOCKDB1M -S:C—but subsequent regions are started normally. The documentation warns that cold-starting those subsequent regions produces unexpected behavior. Active locks are viewed in ESCWA on the Live Region Locks page; CASLOCK cannot be used for a LOCKDB group (Enterprise Server LOCKDB).
For Oracle-backed region databases, the documented ESCWA procedure sets ES_DB_FH=Y, ES_DB_SERVER, MFDBFH_CONFIG, MFDBFH_SCRIPT_DIR, and—when clustered database-hosted files require resource locking—ES_LOCKDB and optionally ES_SERVER. After a cold restart, DBFH-prefixed console entries indicate whether the region and cross-region databases were created successfully (Configure a Region or Cross-Region Database in Enterprise Server (Oracle)).
Takeaway: In a typical MFDBFH cluster, assign every region a unique ES_LOCKDB region database; sharing one risks lock loss and is rejected at startup, while PAC uses a different single-region-database model.