Method and apparatus for performing conditional operations on externally shared data

Abstract

A Structured External Storage (SES) processor is linked by a communication means to one or more general purpose processors. Two or more applications executing on the one or more general purpose processors communicate function request messages to a message processor within the SES to effect serialized sharing of data within the SES. Within the message processor, a predicate function means executes unconditionally on receipt of one of the function request messages, and a data function means executes conditionally and atomically with respect to the predicate function means following a "successful" condition produced by the predicate function means. The predicate function means comprises a predicate compare function means and a predicate update means, the predicate compare function means executing unconditionally and producing a "successful" or "unsuccessful" result, the predicate means executing conditionally and atomically with respect to the predicate compare function means, following a "successful" result by the predicate update compare function means.

Claims

The invention claimed is:

1. An apparatus for providing conditional operations on shared data objects shared among two or more applications operating in a system comprising one or more general purpose processors on which said applications execute, each of said one or more general purpose processors being coupled to a structured external storage (SES) facility that is distinct from said one or more general purpose processors, said apparatus comprising:

a) means for creating a data structure comprising said shared data objects within said SES facility;

b) communication means for communicating a function request message between one of said two or more applications and said SES facility, said function request message specifying an operation on a target data object selected from said shared data objects, said operation being contingent on a presumed state of said target data object; and

c) a message processor within said SES facility, responsive to said function request message and operating on said data structure, said message processor comprising a predicate function means for executing a predicate function within said SES facility, independently of said one or more general purpose processors, for verifying said presumed state of said target data object and a data function means for executing a data function within said SES facility, independently of said one or more general purpose processors, for performing said operation on said target data object, said predicate function executing unconditionally and producing either a "successful" or an "unsuccessful" condition, said data function executing conditionally and atomically with respect to said predicate function, following a "successful" condition produced by said predicate function.

2. The apparatus of claim 1 in which said data structure comprises a list structure, said list structure comprising one or more lists, each of said one or more lists comprising a list control and one or more list entries, and in which said function request messages each comprise a list command message.

3. The apparatus of claim 2 in which said predicate function means comprises a predicate compare function means for executing a predicate compare function for comparing said presumed state of said target data object with its actual state and a predicate update means for executing a predicate update function for updating the state of said target data object, said predicate compare function executing unconditionally and producing either a "successful" or an "unsuccessful" condition, said predicate update function executing conditionally and atomically with respect to said predicate compare function, following a "successful" condition produced by said predicate compare function.

4. The apparatus of claim 3 in which each of said list entries comprises a version number field having a list entry version number value, in which said list command message comprises a comparative version number field having a comparative version number value, and in which said predicate compare function comprises a compare version number function, said compare version number function comparing said comparative version number value with the list entry version number value in a specified list entry.

5. The apparatus of claim 4 in which said predicate update function comprises a change version number function, said change version number function replacing said list entry version number value with a replacement value.

6. The apparatus of claim 5 in which said list command message further comprises an indicator field having an indicator value and an optional replacement field having an optional replacement value, and in which said replacement value is a predetermined positive delta to said list entry version number value when said indicator field has a first value, said replacement value is a predetermined negative delta to said list entry version number value when said indicator field has a second value, and said replacement value is said optional value when said indicator field has a third value.

7. The apparatus of claim 3 in which said list structure further comprises a lock table having one or more lock table entries each having lock table entry value, in which said list command message comprises a comparative lock entry having a comparative lock value, and in which said predicate compare function comprises a compare lock value function, said compare lock value function comparing said comparative lock value with a first one of said lock table entry values.

8. The apparatus of claim 7 in which said predicate update function comprises a change lock value function, said change lock value function replacing said first one of said lock table entry values with a replacement value.

9. The apparatus of claim 8 in which each of said lock table entries comprises a global lock table entry, in which each of said lock table entry values comprises a global lock table entry value, in which said comparative lock value comprises a comparative global lock value, and in which said first one of said lock table entry values comprises a global lock table entry value.

10. The apparatus of claim 7 in which said predicate update function comprises a change lock value function, said change lock value function replacing a second of said lock table entry values with a replacement value.

11. The apparatus of claim 10 in which each of said lock table entries comprises a global lock table entry and a local lock table entry, in which each of said lock table entry values comprises a global lock table entry value and a local lock table entry value, in which said comparative lock value comprises a comparative global lock value, in which said first of said lock table entry values comprises a global lock table entry value, and in which said second of said lock table entry values comprises a local lock table entry value.

12. The apparatus of claim 3 in which each of said list entries comprises a list number field having a list entry list number value, in which said list command message comprises comparative list number field having a comparative list number value, and in which said predicate function comprises a compare list number function, said compare list number function comparing said comparative list number value with said list entry list number value in a specified list entry.

13. The apparatus of claim 3 in which said communication means is a first communication means, said apparatus further comprising second communication means for communicating response messages between said SES facility and one of said two or more applications, said response messages each comprising a list entry controls field.

14. The apparatus of claim 13 in which said list entry controls field comprises a list entry number field and a list entry version number field.

15. The apparatus of claim 2 further comprising Write List Controls means for setting a list threshold control field in said SES facility to a list threshold value; in which said predicate function comprises a compare means for comparing, for a less than or equal condition, a projected list size with said list threshold value; and in which said data function, if executed, causes a target one of said one or more lists to have a size equal to said projected list size.

16. The apparatus of claim 2 in which predicate function means comprises:

a first predicate compare function means for executing a first predicate compare function for comparing said presumed state of said target data object with its actual state, and a first predicate update means for executing a first predicate update function for updating the state of said target data object, said first predicate compare function executing unconditionally and producing either a "first successful" or "first unsuccessful" condition, said first predicate update function executing conditionally and atomically with respect to said first predicate compare function, following a "first successful" condition produced by said first predicate compare function;

