Resource Locking

Prior to the introduction of MFDBFH, the locking and releasing of resources accessible to a group of enterprise server regions configured as a cluster was the responsibility of the Global Lock Manager (GLM): a dedicated enterprise server region whose role is to process global lock requests.

This process was required to allow jobs of the same name to run on different regions, and to also prevent concurrent access to data sets that have been allocated as DISP=OLD|NEW|MOD in JCL within their submitted jobs.

When your catalog and spool queues are stored in a database, a different process is required to handle the resource locking. The role of a GLM is replaced by the combination of region databases and a cross-region database. A region database will process step- and system-scoped ENQs, and a cross-region database will process system-scoped ENQs.

How you set up your resource locking depends on the enterprise server configuration you have:

A typical enterprise server cluster (ES_LOCKDB method)

Within a cluster where a GLM would previously been employed, the step- and system-scoped ENQs initiated by an enterprise server region must be processed by its own dedicated region database server. This is achieved by using the ES_LOCKDB=<region-db> environment variable. Note, the region database specified by the variable must be configured as part of the database configuration file currently in use.

The following excerpt from a database configuration file shows a Db2 configuration where one physical database houses a cross-region database, 3 region databases, and a datastore:

<?xml version="1.0" encoding="utf-8" ?>
<!-- MFDBFH 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>

If a cluster of 3 enterprise servers were using this configuration file, each server must specify a different region database to process its locking resources; so you could specify ES_LOCKDB=DEVL1 on the first server, ES_LOCKDB=DEVL2 on the second, and ES_LOCKDB=DEVL3 on the third.

Important: The reason for ensuring that each server uses its own region database is because the region database is cold-started when the server that specifies it is started. During the cold start, a region database drops and reinstalls any associated database objects. If more than one server was using the region database, locks for the other servers could be lost. To ensure the same region database is not configured for multiple servers, a check is made during a server startup: if it is not using a unique region database, startup fails and the failure is written to the console log.

As well as specifying the region database on each server, you must also specify which MFDBFH server (that is, the server name entry in the configuration file) that the region database belongs to. Using the example above, each server in the cluster should also set the ES_SERVER=MYSERVER variable.

A Performance and Availability Cluster (PAC)

If you have configured a PAC, the setup is slightly different to that of a typical cluster. The same types of servers perform the same locking processes (region databases process step- and system-scoped ENQs; cross-region databases process system-scoped ENQs), but only a single region database is required for the step- and system-scoped ENQs for all enterprise server regions in the PAC.