IBM Support

Supplement to the Administrator's Guide about the Lock Manager

Preventive Service Planning


This document provides supplemental information to the IBM Rational ClearCase Administrator's Guide about the Lock Manager.


This document serves to consolidate supplemental information related to the Rational ClearCase Lock Manager. Details about the Lock Manager can be found in the ClearCase Administrator's Guide on the topic of Improving VOB Host Performance.

About the Lock Manager prior to 7.0

In addition to the content in the Administrator's Guide, the following highlights outline the purpose, features and limitations of the lock manager process.

Windows, Linux, AIX®, SGI® and other platforms
  • The lock manager is an individual process that coordinates concurrent access to VOB database files.

  • The lock manager has a hard limit of 1024 users which corresponds to the number of VOBs and or users accessing those VOBs for a given host.

On Solaris® and HPUX®
  • The coordination of VOB locking is performed by the db_server and vobrpc_server processes themselves.

  • A file, /var/adm/atria/almd is memory mapped by the lockmgr and all the db_server and vobrpc_server processes running on a VOB host - known as the shared memory lock manager (introduced in 4.1).

    Note: The shared memory lock manager has not been implemented for use on pSeries hardware.

  • A single mutex mechanism is used to control concurrent updates to this file.

    Mutex is short for mutual exclusion object. A mutex is a program object that allows multiple program threads to share the same resource, such as file access, but not simultaneously. When a program is started, a mutex is created with a unique name. After this stage, any thread that needs the resource must lock the mutex from other threads while it is using the resource. The mutex is set to unlock when the data is no longer needed or the routine is finished.

  • The lock manager process is more of a lock janitor in this capacity as it just sets up and cleans up after the db_server and vobrpc_server processes.

Changes to the Lock Manager as of 7.0 on UNIX and Linux

The 7.0 ClearCase Administrator's Guide does not include the details about the new lock manager. All of the information related to the new features are included below.

As of ClearCase 7.0 the lock manager process has been removed for HP-UX, Itanium, Solaris, and Linux (x86). The lock manager functions have been absorbed by the db_server and vobrpc_server processes for VOBs and the syncmgr_server process for the MultiSite® syncmgrdb. This means that each VOB in essence now has its own lock manager. This change will allow many more VOBs and users on a single machine.


  • As of ClearCase 7.0 IFIX01, the lock manager enhancements described above now apply to AIX. Prior to the iFix, AIX uses a lock manager; after the iFix is applied, the lock manager functions will be absorbed by the db_server and vobrpc_server processes.
  • There are no changes to the lock manager on Windows (x86 or x64) or Linux (x64, iSeries pSeries, and zSeries). There is still a lock manager process on these platforms. The instructions outlined in the ClearCase Administrator's Guide still applies to these platforms.

New Configuration File on UNIX and Linux:

The ability to have different parameters for each VOB on the system as well as a locally-specified override for server-wide settings is now possible through use of a configuration file called vob_almd_params.

NOTE: Although it is possible to set up per VOB almd parameters, we recommend that instead you use only the per server wide settings in /opt/rational/clearcase/config/vob/db . Calculate the highest settings that you need and use that for all VOBs instead.

Note: Modifying this file does not require a reboot or even a restart of the ClearCase services; however, any changes made to the configuration file will be applied when the VOB is idle so as not to impact other operations in progress. A VOB is considered idle in this case when all of the db_server processes have completed work in that VOB.
For example, if there are db_server processes still working (actively working or waiting to work) on a VOB, the changes made to the configuration file will not become active until all but one of those db_servers complete their work. When the last db_server is finished, ClearCase will consider the host idle and will then implement the changes for that VOB.

IMPORTANT: For sites with very high and constant activity in their VOBs, it is recommended you stop and restart ClearCase to avoid any potential problems like the one identified in technote 1253547.

The vob_almd_params server wide configuration file is located in the /opt/rational/clearcase/config/vob/db directory and controls the settings for all VOBs on the host.

Note: The parameter values can be lower than the ones used in previous releases.

The syntax employed within the vob_almd_params file:

–u num –q num

Upgrading UNIX and Linux:

Since there is no longer a lockmgr process on UNIX and Linux in Rational ClearCase 7.0, existing lock manager parameters will not be reused upon upgrade. Instead, these parameters are overwritten with default values.

To preserve existing values for these parameters, save a copy of the host's /var/adm/rational/clearcase/config/lockmgr.conf before you upgrade.