said predicate function means further comprising a second predicate compare function means for executing a second predicate compare function for comparing said presumed state of said target data object with its actual state, and a second predicate update means for executing a second predicate update function for updating the state of said target object, said second predicate compare function executing conditionally and atomically with respect to said first predicate update function following "first successful" condition produced by said first predicate compare function, said second predicate compare function producing either a "second successful" or a "second successful" condition, said second predicate update function executing conditionally and atomically with respect to said second predicate compare function, following a "second successful" condition produced by said second predicate compare function;

said predicate function execution producing said "successful" condition only when said first predicate compare function produces said "first successful" condition and said second predicate compare function produces said "second successful" condition.

17. An apparatus for providing serialized access to shared data objects shared among two or more applications operating in a system comprising one or more general purpose processors on which said applications execute, each of said general purpose processors being coupled to a structured external storage (SES) facility that is distinct from said one or more general purpose processors, said apparatus comprising:

a) a list data structure stored within said SES facility and comprising said shared data objects, said list data structure comprising one or more lists, each of said one or more lists comprising a list control and one or more list entries having list entry identification tokens;

b) communication means for communicating a function request message between one of said two or more applications and said SES facility, said function request message specifying an operation on a particular list entry, said operation being contingent on the existence of said particular list entry within said list data structure, said function request message comprising a supplied means for designating said particular list entry; and

c) a message processor within said SES facility, responsive to said function request message and operating on said list data structure, said message processor comprising a predicate function means for executing a predicate function independently of said one or more general purpose processors and a data function means for executing a data function independently of said one or more general purpose processors, said predicate function comprising a compare identifier function comparing said supplied means for designating said particular list entry with the list entry identification token within one of said one or more list entries, to generate an "equal" or "not equal" result, and said data function comprising a create/replace list data entry function operationally conditioned on the result of said compare identifier function, and executing atomically with said compare identifier function, so that a create function creating a new list entry is performed when said predicate function generates a "not equal" result, and a replace function replacing an existing list entry is performed when said predicate function generates an "equal" result.

18. A method for operating a computer system to provide serialized access to shared data objects shared among two or more applications operating om said system comprising one or more general purpose processors on which said applications execute, each of said one or more general purpose processors being coupled to a structured external storage (SES) facility that is distinct from said one or more general purpose processors, said method comprising the steps of:

a) creating a data structure, comprising said shared data objects, within said SES facility;

b) communicating a function request message between one of said two or more applications and said SES facility, said function request message specifying an operation on a target data object selected from said shared data objects, said operation being contingent on a presumed state of said target data object;

c) performing within said SES facility, in response to said function request message and independently of said one or more general purpose processors, a serialization-checking predicate function for verifying said presumed state of said target data object, said predicate function resulting in a "successful" or an "unsuccessful" condition; and

d) if said performing of said predicate function results in a "successful" condition, providing said serialized access and further performing within said SES facility, atomically with said predicate function and independently of said one or more general purpose processors, a data function comprising said operation on said target data object.

19. The method of claim 18 in which said step of creating a data structure further comprises the step of creating a list data structure, said list data structure comprising a list control and one or more lists, each of said one or more lists comprising one or more list entries, each of said one or more list entries comprising a version number field having a list entry version number value; in which said function request message comprises a list command specifying an operation on a specified list entry of one of said lists, said list command comprising a comparative version number field having a comparative version number value; and in which said step of performing a predicate function comprises comparing said comparative version number value with the list entry version number value in said specified list entry.

20. The method of claim 19 in which said step of performing said predicate function further comprises replacing said list entry version number value with a replacement value.

21. The method of claim 18 in which said step of creating a data structure comprises the step of creating a list data structure, said list data structure comprising a list structure and one or more lists, each of said one or more lists comprising one or more list entries, and said list data structure further comprising a lock table having one or more lock table entries each having a lock table entry value, each of said list entries being controlled by a corresponding lock table entry; in which said function request message comprises a list command specifying an operation on a specified list entry of one of said lists, said list command comprising a comparative lock entry having a comparative lock value; and in which said step of performing said predicate function comprises comparing said comparative lock value with the value in the lock table entry corresponding to said specified list entry.

22. The method of claim 18 in which said step of creating a data structure comprises the step of creating a list data structure, said list data structure comprising a list structure and one or more lists, each of said one or more lists comprising one or more list entries, each of said one or more list entries comprising a list number value; in which said function request message comprises a list command comprising a comparative list number field having a comparative list number value; and in which said predicate function comprises comparing said comparative list number value with the list number value in a specified list entry.

23. The method of claim 18 in which said step of creating a data structure further comprises the step of creating a list data structure, said list data structure comprising one or more lists, each of said one or more lists comprising a list control and one or more list entries; in which said method further comprises performing a write list controls function to set a list threshold control field in said SES facility to a list threshold value; in which said predicate function comprises comparing, for a less than or equal condition, a projected list size with said list threshold value; and in which said data function, if executed, causes a target one of said one or more lists to have a size equal to said projected list size.

24. A method for operating a computer system to provide serialized access to data shared among two or more applications operating in said system comprising one or more general purpose processors on which said applications execute, each of said one or more general purpose processors being coupled to a structured external storage (SES) facility that is distinct from said one or more general purpose processors, said method comprising the steps of:

a) creating a list data structure within said SES facility, said list data structure comprising a list control and one or more lists, each of said one or more lists comprising one or more list entries having SES list entry identification tokens;

b) communicating a function request message between one of said two or more applications and said SES facility, said function request message specifying an operation on a particular list entry, said operation being contingent on the existence of said particular list entry within said list data structure, said function request message comprising a supplied means for designating a particular list entry; and

