The limited lock facility (LLF) and the concurrency filter lock
facility (CFLF), which are two external lock facilities (XLFs)
supported by the TPF 4.1 system, were required to control access to
data shared by two or more processors in a loosely coupled complex.
CF record lock support, which uses the CF support provided on
program update tape (PUT) 9 to implement an XLF, provides the
option of using one or more CFs as XLFs. A CF is an IBM
processor, sometimes referred to as a central processor complex
(CPC), that is used to centralize storage for all attached
processors in a processor configuration by providing shared storage
and shared storage management functions. A CF can run in a logical
partition (LPAR), under the IBM VM system, or as a stand-alone
processor.
CF record lock support offers significant flexibility in using
CFs as XLFs in your locking configuration. Your locking
configuration may be dynamically modified by adding or deleting
CFs. When a CF is added to or deleted from the locking
configuration, the TPF 4.1 system automatically redistributes any
locks to balance the locking workload across all available CFs. You
can add as many as 32 CFs to your locking configuration for a high
degree of availability. The CFs in your locking configuration can
be used in addition to, or instead of, an LLF and CFLF control unit
(CU). In addition, the CFs in your locking configuration can
simultaneously be used for nonlocking workloads. Using CFs in a
locking configuration can eliminate the need for an LLF or CFLF,
giving you greater flexibility when selecting and implementing new
module CUs. Using CFs for locking dramatically increases the lock
space available. Therefore, CF record lock support enables full
exploitation of virtual file access (VFA) synchronization.
All online modules in a loosely coupled complex must use an XLF
for locking to control access to shared data. You can specify which
online modules will use CFs for locking even if a specified module
is connected to a CU with LLF or CFLF CUs. Modules can be migrated
to use CFs for locking individually, in groups, or all online
modules at once. The lock residency of any duplicate module is
configured automatically to be identical to that of the
corresponding prime module. General data sets may be migrated to
use CFs for locking also.
CF List Structures for CF Locking
In a loosely coupled complex, locks are used to control access
to data shared by two or more processors. With CF record lock
support, these locks can now be represented as entries in a CF
list structure. A CF list structure is a named piece of storage
on a CF that enables users to share information organized as
entries on a set of lists or queues.
CF record lock support creates the following CF list structures
for CF locking on each CF in the locking configuration:
- ITPFLK1_xxxxxx
- ITPFLK2_xxxxxx
Where xxxxxx is the complex name.
Any event that changes the status or configuration of the TPF
4.1 system and impacts the distribution of CF locks on the XLF can
require that CF locks are reassigned from one XLF to another.
Events that can trigger lock recovery include:
- Changing the status of a module from offline to online or
online to offline
- Completing an all-file copy operation
- Adding or removing a CF from the CF locking configuration
- Changing an assignment of lock residency between a module and a
CF
- Failure of a CF that was actively participating in CF
locking.
Functional Messages Used for CF Locking
Functional messages are used to display entries in the coupling
facility locking table (CFLT) and to manage the CFs in a locking
configuration. CF record lock support provides the following
functional messages:
| Functional Message |
Description |
| ZCFLK ADD |
Adds a CF to the CF locking configuration, which then enables
the CF for use as an XLF so new locks can be stored on it. |
| ZCFLK DELETE |
Removes a CF from the CF locking configuration. All CF locks
stored on this CF are redistributed automatically among the
remaining CFs in the CF locking configuration on a module-by-module
basis. As a result, CF locks can no longer be stored on this
CF. |
| ZCFLK DISPLAY |
Displays information about the CF locking configuration. |
| ZCFLK INITIALIZE |
Initializes the CF locking configuration. |
| ZCFLK MIGRATE |
Changes the lock residency of a module from a CFLF locking CU
to a CF, or from a CF to a CFLF locking CU. |
| ZDLCK DISPLAY |
Displays locks in a CF. |
Diagnostics
- Information maintained in the CF trace table and the lock trace
table is available.
- Three new data collection reports are available:
- A CF usage summary report that provides information about the
CF utilization and storage in use
- A CF structure summary report that provides information about
the structure size, the requests per second, the service time, and
the queue time
- A CF locking summary report that provides information about the
number of prime modules active on the CF, the number of operations
for each request, the number of lists, the list depth, the number
of locks held, and the average number of locks for each list.
Lock Name Format
Lock names have a new format with CF record lock support. The
symbolic device address (SDA) is no longer included in the lock
name. Because the lock space resides in the CF and a prime module,
its duplicate and the copy modules are all on the same CF; there is
no need to rebuild the locks during ZAMOD UP or ZMCPY functional
message processing. This eliminates the movement of locks during
these processes.
The new lock name format is as follows:
0001 0079 01 04 00 00
MOD CYL HD REC DBI IND
00 = RHT lock
80 = SYNC lock
08 = GDS lock
01 = USER lock
The lock name in the lock trace table contains a time stamp in
the first 8 bytes and the indicator has a different meaning:
B32810D33F2A4103 0001007901040000
Indicator: 00 = RHT lock granted notification
80 = SYNC lock granted notification
20 = RHT lock contention notification
A0 = SYNC lock contention notification
First Quarter 2000 - Table of Contents