After the upgrade, you can restore these parameter values to one of the vob_almd_params files above.

  • There is no longer a need to specify –f when customizing the vob_almd_params file.

  • The old –u and -q parameters were used for ALL VOBs on the system. You will need to recalculate if you plan to apply settings on a per-VOB basis.

ClearCase Administrator's Guide addendum

  • The 7.0 and 2003.06.00 ClearCase Administrator's Guides contain the same content.

Addendums to the sections listed below are provided.

  1. The ClearCase Administrator's Guide under the lockmgr reference information > Options and argument > -u section states:

    You can compute a very approximate value [rule of thumb] for –u by using the formula:

    V*(N/4 + 5

    Note: For UNIX and Linux using the new lock manager process in ClearCase 7.0, V will equal 1 since there is one "lock manager" per VOB.

    The formula will compute an approximate value; however, it is not worst case. Since one db_server process can consume up to 4 user table slots for each VOB the process is accessing, the worst case value for the user table (-u) should be:

    V*(N + 5)

    Note: The -q value in should be no more than 5*(-u value).

  2. The ClearCase Administrator's Guide under the lockmgr reference information > Options and argument > -u section also states a better method to use to calculate the user table.

    For a more realistic value—one that does not cause the lock manager to consume unnecessary virtual memory on the VOB server host—monitor the total number of db_server and vobrpc_server processes running on the VOB server host for an extended period of typical use (perhaps a week or two). Then multiply the peak value by a factor that will accommodate growth (two, or perhaps a little more).

    Here is an example of what that section describes:

    If you count db_server and vobrpc_server processes and get

    13 combined processes at 1:00 PM
    18 processes at 1:30 PM
    12 processes at 2:00 PM
    13 processes at 2:30 PM

    and continue this pattern throughout the week, you will be able to find the maximum number for the user table.

    In this example the maximum was 18, so the -u value would be 36 which was derived by using twice the maximum number of processes at any one time ( 2 * 18).

    Note: The -q value in should be no more than 5*(-u value).

  3. The ClearCase Administrator's Guide makes reference to a lockmgr_log file on UNIX and Linux. There is no lockmgr_log file. Any error related to the lock manager would appear in either the vobrpc_server log or the db_server log.
  4. In the ClearCase 7.x Administrator's Guide under the section Modify Lock Manager Startup Options > To change lock manager startup options > On Windows hosts there is a line break on page 231 which may confuse administrators who are trying to set the registry key for the lock manager parameters in the Windows registry. The following information is provided to provide clarification.

    Note: This solution contains information about modifying the system registry. Before making any modifications to the Microsoft® Registry Editor, it is strongly recommended that you make a backup of the existing registry. For more information describing how to back up the registry, refer to the Microsoft Knowledge Base article 256986 at

    To successfully set the lock manager parameters, follow the instructions below:

    a. Open the Registry Editor. Click Start > Run and type regedit

    b. In the tree on the left, navigate to

    32-bit Windows) HKEY_LOCAL_MACHINE\SOFTWARE\Atria\ClearCase\CurrentVersion

    For 64 bit Windows Operating systems the path is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Atria\ClearCase\CurrentVersion

c. Right click on Current Version and select New > String Value

d. Type LockMgrCmdLine as the name of the new String.

e. Double click the string value and enter the value –a almd –f num –u num –q num (where num is the value you have calculated).

  • New in ClearCase 7.1, the lockmgrcmdline will be automatically created by the installer with the following values if a "server" type of installation is selected (anything that is not a client-only install):

    -a almd -f 1024 -u 1024 -q 4096
  • The ClearCase 7.1 Administrators Guide incorrectly states:

    "The –f option cannot be set higher than 1018."

    The 1018 limit applies only to the -u option which is already documented correctly in the lockmgr reference information.

    Additional details:

    -f specifies the size of a table lockmgr creates to track the files it is managing.
    There are 7 managed file per VOB hosted on the system.
    There are also 19 managed files for the syncmgrdb on a MultiSite server.

    With "-f 256" the lockmgr can manage 36 VOBs if the syncmgrdb is not active,
    but only 33 VOBs if the syncmgrdb becomes active before all the VOBs are active.

[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Lock Manager","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF015","label":"IRIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0;7.0.1;7.1;7.1.2;8.0;8.0.1;9.0","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
29 September 2018