c) executing atomically within said SES facility, in response to said function request message and independently of said one or more general purpose processors, a function pair comprising a predicate function and a data function, said predicate function comprising the step of comparing said supplied means for designating a particular list entry with the list entry identification token within one of said one or more list entries to produce an "equal" or "not equal" condition, and said data function comprising a write list data entry function operationally conditioned on a result of said step of comparing so that a new list entry is written if said predicate function produces a "not equal" condition, and a replacement list entry is written if said predicate function produced an "equal" condition.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application contains subject matter which is related to the subject matter of the following applications which are assigned to the same assignee as this application. They are hereby incorporated by reference:

"Configurable, Recoverable Parallel Bus" by N. G. Bartow et al, Ser. No. 07/839,657, (Docket No. PO991066), Filed: Feb. 20, 1992; "High Performance Intersystem Communications For Data Processing Systems" by N. G. Bartow et al, Ser. No. 07/839,652, (Docket No. PO991067), Filed: Feb. 20, 1992; and "Frame-Group Transmission And Reception For Parallel/Serial Buses", issued as U.S. Pat. No. 5,267,240 on Nov. 30, 1993.

The subject matter in the following listed applications is also related to and is hereby incorporated by reference in the present application. Each of the following listed applications is owned by the same assignee as the present application, is filed on the same day as the present application, and has the same priority date as the present application. They are:

"Communicating Messages Between Processors And A Coupling Facility" by D. A. Elko et al, Ser. No. 07/860,380 (Docket Number PO991006); "Sysplex Shared Data Coherency Method and Means" by D. A. Elko et al, Ser. No. 07/860,805, (Docket Number PO991052); "Method and Apparatus For Distributed Locking of Shared Data, Employing A Central Coupling Facility" by D. A. Elko, et al., Ser. No. 07/860,808, (Docket Number PO991059); "Command Quiesce Function" by D. A. Elko et al, Ser. No. 07/860,330, (Docket Number PO991062); "Storage Management For A Shared Electronic Storage Cache" by D. A. Elko et al, Ser. No. 07/860,807, (Docket Number PO991078); "Management Of Data Movement From A SES Cache To DASD" by D. A. Elko et al, Ser. No. 07/860,806, (Docket Number PO991079); "Command Retry System" by D. A. Elko et al, Ser. No. 07/860,378, (Docket Number PO992002); "Integrity Of Data Objects Used To Maintain State Information For Shared Data At A Local Complex" by D. A. Elko et al, Ser. No. 07/860,800, (Docket Number PO992003); "Management Of Data Objects Used To Maintain State Information For Shared Data At A Local Complex" by J. A. Frey et al, Ser. No. 07/860,797, (Docket Number PO992004); "Recovery Of Data Objects Used To Maintain State Information For Shared Data At A Local Complex" by J. A. Frey et al, Ser. No. 07/860,647, (Docket Number PO992005); "Message Path Mechanism For Managing Connections Between Processors And A Coupling Facility" by D. A. Elko et al, Ser. No. 07/860,646, (Docket Number PO992006); "Method And Apparatus For Notification Of State Transitions For Shared Lists of Data Entries" by J. A. Frey, et al., Ser. No. 07/860,809, (Docket Number PO992007); "Apparatus And Method For List Management In A Coupled DP System" by J. A. Frey, et al., Ser. No. 07/860,489, (Docket Number PO992009); "Interdicting I/O And Messaging Operations In A Multi-System Complex" by D. A. Elko, et al., Ser. No. 07/860,489, (Docket Number PO992010); and Method and Apparatus for Coupling Data Processing Systems" by D. A. Elko, et al., issued as U.S. Pat. No. 5,317,739 on May 31, 1994.

BACKGROUND OF THE INVENTION

This invention relates to the field of general purpose computer systems which share data in a single or multi-system configuration (a SYSPLEX). More particularly, it relates to performing conditional operations on shared data within a shared coupling facility in such a configuration.

As is known, processes or applications executing concurrently in a central electronic complex (CEC) or in a system complex (Sysplex) comprising two or more CEC's coupled together can compete for access to shared resources such as external data.

Customarily, an operating system is provided in a CEC, which consists of software that controls execution of programs. An operating system is typically enabled to schedule events, control the execution of processes and schedule their access to resources. In this regard, an operating system facilitates orderly access to resources by implementing sequencing mechanisms that serialize the access of competing processes to shared resources.

As described in Hwang and Briggs, "Computer Architecture and Parallel Processing", 1984, one method of resource use serialization of competing processes involves a synchronization mechanism that utilizes a shared variable whose condition indicates the status of a shared resource. Access of a process to the resource is signalled by the variable being placed by the process into a "busy" condition, which indicates unavailability of the resource to other processes requiring use of it. When a process observes that the shared variable has an "available" or "unbusy" condition, it will be able to obtain the resource for its own use.

Mutual exclusion of access to shared resources, according to Hwang and Briggs, can be implemented by a sequence of instructions forming a part of an operating system that define "lock" and "unlock" operations. For the lock operation, a process executes against a resource status variable (RSV) by inspecting its current condition and, when the condition is other than busy (unlocked), setting the RSV to busy (locking it), and then using the resource. Then, when use of the resource is completed, the process executes against the RSV in an unlock operation wherein the RSV is set to a nonbusy condition. Under this construct, a process has exclusive control over the resource once it "locks" the lock; other processes cannot gain entree until the controlling process "unlocks" the lock.

To preclude the ambiguous circumstance where one process detects a nonbusy condition before a competing process set the RSV to "busy", the IBM System 370 extended architecture (as described in IBM Publication No. SA22-7085-0) provides a family of atomic operations that test and modify an RSV held at a storage location in a single read-modify-write instruction. The atomic operations are completed so that the RSV is not tested and set by another process before the currently-executing process completes its operation. Thus, the operations are "atomic" in the sense that they either succeed completely in altering the condition of the RSV or fail, in which case the RSV is left unchanged.

Obermarck, U.S. Pat. No. 4,399,504 teaches lock management to control access to data resources shared by two or more central electronic complexes. Obermarck is instructive in one of the principal limitations of presently-utilized lock operations: the requirement that waiting processes suspend operations when contending for shared resources.

Methods other than lock setting are also available to serialize access to shared resources. Roever, U.S. Pat. No. 4,189,771 describes a single thread, contention-free process for detecting deadlock from a vector of process wait relations. Carlson et al., U.S. Pat. No. 4,410,940 provides for transfer of control among hierarchically related processes through the use of pointers to traverse an activity. Chatfield, U.S. Pat. No. 4,183,083 utilizes a form of dynamic scheduling to increase throughput in a multiprogrammed computing system.

Process synchronization, implemented by interprocess communication, is also used to serialize utilization of shared resources. Interprocess communication involves passing data across message interfaces between processes. This is typically referred to as "loose coupling". Loose coupling by processor intercommunication places reliance on pattern and content of message traffic. Moreover, it is often the case that communicating processors may share only a few physical resources such as the network or secondary storage. Securing mutual exclusion of resource access while avoiding mutual blocking or suspension has led to embedding language/algorithmic constructs within the competing processes or embedding such constructs in the form of monitors in operating systems. A well-known software solution in this regard has been contributed by Dijkstra in "Cooperating Sequential Processes", PROGRAMMING LANGUAGES, Academic Press, 1968.

For performance reasons, it is important to minimize the amount of communication required between systems in a SYSPLEX.

Prior art required multiple interactions between concurrently executing processes to establish and release serialization for individual or multiple requests to access shared data.

It consisted of explicit serialization across multiple executions of a command in order to block intervening updates to the shared data objects. In many cases, such strong serialization is unnecessary and results in undesirable resource contention, performance degradation, and complex recovery logic.

GENERALIZED LOCKING PROTOCOL

When sharing data on an external device, a general locking protocol makes extremely costly the performance overhead of using such data for many of the process requirements which could otherwise be satisfied in a single data access.

Typically, the method employed by programming to gain the exclusive right to update a shared data object consists of multiple steps, each of which results in potentially unnecessary and undesirable resource contention, performance degradation, and complex recovery logic.

Consider the following example in which a program intends to read the contents of the data object and change its state to "b" only if the current state of the object is "a".

1. The program acquires an explicit exclusive lock, multi-system in scope, to block concurrent access to the target shared data object

2. The program accesses the object (transfers its contents to the CPC), and determines its current state

3. If the state of the object is not "a", the program proceeds to step 5

4. The program performs a write-access to the object to update its state to "b"

5. The program releases the exclusive lock

The above scenario includes two physical round trips to a shared lock facility. The above scenario also includes two physical accesses to the shared data object. The scenario may also result in undesirable contention and intersystem signalling due to use of an explicit lock. Also note that the physical transfer of the data was unnecessary when the state of the object was not "a".

In an environment where the majority of accesses can be accomplished in a single, atomic command such as in the case with the SES list entries, such a protocol is not desirable.

Certain programming protocols require the ability to have multiple individual commands processed without intervening operations being executed on behalf of other processes which execute in parallel in a Sysplex configuration.

The need exists for multiple operations to be performed on behalf of a particular process without commands presented to an external device on behalf of other processes accessing the set of objects being manipulated by the first process. For example, programming protocols exist which require a process to view all the entries on a particular list. In order to correctly view all the entries on a particular list, no entries must be added or deleted to that list by other processes. In another example, it is required that an entry be placed on each of two lists before the results of the process are made visible to other processes.

DASD KEY OBJECTS AND SEARCH KEY EQUAL CHANNEL COMMANDS

In the prior art (e.g., as described in IBMs 3990 Storage Control Reference Manual, GA32-0099-1), channel command words (CCW's) are described which enable programming to set and compare the key field of a Count/Key/Data DASD architecture device. As is described in that architecture, CCW's can be chained together and are executed one at a time. For the duration of a given channel program, the device maintains an allegiance with the interface over which the channel program is executing (see, e.g., IBM's Enterprise Systems Architecture/370 Principles of Operation, SA22-7200-0). Operations which set or test the key field can be followed by operations which access shared data. However, no ability exists to insure atomic actions on the key and shared data areas. It is the responsibility of programming to institute protocols to detect and correct errors which occur when a process accesses data residing on a shared DASD device.

In prior art, such as the DASD key mechanisms, comparison of the serialization point and execution of the subsequent requests are not atomic. Individual channel command words are required to establish the serialization point and access data Between these two operations errors can occur which require complex programming protocols for error detection and recover.

Single CPC Operations

In the aforementioned ESA/370 Principles of Operation, the CS and CDS ESA/390 CPU instructions are described which provide the compare and replace function on locations within main memory.

General Data Base Locking

A known mechanism achieves serialization of shared data resources through a general data base locking protocol. The general protocol requires that a serialization point be established and acknowledged by all processes which share access to the data. After such a serialization point has been established, the shared data is accessible. When access to the shared data is no longer required, the serialization point is released. Significant complexity and system performance degradation occur as this locking mechanism requires multiple interactions between the processes which concurrently execute and access the shared data.

SUMMARY OF THE INVENTION

This invention describes a configuration which enables a network of CPCs (101 to 104) to issue requests to and receive responses from a coupling facility. The coupling facility described herein is a Structured External Storage processor (SES 110).

One or more programmed-applications 105 to 108 on one or more processors (central processing complexes, or CPCs 101 to 104) share lists 109 of data entries that exist in the SES 110 which is shared by the plurality of processors. One or more lists of data elements are defined to exist in a SES device which are shared among multiple users. Management of the lists of data entries is performed in the SES facility and relieves the list user application of the burden of storage management for shared data.

Programming can request the SES 110 to perform commands or operations which are designed to return data and status information. A set of such operations are described in this invention. The individual commands operate atomically as viewed by all other processes across all CPCs attached to the SES.

The mechanisms described in this invention provide the means by which programming can associate a serialization point with an arbitrary set of objects and allow individual commands to access those objects without performance penalty by processes which do not require serialization among each other.

The mechanisms described in this invention also provide the means by which programming can enable execution of processes which require serialization across multiple SES list commands.

Checking of the serialization point and execution of the associated command is atomic as viewed by other processes and either executes to completion or does not change the state of the referenced SES objects.

If the comparison of the serialization point is not successful, execution of the command is suppressed, and data is returned which reflects the associated process which holds the serialization in a manner which is atomic with the execution of the SES command.

Additionally, the present invention provides for limiting the size of a particular list. This is accomplished by defining lists in terms of list entries, and list entries in terms of list elements, and allowing the creator of a list structure to set thresholds for the maximum number of list entries in a list, or list elements in a list. A count of the number of entries or elements in a list is maintained on a list basis, and modified as list entries are created, moved, and deleted. In this manner the potential for a defective application to usurp a disproportionate amount of SES storage allocated to the structure is reduced.

It is an object of the present invention to provide a mechanism for serialized access to shared external data that permits operations on such data without the need for a separate external reference to first obtain a lock.

It is a further object of this invention to provide for the conditional execution of commands which create or replace data on external storage based on the current existence of a data item at the external storage within the scope of a single command.

It is a further object of this invention to provide efficiently for data integrity by providing operations that permit version number checking for data on external storage within the scope of a single command.

It is a further object of this invention to provide for the conditional execution of a command which references a data item at the SES as determined by the list on which the data item currently resides.

It is a further object of this invention to reduce the possibility of aberrant processes accumulating excessive amounts of available list storage by providing for thresholds that may be set for lists.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the environment in which programmed-applications in different CPCs are sharing a List in the SES device.

FIG. 2 is a block diagram illustrating the overview structure of a List Structure in the SES facility.

FIG. 3 is a block diagram illustrating the structure of a List objects in the SES facility.

FIGS. 4A, 4B and 4C are block diagrams illustrating the structure and contents of a message command block and message response block.

FIG. 5 is a flowchart showing the overview of the process for verifying presumed state.

FIG. 6 is a flowchart showing the state verification process within an individual SES list command.

FIG. 7 is a flowchart showing the lock comparison and replacement processes within an individual SES list command.

FIG. 8 is flowchart showing the process for serialization across multiple SES List commands.

FIG. 9 is a flowchart showing the create/replace process for write-list-entry SES command.

FIG. 10 is a block diagram illustrating sample contents of a Lock Table object in the SES facility.

FIG. 11 is a flowchart showing the process for detecting "list full" conditions.

FIG. 12 is a flowchart illustrating the Attach List Structure User (ALSU) command.

FIG. 13 is a flowchart illustrating the Detach List Structure User (DLSU) command.

FIG. 14 is a flowchart illustrating the Register List Monitor (RLM) command.

FIG. 15 is a flowchart illustrating the Deregister List Monitor (DLM) command.

FIG. 16 is a flowchart illustrating the process of scanning for list entries by direction, for multiple list entry commands.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Overview

One or more programmed-applications (users 105 108) on a plurality of processors (central processing complexes, or CPCs 101-104) share structures 111 of list objects that are defined and exist in a shared, structured external storage device (a SES device 110) which is shared by the plurality of processors. Management of the list objects is performed within the SES facility 110 and relieves the list user applications 105-108 of the burden of:

1. Verification of the presumed state of list-entry objects.

2. Serialization of accesses to list-entry objects 302 in the list structure 111.

3. Accessing the SES device beforehand to determine if a subsequent request to create/replace list-entry objects 302 will be successful.

Individual command operations executed by the SES facility are designed to operate atomically.

Mechanisms are described for providing the ability for a program 105-108 having access to the storage device to conditionally operate upon target data objects based on the successful verification of the presumed state of the object, to optionally and independently change the verified presumed state of the object to another specified state, and to then perform an operation on the object (such as read, replace, move, delete). The functions in the SES facility 110 provide the above support in a single atomic operation at the storage device without the need for explicit serialization obtained by the program for the purpose of blocking ongoing concurrent operations and without requiring multiple accesses to the storage device.

In addition, if the verification of the presumed state fails, the operation at the SES is suppressed, the current list entry controls are returned, and the expense of transferring the data object over the link to the CEC is avoided.

Certain programming protocols require the ability to have multiple individual commands processed without intervening operations being executed on behalf of other processes which execute in parallel in a Sysplex of CECs. A mechanism is described for achieving the required serialization of multiple individual commands at high performance and under programming control.

The mechanisms provide the means by which programming can associate a serialization point with an arbitrary set of objects and allow individual commands to access those objects without performance penalty while also enabling execution of processes which require serialization across multiple commands.

Typically, when data is stored, it is necessary to know whether or not the storage is allocated. The SES list structure allows the program to optionally specify that a list entry should be replaced if it already exists or created if it does not. The program does not have to provide explicit serialization since the operation executes atomically.

THE PROCESS OF VERIFICATION AND ATOMIC OPERATION

A set of objects and command operations against those objects are defined at the SES. Programming protocols utilize these commands and objects to insure efficient execution of individual SES list commands while enabling serialized access across multiple SES list commands when required.

FIGS. 2 and 3 show the objects in a list structure 111 which are defined and exist in the SES 110 and are relevant to this invention. There is a separate section in this document which describes the contents of the objects and their relationships to the objects that are diagrammed in these two figures.

The storage objects and processes are accessed using commands issued by the program. Commands are packaged in a message command block 409, and are communicated from the message facility (112, 121, 119, 120) to the message processor 113 via the Send Message instruction. The message processor returns the summarized results of the operation in the message response block 417.

FIG. 4 shows the structure of a message command block 409 with emphasis on the command operands which are relevant to this invention and can be specified by programming in the request operands 402, and the structure of the response operands object 403 which is returned to the program 105 when the list-structure commands complete their processing.

Programming is provided the means to govern state changes against the shared data objects in a way that ensures no updates are lost. Programming instructs the SES 110 to apply changes to shared list entries 302 only when the current state of the entry can be determined and verified, by the SES during execution of the command.

FIG. 5 describes an overview of the interaction between a CPC based program which is processing list and lock objects, and the SES based command processors which must verify the presumed state of the objects of interest (predicate funtion 510) and then conditionally allows the command process (data function 511) to be executed.

The allocate-list-structure command creates (FIG. 5 at 501) the list structure 111 including the associated lock-table 205 based on specification of the Lock-table-entry characteristic (LTEX 425) and Lock-table-entry count (LTEC 427) and lists based on the specification of the list-element-characteristic (LELX 462), the maximum data-list-entry size (MDLES 437) and the list count (LC 433).

Lock table entries 206 are created in an initialized state with available global lock manager 207 and local lock manager 208 objects.

The list commands also provide a means for conditionally creating, reading, replacing, moving, deleting, writing and moving, reading and deleting, or moving and reading one list entry 502. List entries are accessible by means of a SES provided list-entry identifier 404, a program provided list-entry name 405, or by position in the list. This list position is specified as either leftmost or rightmost position 406, or as a keyed position.

State and lock verification is an operation that is common to the single-list-entry commands. Single-List-Entry Commands include the commands Read list entry, Write list entry, Move list entry, Delete list entry, Write and move list entry, Move and read list entry, and Read and delete list entry.

The state of a list entry 302 and a lock entry 206 may be tested to conditionally determine execution of a list command. The state of a list and/or lock entry is determined at 503 by:

1. The list 109 in which the entry resides, as indicated by the list number 305.

2. The version number of the entry, as indicated by the version number 304.

3. The state of the specified lock-table entry 206, as indicated by the associated global lock manager 207 and local lock manager 208.

4. Whether or not the list (109) is in a full condition.

5. Whether or not the list entry 302 exists, for write operations requesting conditional create/replace.

If the verification of the presumed state fails 504, the operation is suppressed and an indicative (not-successful) response code 407 is passed back to the program. If global lock manager replacement is requested, the global lock manager is replaced even if the local lock manager comparison fails and the rest of the command is suppressed.

If the verification of the presumed state is successful, (503 and 505A) the state may be updated (505B), the command processor completes its execution and a successful response code 407 is passed back to the program.

The list entry controls (315) (including the version number (304) list number (305), LEID (308), LEN (310) and LEK (311) (if name or keys exist)), are returned 506 in the response operands 403 of all single list entry, read list, and read list set SES commands.

When lock-manager comparison fails, the lock-table-entry value (LTE 485) and an indicative response code 407 are returned.

The program examines the response operands (403) at 507. If the response indicates success, the program 505 continues to its next interaction with the SES list structure (111).

If the response indicates a not-successful request, the program understands that previously issued command did not execute the desired operation. The program executes contingency processing 508 which determines what action is needed before it can resume its interaction with the list objects.

Details of conditional command execution are described in the following with reference to FIGS. 6, 7, 9 and 11 as further expansion of FIG. 5 at 503.

List Number Comparison

The Entry-Locator Type 429 is examined to determine if list number 423 and 305 comparison is requested 601. A field in the ELT 429 indicates:

1. Do not compare the list numbers

2. Compare the list numbers

The LN operand (423) on the list command is compared at 602 to the entry list number (305) which specifies the number of the list 109 on which the entry exists. When the list numbers match, a successful comparison 602 allows the command to continue its execution. If the list numbers do not match, the initiated operation against the designated list entry 302 is not performed and an indicative response code 407 is returned 607.

Version Number Comparison

If the version request type (422) specifies comparison 603 of version numbers, the value in the command operand 421 is compared 604 to the version number object (305) in the target list entry controls object (315). If the version numbers are not equal, the initiated operation against the designated list entry (302) is not performed and an indicative response code (407) is returned.

If the version numbers (421 and 305) are equal 604, the comparison is successful and the command continues its execution.

On successful completion of a SES list command the version number of a list entry (304) may be updated as specified by the command through the version request type 422. The version number associated with the list entry may be incremented, decremented, or replaced by the value specified by the command (411). If the comparison of version numbers fails, the initiated operation against the designated list entry is not performed and an indicative response code is returned.

Example of Version Number Verification

Consider the use of a version number in the scenario described in the prior art in which a program intends to read the data object and change the state of the object to "b" only if the current state of the object is "a".

The program sends a read command request to the SES facility and specifies a version-request-type 422 of compare and replace version number, a compare version number 421 of "a", and a (replacement) version number 411 of "b".

Note that no explicit locks were obtained and only one physical access to the SES facility was required. In addition, if the compare of the version numbers 304 and 421 fails, the operation at the SES is suppressed, the current list entry controls (VN 408, LEID 410, LN 430, LEK 449 or LEN 448, DLES 451, RC 407) are returned, and the expense of transferring the data object over the link to the CPC is avoided.

Lock Table Entry Processing

For the locking processes of comparison and replacement, command execution is conditionally performed, and is based on specification of the lock-request type (LRT 412), Local-lock bit value (LLB 413), and Lock-table-entry number (LTEN 414). When the global-lock managers (415 and 207) are compared, the local-lock manager as specified by the user identifier 418 and the local lock manager 208 are optionally compared. In order for the command to perform the requested list entry process, the requested lock processes must succeed. In order for the command to perform global lock manager replacement, it is not necessary for local lock manager comparison to succeed.

Global-lock-manager comparison is bypassed 60A if the lock-request-type (412) indicates no lock process requested.

If the list-structure type (LST) (204) indicates that the lock table was created and the lock-request-type (412) indicates compare global-lock-managers 605, then comparison of the global-lock-mangers occurs 606.

Global-lock-manager comparison 606 is always requested (605) before a lock-table entry (206) is written; or it is conditionally requested (605) before a list entry (302) is created, replaced, read, moved, or deleted, depending on the command and lock-request type (412).

When they match, the global-lock-manager comparison succeeds, and the command continues. When they do not match, the global-lock-manager comparison fails, and the lock-table-entry value (LTE 455) and indicative response code 407 are returned in the response operands (403).

The global-lock-managers (207) from the specified lock table entry (414) and the CGLM operand 415 are compared 606 when global-lock and local-lock-managers replacement is requested (702).

One or both of the objects contained within a lock-table entry (206) are replaced, depending (FIG. 7 at 701) on the lock-request type (412) specified.

When the LRT (412) specifies replace global and lock managers and the global-lock-manager comparison succeeds 606, the global-lock-manager (207) is replaced 703A with the user identifier (418) specified and the local-lock-managers (208) are replaced 703B with the local-lock-managers (416) specified.

Local-lock-manager comparison 705 occurs before a lock-table entry 206 is written or before a list entry 302 is created, replaced, read, moved, or deleted depending on the command and lock-request type 412.

When a local-lock-manager 208 object exists and a global-lock-manager replacement is requested (GLM path from 704) via the LRT 412, the global-lock-manager object (207) is replaced with the specified user identifier (418) at 709, the local-lock-manager-object value is ANDed with a mask of all ones except for the local-lock bit corresponding to the user identifier 418 specified. This ANDed value is then compared 706 with zero. When they match, the local-lock-manager comparison succeeds. When they do not match, the local-lock-manager comparison fails and an indicative response code (407) is generated at 707.

When a local-lock-manager object 208 exists and a local-lock-manager replacement is requested (the LLM path from 704), the local-lock bit corresponding to the user identifier specified is compared 705 with the local-lock bit value (413) specified. When they match, the local-lock-manager comparison fails. When they do not match, the local-lock-manager comparison succeeds.

When the local-lock-manager comparison fails, an indicative response code 407 is generated 707.

When the local-lock-manager comparison succeeds, the local-lock bit corresponding to the user identifier (418) specified is replaced 708 with the local-lock-bit-value (413) specified.

List Threshold Processing

FIG. 11 illustrates list threshold processing.

A list structure (111) is created on the first successful invocation of the allocate-list-structure command for a structure that does not already exist.

The type of count and limit that exists in the list controls is defined at allocation in the specified LST operand 447. This determines the counting method used 1101 in list threshold processing (list entries, or list elements).

The limits (303 or 313) may be changed by means of the write-list-controls command and read by means of the read-list-controls command.

When the counter indicator in the specified list-structure type (204) specifies that a list entry count and list entry count limit are defined and allocation is successful, the list controls (314) for each list (109) contain list-entry count (301) and a list-entry-count limit (303). When the counter indicator in the specified list-structure type specifies that a list element count and list element are defined and allocation is successful, the list controls for each list contain list-element count (312) and a list-element count limit (313).

The limit is compared with the count whenever a list entry 302 is created, moved, or replaced 1102.

The list-element counts (312) are updated 1106 whenever a list entry (302) is created, deleted, replaced, or moved to another list 109 and the count indicator in the list-structure type (204) specifies a list element count exists. (Counts are updated in both target and source lists for a "Move".)

The list-entry counts (301) are updated 1106 whenever a list entry (302) is created, deleted, or moved to another list (109) and the counter indicator in the list-structure type (204) specifies a list entry count exists. (Counts are updated in both target and source lists for a "Move".) The list-element-count-limit object (313) is compared 1105 with the list-element-count (312) whenever a list entry (302) is added (created or moved) to the list, or replaced with a change in size (the list entry size is specified in the Data List Entry Size (316) field of the List Entry Controls) and the counter indicator in the list-structure type (204) specifies a list element count exists. The new list element count is the sum of the former list element count (312) and the net add due to the new entry. If the new list element count matches or exceeds the list-element-count limit (313), then the list (109) is full. When the list (109) is full, no objects are updated and an indicative response code (407) is returned 1107.

The list-entry-count-limit object (303) is compared 1104 with the list-entry-count (301) whenever a list entry (302) is created or moved and the counter indicator in the list-structure (204) is zero. A list (109) is full when the number of list entries created matches or exceeds the list-entry-count limit (303). When the list (109) is full, no objects are updated and an indicative response code (407) is returned 1107.

Create/Replace List Entry Processing

The SES list structure allows the program to optionally specify that a list entry 302 is to be replaced if it already exists or created if it does not. Also, since the commands that perform the create/replace process execute atomically, the program does not have to provide explicit serialization while obtaining this information.

The program can request:

1. Unconditional replacement of a list entry,

2. Unconditional creation of a list entry, or

3. Conditional replacement or creation of a list entry.

Typically, when data is stored, it is necessary to know whether or not the storage is allocated. The SES list structure 111 allows the program to optionally specify that a list entry 302 be replaced if it already exists or be created if it does not. This eliminates first time logic in the program and allows for better performance, since the program does not need to know (through a request to the SES 110) or find out whether the list entry exists or not. Also, since it executes atomically, the program does not have to provide explicit serialization while obtaining this information.

One example of when a program would like to replace or create a list entry 302 is when the list entry represents recovery information and the program knows that any previously existing data of the same name is by definition older than the new data being written. In this case, the program does not care whether or not old data exists, it simply wants to write the new data.

The option to replace or create a list entry 302 is controlled by the write-request type 420.

List entry 302 creation 904 is requested on a write-list-entry command and the write-and-move-list-entry command, depending on the write-request type 420 specified. FIG. 9 is a diagram of the process flow for the create/replace process that occurs in the above mentioned two commands.

Creating a List Entry

Examine 901 the write-request type 420 to determine if it specified unconditional list entry creation.

When a write-request type specifies create, list-entry creation is unconditionally requested (Y path from 901); if list-entry name (310) already exists 902, an indicative response code 407 is returned 905.

When a write request type (420) specifies replace or create is specified, and the designated list entry does not exist ("N" path from 907), list entry creation is performed 904.

When the list set (202) and list (109) is not full and list-entry creation is requested, a list entry 302 is created 904.

A list entry (302) is created at the first entry position relative to the designated position 903, and the relative position of all succeeding entries is increased by one.

Replacing a List Entry

A list entry 302 can be replaced 910 on a write-list-entry command.

When a write-request type 420 specifies a replace or specifies a replace or create 906 and the designated list entry (302) exists 907, the list entry is replaced 910.

When a write-request type 420 of replace is specified and the designated list entry (302) does not exist 909, an indicative response code (407) is returned 905.

The position of a list entry (302) is not affected when it is replaced 910.

The processing of the list entry 302 continues 710 within the command that performs this process of state validation and serialization.

Advantages of Conditional Atomic Command Execution

The described mechanisms allow programs having access to a shared external storage to conditionally operate upon target data objects based on the successful verification of the presumed state of the object, and to optionally and independently change the verified presumed state of the object to another specified state in a single atomic operation. The following advantages are realized through use of the described mechanisms:

1. Costly explicit intersystem locking is reduced resulting in less contention for the locks, less contention for the physical paths to the locking facility, less contention at the locking facility, and less contention in the system software which manages the facility.

2. The number of accesses to the shared external storage is reduced resulting not only in improved path length for the request but also in less intersystem contention at the storage facility and on the physical paths to the facility.

3. Information related to the current state of the accessed data objects are returned in the command response area to the program for its inspection without requiring additional accesses to the facility.

4. Comparison of the serialization point and execution of the subsequent requests are atomic.

Serialization of List Entry Commands

The objects and operations described herein are utilized by programming in a wide diversity of protocols to satisfy the requirement to serialize access to a set of SES list objects across multiple SES list commands.

An example serves to illustrate the function afforded by these mechanisms. In the following example, the majority of operations are single-list-entry commands which create, read, delete, or move a list entry. Occasionally, the requirement exists to access multiple list objects associated with a particular list structure. More than one command would be used in this case.

FIG. 8 shows the process flow that occurs for this example.

Programming chooses to cause creation of a SES list structure at 801, through the allocate list structure command processed at 809 with at least one lock table entry 206 and a number of lists. Programming associates the first lock table entry with list number one, the second lock table entry with list number two, etc. at 802.

All requests to write, delete, move or read 805 a SES list entry (302) are combined with a lock request type (412) which compares at 807 for a zero value in the associated global-lock-manager (207).

When it is necessary to retrieve all the entries from a particular list, programming through the use of the write lock table entry command sets (at 804) the global-lock-manager value (207) to the user identifier 418 associated with the process that issues more than one list command.

Individual accesses to the SES list (109) operate at 808 correctly without contention when no process is in execution which is retrieving all of the list entries.

When a process is in execution to retrieve all of the list entries 302, single list entry requests which compare at 806 for a zero value in the global-lock-manager 207 fail at 807 and identify in the response operands the user identifier 418 associated with the process that is issuing multiple list commands.

Software protocols cause these single list entry requests to be delayed until the process reading multiple list entries (302) has completed.

Global Objects

The global objects identify the SES facility, describe its state, define its model-dependent limitations and summarize the status of its resources.

The fixed global controls are set at SES power-on reset and are not modified by any SES command.

The program-modifiable global controls are initialized at SES power-on reset and may be modified by subsequent SES commands.

The fixed global controls are summarized in the following table.

    ______________________________________
    Fixed Global Controls  Acronym
    ______________________________________
    SID limit              SL
    Total control space    TCS
    ______________________________________

    ______________________________________
    Program-Modifiable Global Controls
                             Acronym
    ______________________________________
    Free control space       FCS
    Free space               FS
    SID vector               SV
    Total space              TS
    ______________________________________

    ______________________________________
    List Limits              Acronym
    ______________________________________
    List-number limit        LNL
    Lock-table-entry-characteristic limit
                             LTEXL
    User-identifier limit    UIDL
    ______________________________________

    ______________________________________
    Fixed List-Structure Controls
                            Acronym
    ______________________________________
    List count              LC
    List-element characteristic
                            LELX
    List-structure type     LST
    Lock-table-entry characteristic
                            LTEX
    Lock-table-entry count  LTEC
    Maximum data-list-entry size
                            MDLES
    Maximum list-set-element count
                            MLSELC
    Maximum list-set-entry count
                            MLSEC
    Structure size          SS
    ______________________________________

    ______________________________________
    Program-Modifiable List-Structure Controls
                              Acronym
    ______________________________________
    List-set-element count    LSELC
    List-set-entry count      LSEC
    Nonzero-lock-table-entry count
                              NLTEC
    User-identifier vector    UIDV
    User-structure control    USC
    ______________________________________

    ______________________________________
    User Controls          Acronym
    ______________________________________
    List-notification token
                           LNT
    System identifier      SI
    User-attachment control
                           UAC
    ______________________________________

    ______________________________________
    List Controls          Acronym
    ______________________________________
    List-element count     LELC
    List-element-count limit
                           LELCL
    List-entry count       LEC
    List-entry-count limit LECL
    List-monitor table     LMT
    List-state-transition count
                           LSTC
    User list control      ULC
    ______________________________________

    ______________________________________
    List-Entry Controls     Acronym
    ______________________________________
    Data-list-entry size    DLES
    List-entry identifier   LEID
    List-entry key/list-entry name
                            LEK/LEN
    List number             LN
    Version number          VN
    ______________________________________

    ______________________________________
    List-Notification Operands
                            Acronym
    ______________________________________
    Non-empty state change  NESC
    List-notification-entry number
                            LNEN
    List-notification token LNT
    Summary update          SU
    ______________________________________