Method of managing resources in one or more coupling facilities coupled to one or more operating systems in one or more central programming complexes using a policy

Abstract

A method and system for managing one or more coupling facilities in a data processing system. An active policy is used to control resources located in the coupling facilities. The active policy can be changed such that control of the resources can be altered. Compatible changes are made immediately and incompatible changes are made at a subsequent time. Recorded in the active policy and in the coupling facilities is information regarding the resources. When the information in the active policy is not in synchronization with the information in the coupling facilities, a reconciliation technique is performed. The resources in the coupling facilities can be modified but prior to the modification, the intended modifications are stored in the active policy.

Claims

We claim:

1. A method to manage coupling facility resources (said resources) in a data processing system having one or more operating systems running on one or more processors coupled by one or more data transmission channels to one or more coupling facilities, said resources comprised of said one or more coupling facilities and one or more structures contained within said one or more coupling facilities, said method comprising the steps of:

using a policy stored in the data processing system for controlling said resources, said policy comprised of one or more active rules, current status of resource usage, and a pending policy; said active rules permit or disallow use of each of said one or more coupling facilities and define or disallow use of each of said one or more structures; said pending policy comprised of one or more pending rules;

identifying a set of changes by any of said operating systems comparing the said pending rules with the said active rules located in said policy;

modifying the said policy using the said set of changes to add, delete, or change active rules in said policy when the changes processed by the identifying step are found compatible with the active rules, and changes found incompatible with the active rules remaining pending for subsequent implementation; and

accessing by said one or more operation systems said active rules in said policy to allow users to obtain and release usage of said one or more structures contained within said one or more coupling facilities.

2. The method of claim 1, further comprised of defining one or more administrative polices, said administrative policy containing one or more rules to define use of each of said one or more coupling facilities and use of each of said one or more structures and activating one of said one or more administrative policies to create in said policy a pending policy.

3. The method of claim 2, wherein said policy and said one or more administrative policies are stored on a function data set shared by the said one or more operating systems.

4. The method of claim 2, wherein said activating step comprises an operator issuing a command from any of said one or more operating systems to start making changes to said policy.

5. The method of claim 4, wherein said issuing by an operator of a command is repeated prior to completing said identified set of changes.

6. The method of claim 1, wherein said policy is further comprised of:

checkpoint save area for storing intended modifications for allowing users to obtain and release usage of said structures; and

pending policy definition comprised of one or more pending rules to define use of each of said one or more coupling facilities and use of each of said one or more structures.

7. The method of claim 1, further comprising the step of implementing said incompatible changes.

8. The method of claim 7, wherein said implementing step comprises the step of deleting at least one of said coupling facilities associated with said incompatible changes when said structures contained within said at least one of said coupling facilities are no longer actively being used.

9. The method of claim 7, wherein said implementing step comprises the step of deleting one or more of said structures associated with said incompatible changes when said one or more structures to be deleted are no longer actively being used.

10. The method of claim 7, wherein said implementing step comprises the step of changing one or more active rules of one or more said structures associated with said incompatible changes when said one or more structures to be changed are no longer actively being used.

11. The method of claim 10, wherein said one or more active rules include definitions of said one or more coupling facilities to contain said structure, size limit for said structure, and number of users allowed to use said structure.

12. The method of claim 1, further comprising the steps of:

recording in said policy and in at least one of said coupling facilities information regarding said structures contained within said coupling facility and said users of said structures; and

adjusting said information in said policy and in said at least one coupling facilities when compared said information in said policy does not coincide with said information in said at least one of said coupling facilities.

13. The method of claim 12, wherein said adjusting step comprises the step of using said information stored in at least one of said coupling facilities to reconcile at least one of said coupling facilities and said policy.

14. The method of claim 13, wherein said information stored in at least one of said coupling facilities is used to make the information in at least one of said coupling facilities and said policy consistent.

15. The method of claim 14, wherein said information comprises one of information associated with said one or more structures and said users of said one or more structures.

16. The method of claim 12, wherein said adjusting step comprises adding structures contained within at least one of said coupling facilities to said policy in order to make at least one of said coupling facilities consistent with said policy.

17. The method of claim 12, wherein said adjusting step comprises deleting structures contained within at least one of said coupling facilities in order to make at least one of said coupling facilities consistent with said policy.

18. The method of claim 12, wherein said adjusting step comprises adding users of said one or more structures contained within at least one of said coupling facilities to said policy in order to make at least one of said coupling facilities consistent with said policy.

19. The method of claim 12, wherein said adjusting step comprises deleting users of said one or more structures contained within at least one of said coupling facilities in order to make at least one of said coupling facilities consistent with said policy.

20. The method of claim 12, wherein said adjusting step comprises ignoring information located in at least one of said coupling facilities in order to make at least one of said coupling facilities consistent with said policy.

21. The method of claim 1, wherein said accessing step further comprises the steps of:

recording intended modification in said policy; and

modifying said structures or said users of said structures; and

erasing intended modification from said policy.

22. The method of claim 21, wherein said step of modifying comprises one of allocating said one or more structures, deallocating said one or more structures, attaching said users of said one or more structures, and

detaching said users of said one or more structures.

23. The method of claim 21, wherein modification of said one or more structures or of said users of said structures is interrupted due to a predefined condition.

24. The method of claim 23, wherein one or more operating systems have connectivity by running said one or more processors coupled to at least one of said one or more coupling facilities and wherein said predefined condition comprises losing connectivity by one of said one or more operating systems making said modifications.

25. The method of claim 24, wherein a surviving operating system of said one or more operating systems uses said recorded intended modifications to perform said modifications.

26. The method of claim 23, wherein said predefined condition comprises having each of said one or more operating systems fail.

27. The method of claim 26, wherein a first of said one or more operating systems to recover from failure performs said modification using said recorded intended modifications.

Description

TECHNICAL FIELD

This invention relates in general to the field of data processing and, in particular, to providing a mechanism which enables customers to manage one or more coupling facilities located in a data processing system.

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. Each of the below listed applications is hereby incorporated by reference in its entirety:

"Configurable, Recoverable Parallel Bus," by N. G. Bartow et al., Ser. No. 07/839,657, (Docket No. PO9-91-066), Filed: Feb. 20, 1992 now U.S. Pat. No. 5,357,608;

"High Performance Intersystem Communications For Data Processing Systems," by N. G. Bartow et al., Ser. No. 07/839,652, (Docket No. PO9-91-067), Filed: Feb. 20, 1992 now U.S. Pat. No. 5,412,803;

"Frame-Group Transmission And Reception For Parallel/Serial Buses," by N. G. Bartow et al., Ser. No. 07/839,986, (Docket No. PO9-92-001), Filed: Feb. 20, 1992 now U.S. Pat. No. 5,267,240;

"Communicating Messages Between Processors And A Coupling Facility," by D. A. Elko et al., Ser. No. 07/860,380, (Docket No. PO9-91-006), Filed: Mar. 30, 1992 now abandoned;

"Sysplex Shared Data Coherency Method And Means," by D. A. Elko et al., Ser. No. 07/860,805, (Docket No. PO9-91-052), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,537,574;

"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 No. PO9-91-059), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,339,427;

"Command Quiesce Function," by D. A. Elko et al., Ser. No. 07/860,330, (Docket No. PO9-91-062), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,539,405;

"Storage Element For A Shared Electronic Storage Cache," by D. A. Elko et al., Ser. No. 07/860,807, (Docket No. PO9-91-078), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,457,793;

"Management Of Data Movement From A SES Cache To DASD," by D. A. Elko et al., Ser. No. 07/860,806, (Docket No. PO9-91-079), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,493,668;

"Command Retry System," by D. A. Elko et al., Ser. No. 07/860,378, (Docket No. PO9-92-002), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,392,397;

"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 No. PO9-92-003), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,331,673;

"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 No. PO9-92-004), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,388,266;

"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 No. PO9-92-005), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,394,592;

"Message Path Mechanism For Managing Connections Between Processors And A Coupling Facility," by D. A. Elko et al., Ser. No. 07/860,646, (Docket No. PO9-92-006), Filed: Mar. 30, 1992 now abandoned;

"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 No. PO9-92-007), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,390,328;

"Method And Apparatus For Performing Conditional Operations On Externally Shared Data," by J. A. Frey et al., Ser. No. 07/860,655, (Docket No. PO9-92-008), Filed: Mar. 30, 1992 now abandoned;

"Apparatus And Method For List Management In A Coupled DP System," by J. A. Frey et al., Ser. No. 07/860,633, (Docket No. PO9-92-009), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,410,695;

"Interdicting I/O And Messaging Operations In A Multi-System Complex," by D. A. Elko et al., Ser. No. 07/860,489, (Docket No. PO9-92-010), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,394,554;

"Method And Apparatus For Coupling Data Processing Systems," by Elko et al., Ser. No. 07/860,803, (Docket No. PO9-92-012), Filed: Mar. 30, 1992 now U.S. Pat. No. 5,317,739;

"Authorization Method For Conditional Command Execution," by Elko et al., Ser. No. 08/021,285, (Docket No. PO9-92-018), Filed: Feb. 22, 1993 now abandoned.

"A Dumping Service Facility For Multisystem Environment," by Elko et al., Ser. No. 08/073,909 (Docket No. PO9-92-068), Filed: Jun. 08, 1993;

"A Method And System For Capturing and Controlling Access To Information In A Coupling Facility," by Neuhard et al., Ser. No. 08/146,647 (Docket No. KI9-93-004), Filed Nov. 1, 1995; and

"A Method And System For Managing Data and Users Of Data In A Data Processing System," by Allen et al., Ser. No. 08/146,727 (Docket No. KI9-93-009), Filed Nov. 1, 1993, now U.S. Pat. No. 5,465,359.

BACKGROUND ART

Use of policy information provided by customers to control utilization of data processing resources is well known within the industry. For example, the Data Facilities Product (DFP) Systems Managed Storage (SMS) product from International Business Machines Corporation provides for the definition of policy information to control the placement and management of data sets on DASD. SMS policy support is described in DFSMS/MVS 1.1 Storage Administration Reference for DFP (SC26-4920), Chapters 2, 11 and 15, which is incorporated herein by reference in its entirety.

The SMS documentation describes the manner in which customers control a DASD configuration. In particular, there is a control data set called COMMDS (communication data set) that is shared and accessed by all systems in a SMS configuration. Each of the participating systems access COMMDS on a default of 15 secs (which can be changed from 1 to 999 secs). Inactive policies are kept in a data set called SCDS (Source Control Data Set). This is validated and activated through interactive programming services or operator command on any one of the systems in the configuration.

The process of activation puts the active policy in another data set called ACDS (Active Control Data Set) and records the change of the configuration in the COMMDS. All systems, when they access the COMMDS, recognize this and use the new ACDS and COMMDS. ACDS is also shared by all processors in a configuration. Therefore, there is a single policy that is active, is changeable through command from any system, is system wide and does not require system reinitialization. Some operator commands will result in updating ACDS and COMMDS. But, to add new processors, storage groups, volumes or libraries, the interactive programming services must be used to add, delete, or remove entries in an SCDS, validate and activate the new policy. If the validation step fails, the old configuration is retained. Because of the validation, there can be nothing incompatible between the old configuration and the new configuration defined by policy. The old set (SCDS, ACDS and COMMDS) is not checked with the new set.

There is no duplication of information in SMS between the ACDS and control information stored on DASD. Therefore, if the COMMDS or ACDS become unusable, the user can allocate a new one and copy the information from the SCDS, or activate the same or a different SCDS. SMS also keeps an in-storage copy of ACDS. Therefore, if an ACDS becomes unusable, all systems can continue to work.

Several disadvantages are associated with the current mechanisms for managing permanent storage facilities. Notably, the current techniques do not assist in reclaiming storage areas when those areas are no longer needed and processing associated with policies which are used to direct allocation of storage areas assume that no errors have been made by the system's administrator.

Reclaim of storage areas occurs outside the current mechanisms for storage allocation policy management. There are no current facilities for tracking the set of users associated with an allocated storage area, no processing for maintaining the status of users of an allocated storage area at the storage facility, and no capabilities for insuring reclaim of storage areas no longer needed occurs in a timely way and transparently to users of the storage area should changes in the configuration make it not possible to access the storage facility at the time a storage area is to be released. As there currently does not exist any mechanism for tracking users of a storage area, nor management of resource re-use, there are no facilities for managing delays in reclaiming storage areas nor any possible inconsistencies between policy information regarding storage areas in use and their users, and the status recorded at the storage facility.

As it is always assumed that any and all changes made by the systems administrator are to take immediate effect, there is no management of incompatible changes nor pending policy changes.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method for managing one or more coupling facilities located in a data processing system. An active policy for controlling resources in at least one of the coupling facilities is used. The active policy is changed in order to alter control of the resources. Compatible changes to the active policy are made immediately and incompatible changes are stored for subsequent implementation.

In a further embodiment, the incompatible changes are implemented. In one example, they are implemented by removing use of the coupling facilities associated with the incompatible changes when the resources located within the coupling facilities are no longer actively being used.

In another embodiment of the invention, a method for managing one or more coupling facilities is provided. In at least one of the coupling facilities and an active policy, information regarding resources stored within the coupling facility is recorded. When the information in the coupling facility and the active policy is not in synchronization, it is reconciled.

In another embodiment of the invention, a method for managing resources of coupling facilities located in a data processing system is provided. One or more of the resources located within a coupling facility can be modified. However, prior to modifying the resources, the intended modifications are recorded.

In another aspect of the invention, a system for managing one or more coupling facilities located in a data processing system is provided. An active policy for controlling resources in at least one of the coupling facilities is used. Means for changing the active policy is provided such that control of the resources can be altered. Compatible changes to the active policy are made immediately and incompatible changes are stored for subsequent implementation.

In another embodiment of the invention, a system for managing one or more coupling facilities is provided. Means are provided for recording in at least one of the coupling facilities and an active policy information regarding resources stored within the coupling facility. When the information in the coupling facility and the active policy is not in synchronization, means are including for reconciling the information.

In another embodiment of the invention, a system for managing resources of coupling facilities located in a data processing system is provided. Means are included for modifying one or more of the resources located within a coupling facility. Means are also provided for recording the intended modifications prior to modifying the resources.

In accordance with the principles of the present invention, a mechanism is provided which advantageously allows automation of the operation of functions by providing administrative specification rather than requiring operator actions or program intervention. Further, the present invention enables the changing of an active policy wherein incompatible changes are stored and executed when possible. In addition, if the active policy becomes out of synchronization with the Coupling facilities, capabilities are provided for reconciling the active policy with the coupling facilities. Further, the present invention advantageously enables the recordation of intended modifications to resources within the coupling facilities prior to making the modifications. This aids in recovery processing of the coupling facilities if the operating systems should fail or lose connectivity with the coupling facility.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 depicts one example of a block diagram of a data processing system incorporating the management facility of the present invention;

FIG. 2 depicts one example of a coupling facility including multiple storage structures, in accordance with the principles of the present invention;

FIG. 3 depicts one embodiment of a three-level storage hierarchy in a network of attached processors, in accordance with the principles of the present invention;

FIG. 4 depicts one example of the controls associated with a cache structure, in accordance with the principles of the present invention;

FIG. 5 depicts one example of a local-cache control block associated with each local cache of the data processing system depicted in FIG. 1, in accordance with the principles of the present invention;

FIG. 6 depicts one embodiment of a directory information block in connection with the directory depicted in FIG. 3, in accordance with the principles of the present invention;

FIG. 7 depicts one example of a list structure, in accordance with the principles of the present invention;

FIG. 8 depicts one example of the controls associated with the list structure of FIG. 7, in accordance with the principles of the present invention;

FIG. 9 depicts one embodiment of a list-user control block, in accordance with the principles of the present invention;

FIG. 10 depicts one example of the controls associated with a list within the list structure of FIG. 7, in accordance with the principles of the present invention;

FIG. 11 illustrates one example of a list entry control block, in accordance with the principles of the present invention;

FIG. 12 depicts one example of a message command/response block, in accordance with the principles of the present invention;

FIG. 13 depicts one embodiment of request/response operands, in accordance with the principles of the present invention;

FIG. 14 illustrates one example of an overview diagram depicting an active policy coupled to central processing complexes, in accordance with the principles of the present invention;

FIG. 15 depicts one embodiment of the fields associated with the active policy of FIG. 14, in accordance with the principles of the present invention;

FIG. 16 illustrates one example of an overview diagram depicting initiation of a SETXCF START or SETXCF STOP operator command, in accordance with the principles of the present invention;

FIGS. 17a-17c depict one embodiment of the logic associated with a policy change routine, in accordance with the principles of the present invention;

FIG. 18 illustrates one embodiment of the logic associated with a policy change signal process, in accordance with the principles of the present invention;

FIGS. 19a-19c depict one embodiment of the logic associated with a policy reconciliation routine, in accordance with the principles of the present invention;

FIGS. 20a-20c depict one embodiment of an active policy to coupling facility subroutine associated with the policy reconciliation routine of FIGS. 19a-19c, in accordance with the principles of the present invention;

FIG. 21 depicts one embodiment of a policy reconciliation not allocated subroutine, in accordance with the principles of the present invention;

FIG. 22 depicts one embodiment of a policy reconciliation different sysplex subroutine, in accordance with the principles of the present invention;

FIG. 23 depicts one embodiment of the logic associated with a policy reconciliation different structure subroutine, in accordance with the principles of the present invention;

FIG. 24 illustrates one example of the logic associated with a detach subroutine for the policy reconciliation routine of FIGS. 19a-19c, in accordance with the principles of the present invention;

FIGS. 25a-25b depict one embodiment of the logic associated with a detach command, in accordance with the principles of the present invention;

FIG. 26 depicts one embodiment of a policy reconciliation user reconcile subroutine, in accordance with the principles of the present invention;

FIG. 27 depicts one embodiment of a deallocate subroutine associated with the policy reconciliation subroutine of FIGS. 19a-19c, in accordance with the principles of the present invention;

FIGS. 28a-28c illustrate one example of a coupling facility to active policy subroutine associated with the policy reconciliation routine of FIGS. 19a-19c, in accordance with the principles of the present invention;

FIGS. 29a-29e depict one embodiment of the logic associated with a connect service, in accordance with the principles of the present invention;

FIGS. 30a-30b depict one embodiment of the logic associated with a checkpoint cleanup routine, in accordance with the principles of the present invention;

FIG. 31 depicts one embodiment of the logic associated with a deallocate structure command, in accordance with the principles of the present invention;

FIGS. 32a-32b depict one embodiment of the logic associated with an allocate structure command, in accordance with the principles of the present invention;

FIG. 33 depicts one embodiment of the logic associated with an attach command, in accordance with the principles of the present invention;

FIG. 34 illustrates one embodiment of the logic associated with a notification for a connect service, in accordance with the principles of the present invention;

FIGS. 35, 35a-35d depict one embodiment of the logic associated with a disconnect/failed routine, in accordance with the principles of the present invention;

FIG. 36 depicts one embodiment of the logic associated with a notification for disconnect/ failed routine, in accordance with the principles of the present invention;

FIG. 37 depicts one embodiment of the logic associated with an end of task routine, in accordance with the principles of the present invention;

FIG. 38 depicts one embodiment of the logic associated with an end of memory routine, in accordance with the principles of the present invention;

FIG. 39 illustrates one embodiment of the logic associated with a coupling facility cleanup routine, in accordance with the principles of the present invention;

FIGS. 40a-40d depict one embodiment of the logic associated with an event exit response routine, in accordance with the principles of the present invention; and

FIGS. 41a-41b depict one embodiment of the logic associated with a force service, in accordance with the principles of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In accordance with the principles of the present invention, a mechanism is provided which enables customers to manage one or more coupling facilities located in a data processing system. In particular, an active policy is provided through which customers of the data processing system can control utilization of the coupling facilities. Customers are given the ability to initially define the active policy and make subsequent changes to the policy. As described below, the policy can be changed during ongoing operation of the system. Some changes may be made immediately, while others may have to wait, as described in detail below. In addition, a capability is provided for tracking the status of changes. Further, if information in a coupling facility is out of synchronization with information stored in the active policy, a reconciliation mechanism is provided.

FIG. 1 is a block diagram of a data processing system 10 incorporating the management facility of the present invention. Data processing system 10 includes multiple central processing complexes (CPCs) 12a through 12n which are coupled to an input/output (I/O) system 14 and a coupling facility 16. (As used herein, central processing complexes 12a-12n are collectively referred to as central processing complex (CPC) 12.) The main components associated with each central processing complex 12, input/output system 14 and coupling facility 16 are described in detail below. (In another embodiment, data processing system 10 (also referred to as a sysplex) may include a plurality of coupling facilities. Further, while the invention is described in relation to a multisystem environment, such as the one depicted in FIG. 1, it can also be used with a single system environment, which includes one central processing complex 12.)

Each of the CPCs 12a-12n may be an International Business Machines' (IBM) system following the Enterprise Systems Architecture/390 Principles of Operation as described in IBM publication SA22-7201-00, which is hereby incorporated by reference in its entirety. Each of CPCs 12a-12n includes one or more central processing units (CPUs) (not shown) which executes an operating system 13a-13n, respectively. As used herein, operating systems 13a-13n are collectively referred to as operating system 13. In one instance, operating system 13 is an International Business Machines' Multiple Virtual Storage (MVS) operating system for controlling execution of programs and the processing of data, as is well known. In addition, in accordance with the principles of the present invention, each operating system 13a-13n includes a management facility 15a-5n, respectively, for managing one or more coupling facilities in a data processing system, as described in detail herein.

In addition, each CPC 12a-12n contains a plurality of intersystem (I/S) channels 18a-18n, a plurality of local caches 20a-20n, and a plurality of input/output (I/O) channels 22a-22n, respectively. (Local caches 20a-20n are referred to herein collectively as local cache 20. Similarly, intersystem channels 18a-18n and input/output channels 22a-22n are collectively referred to as intersystem channels 18 and input/output channels 22, respectively.) It will be understood that input/ output channels 22 are part of the well known channel subsystem (CSS), which also includes intersystem channels 18 disclosed herein, even though channels 18 and 22 are shown separately in FIG. 1 for convenience.

Coupled to each CPC 12a-12n is an external time reference (ETR) 24, which provides time stamps of control information to be written into a log to document recovery from failures, backing out of undesired operations and for audit trails. External time reference 24, which uses fiber optic interconnect cables, synchronizes the time clocks (not shown) of CPCs 12a-12n to a precision equal to or greater than the duration of the shortest externally visible operation. External time reference 24 provides for cable length propagation time differences, where those differences are important, in order to be able to maintain synchronization to within the length of the mentioned external operation.

As depicted in FIG. 1, each central processing complex 12a-12n is coupled via a link 26a-26n, respectively, to input/output system 14. Input/output system 14 includes, for example, a dynamic switch 28, which controls access to multiple input/output (I/O) control units (CU) 30a through 30n and one or more direct access storage devices (DASD) D1 through DN (collectively referred to as DASD 32), which are controlled by the control units. Dynamic switch 28 may be an ESCON Director Dynamic Switch available from IBM Corporation, Armonk, N.Y. Such a dynamic switch is disclosed in U.S. patent application Ser. No. 07/429,267 for "Switch and its Protocol," filed Oct. 30, 1989 and assigned to the owner of the present invention, which application is incorporated herein by reference in its entirety. As is known, input/output commands and data are sent from a central processing complex 12a-12n to an I/O control unit 30a-30n through dynamic switch 28 by means of I/O channels 22a through 22n of the respective CPCs 12a through 12n. Channel programs for a particular I/O channel are established by channel command words (CCWs), as is well known in the art.

One or more of direct access storage devices 32 includes one or more data sets 31a-31n, respectively. In particular, DASD 32 may include one or more couple data sets for storing status information relating to one or more CPCs 12 (i.e., read information for all CPCs and write information relating to one CPC) and/or one or more function data sets for storing the active and administrative policy information, as described in detail below. In one embodiment, the couple and function data sets are not stored on the same DASD data set or volume.

Each central processing complex 12a-12n is also coupled via a bus 34a-34n, respectively, to coupling facility 16. Coupling facility 16 contains storage accessible by the CPCs, performs operations requested by programs in the CPCs and maintains status regarding structures and users of structures located within the coupling facility. The coupling facility enables sharing of data, which is directly accessible by multiple operating systems. As described further below, the coupling facility contains control information regarding shared data and may contain shared data. In one embodiment, coupling facility 16 is a structured-external storage (SES) processor and includes, for example, a plurality of intersystem (I/S) channels 36 for communicating with intersystem channels 18a-18n, one or more buffers 38 located within intersystem channels 36 for storing data received from intersystem channels 18a-18n, message processors 40a -40n for handling messages, a selector 44 for directing message requests received over an intersystem channel to a message processor 40a -40n, a coupling facility cache 46 and a coupling facility list 52, which are described in further detail below. Even though only one coupling facility 16 is shown in the embodiment of FIG. 1, it will be understood that multiple coupling facilities may be provided for, each with its own I/S channels and message paths connected to all or some subset of the CPCs 12a-12n.

Coupling facility cache 46 of coupling facility 16 is one example of a coupling facility storage structure. As shown in FIG. 2, coupling facility 16 includes multiple storage structures, such as storage structures 46, 52, 54 and 56. The storage structures include, for instance, list structures (for example, 52 and 54) and cache structures (for example, 46 and 56). Each coupling facility storage structure contains data objects and control objects. The data objects may reside in any storage location, whereas the control objects are generally restricted to control area 58.

Allocated structures (such as cache structures 46 and 56 and list structures 52 and 54) reside in separate coupling facility storage locations and are located by a structure identifier (SID). The SID value provides an identification of a target structure by a command. A command of a particular structure type, such as a cache-structure or list-structure command, may only address or alter the contents of a single structure of the given type. The allocation of a structure is described in detail below.

The partitioning of the coupling facility storage and control area 58 into structures, as shown in FIGS. 2, 3 and 7, is managed by the operating system program. The data objects are organized in tables or lists with an optional adjunct data area. The remaining objects are controls. The relative amount of storage assigned to data and control objects is determined by program-specified parameters in the allocation commands.

Referring to FIG. 3, a three-level storage hierarchy in a network of attached processors 12a-12n is described. The lowest level of the hierarchy is DASD 32, the intermediate level is coupling facility cache structure 46, and the highest level is local cache 20 (e.g., local caches 20a and 20b). Each of these levels is described below.

Direct access storage devices 32 include data blocks which represent data stored in the devices. Local caches 20a and 20b include, for instance, a 16-byte name field 60A, 60B for referencing data; a data field 64A, 64B for storing the data; an optional adjunct data field 66A, 66B for additional data; and a state field 68A, 68B, respectively, for indicating whether the data is valid or invalid. When the data is located in local cache 20, the state of the data is either valid or invalid. The data is validated by CPU instructions and invalidated by, for example, SES-write and SES-invalidate operations. The valid state of the data is tested by a CPU instruction. A valid named data object must be registered in a coupling facility cache directory, described below, in order to maintain local cache coherency. Local cache coherency is maintained by the invalidation process. A registered local-cache entry may test as invalid.

Cache structure 46 includes, for instance, a number of cache structure controls 69, a number of local-cache control blocks (LCCB) 70, a directory 72, a data area 74, and an adjunct area 75, each of which is explained in further detail below.

As shown in FIG. 4, cache structure controls 69 include, for instance, the following controls:

(a) Total-Directory-Entry Count (TDEC): A value that specifies the number of directory entries allocated for the cache.

(b) Total-Data-Area-Element Count (TDAEC): A value that specifies the number of data-area elements allocated for the cache.

(c) Adjunct-Assignment Indicator (AAI): A value that indicates the presence or absence of adjunct areas. Two possible values are: adjunct areas not assigned; adjunct areas assigned. When adjunct areas are assigned, an adjunct area is associated with each directory entry.

(d) Maximum Storage Class (MSC): A value that specifies the number of storage classes. Valid storage class values range from one to the maximum storage class value.

(e) Maximum Cast-Out Class (MCC): A value that specifies the number of cast-out classes. Valid cast-out class values range from one to the maximum cast-out class value.

(f) Data-Area-Element Characteristic (DAEX): A value that specifies the number of bytes in each data-area element. The size of the data-area element in bytes is the product of 256 and 2 raised to the power of the value specified in the data-area element characteristic.

(g) Maximum Data-Area Size (MDAS): A value that specifies the maximum allowable size of a data area as an integral multiple of the data-area-element size. The maximum data-area size is set by the program when the cache is allocated.

(h) Structure Size (SS): A value that specifies the number of units of, for example, SES storage allocated for the cache.

(i) Maximum Structure Size (MXSS): A value that specifies the maximum number of units of SES storage that can be allocated for the cache.

(j) Minimum Structure Size (MNSS): A value that specifies the minimum number of units of SES storage that can be allocated for the cache.

(k) Structure Authority (SAU): A value associated with each bit in a SID vector, described herein. The structure authority has two parts: A time of day (TOD), which reflects the moment when a system was allocating the structure and the system ID used to make the TOD unique. Paired with the sysplex name, it further identifies who caused the structure to be allocated.

(l) User Structure Control (USC): A value defined by the user.

(m) LCID Vector (LCIDV): A bit string with an initial value of zero. The bit positions start at zero and increase sequentially to the local-cache-identifier limit. The bit at position (i) in the string is set to one when a local cache is attached with a local-cache identifier (LCID) value of (i). When the bit is one, the local-cache-identifier is assigned. The bit at position (i) is reset to zero when the local cache is detached and LCID unassignment is requested, when the cache structure is de-allocated, or when a SES power-on reset occurs. When the bit is zero, the local-cache-identifier is not assigned.

A local cache may have, for instance, local-cache states and local-cache-identifier states, described below:

Local-Cache States: A cache structure local cache exists when the associated local-cache identifier is assigned. When a local cache exists, it is either in the attached or the detached state. A local cache is placed in the attached state by an attach-local-cache command, described below. A local cache is placed in the detached state by a detach-local-cache command, also described below, when the detachment process is complete.

Local-Cache-Identifier States: A local-cache identifier is in the assigned state when the associated assigned bit in the local-cache-identifier vector is one. A local-cache identifier is placed in the assigned state by the attach-local-cache command. A local-cache identifier is in the unassigned state when the associated bit in the local-cache-identifier vector is zero. A local-cache identifier is placed in the unassigned state by the detach-local-cache command, depending on LCID-unassignment control, described herein.

As mentioned above, in addition to structure controls 69, cache structure 46 includes local-cache control block 70. Local-cache control block 70 includes a number of local cache controls, described below, which are initialized when a local cache is attached to a coupling facility cache. In one embodiment, local-cache control block 70 includes the following fields (FIG. 5):

(a) Local-Cache Identifier (LCID): A value that identifies a local cache. The controls are deleted when the local-cache identifier is unassigned and they are valid when the local-cache identifier is assigned.

(b) Attachment Status (AS): A control that describes the state of the attachment of a local cache. When the value of the attachment status is one, the local cache is active. When the value of the attachment status is zero, the local cache is inactive.

The attachment status controls the execution of commands that specify the local cache. When the local cache is active, all commands that specify the local cache are processed normally. When the local cache is inactive, all commands that specify the local cache, except attach local-cache, detach local-cache and read local-cache information are suppressed with a request-exception condition.

(c) Local-Cache Token (LCT): A value used to identify the local cache on the CPC.

(d) Local-Cache Authority (LCAU): A value set by the program when the local cache is attached.

(e) System Identifier (SYID): A value specified by the program when a message path, used to communicate commands and messages (as described in co-pending U.S. patent applications entitled, "Communicating Messages Between Processors And A Coupling Facility," by D. A. Elko et al., Ser. No. 07/860,380, (Docket No. PO9-91-006), Filed: Mar. 30, 1992 and "Message Path Mechanism For Managing Connections Between Processors And A Coupling Facility," by D. A. Elko et al., Ser. No. 07/860,646, (Docket No. PO9-92-006), Filed: Mar. 30, 1992, each of which is hereby incorporated herein by reference in its entirety) is activated. The system identifier is maintained in a message-path status vector and copied into the local cache controls when an attach-local-cache command is communicated over the message path.

(f) Attachment Information (AINF): A value set by the program when the local cache is attached.

(g) Detachment Restart Token (DURT): A value used to indicate how far along a detachment process has proceeded.

Referring back to FIG. 3, cache structure 46 also includes a directory 72. Directory 72 is a collection of directory entries positioned into storage classes and arranged as a fully associative array. The directory is a repository of state and location information for the storage hierarchy. The subset of changed directory entries is additionally positioned into cast-out classes. As described with reference to FIGS. 3 and 6, directory 72 includes a name field 78, a state field 80 for indicating the state of each directory entry and a register field 82, described below. Whenever a named data object is placed in the higher two levels of the storage hierarchy (i.e., coupling facility cache structure 46 and local cache 20), its name is registered in name column 78 and its state is registered in state column 80 by coupling facility cache directory 72. In general, state information indicates whether the data is changed, unchanged, locked for cast-out, or resident in coupling facility 16. In particular, state field 80 includes:

(a) A User-Data Field (UDF): The user-data field contains a value that is associated with the data when it is initially changed in the SES cache and is maintained until the data area is re-used. The user-data field is valid when the data is cached as changed.

(b) A Storage Class (SC): A value which identifies the storage class assigned for the name.

(c) A Change Indicator (C): A value which, in conjunction with the cast-out lock, indicates the changed state of the data. When the change bit is one, the data is cached as changed. When the change bit is zero and the data is not locked for cast-out, the data is either not cached, or is cached but not changed. When the change bit is zero and the data is locked for cast-out, the data is cached as changed. Whenever the data is in the changed state, the most recent version of the data resides in the cache. When the change bit is one, the data bit must also be one.

(d) A Data-Cached Indicator (D): A value which indicates whether the data is located in the SES cache. When the data bit is one, the data is cached. When the data bit is zero, the data is not cached.

(e) A Cast-Out-Parity-Bits Indicator (CP): A field which indicates the current assignment of the cast-out parity. Three possible values are: cast-out parity is zero; cast-out parity is one; the cast-out parity is unknown.

(f) A Cast-Out Class (CC): A value which identifies the cast-out class assigned for the name.

(g) A Cast-Out-Lock Value (CLV): A value which indicates the cast-out state of the data. When the cast-out lock is zero, the data is not being cast-out. When the cast-out lock is not zero, the value of the first byte of the cast-out lock identifies the local cache that is casting out the data block from the SES cache to DASD. The value of the second byte identifies the cast-out process on the local system. When the cast-out lock is not zero, the data bit must be one.

(h) A Data-Area Size (DAS): A value that specifies the size of the data area as an integral multiple of the data-area-element size. The initial value is zero when the directory entry is assigned and is zero until the data bit is set to one.

In addition to the above, register 82 is a table containing information on the location of the locally cached copies of the data block. Each row in the table corresponds to an attached local cache. The columns contain the local cache identifier (LCID), local-cache-entry number (LCEN) and a valid bit (LVI) for the local-cache-entry number. A valid local-cache-entry number is registered in the local-cache register when the registration process is executed for the specified name and local cache. A local-cache-entry number is invalidated when a local cache is detected, or when an invalidate-complement-copies process is executed for the specified name and the local cache is a member of the set of local caches being invalidated. The LCEN field is invalid, when LVI is zero.

Location information includes which of the local caches 20a-20n contains a copy. Certain SES-read and SES-write commands register the local cache copy in coupling facility directory 72. SES write and SES-invalidate commands remove the registration and invalidate local copies.

Cache structure 46 further includes data areas 74 and optional adjunct data areas 75. The data sizes are variable with the range of variability being, in one embodiment, between 1 and n times the data-area element size. The data-area element size is fixed for each coupling facility cache structure 46 and is a power of 2 with a minimum size of 256 bytes.

Coupling facility cache 46 is normally smaller than DASD storage 32. Thus, periodically, the changed data is transferred from cache 46 to the backing DASD 32 (FIG. 3). This process, called cast-out, is controlled by the operating system program. In one embodiment, a control associated with a cast-out class includes a cast-out class count, which indicates the number of elements associated with the cast-out class. Cast-out involves for a coupling facility, such as a SES facility, the following operations:

A SES-read for cast-out operation is issued that sets the cast-out serialization and copies the data block to main storage which may or may not be put in local cache 20.

An I/O operation is executed that copies the data block to DASD 32.

A SES-unlock cast-out locks operation is issued that releases the cast-out serialization.

Multiple cast-out processes may co-exist for a single one of local caches 20a-20n. Whenever data is locked for cast-out, an identifier for local cache 20a-20n and an identifier for the cast-out process are placed in directory 72. This is disclosed in U.S. patent application Ser. No. 07/860,806 for "Management of Data Movement from a SES Cache to DASD" by D. A. Elko, et al. (Attorney Docket No. PO9-91-079), incorporated herein by reference in its entirety as noted.

Described in detail above is one example of a cache storage structure. In addition to cache structures, there are list structures, such as list structure 52, depicted in FIGS. 2 and 7. Referring to FIG. 7, the contents of a list structure, such as list structure 52, are described in detail.

List structure 52 resides within coupling facility 16. As shown in FIG. 7, in one embodiment, coupling facility 16 is coupled to processor storage 90a-90n located within each CPC 12a-12n, respectively. List structure 52 includes list-structure controls 92, user controls 94 and, optionally, a lock table 96, and/or a list set 98. List set 98 includes list controls 100 and list-entry controls 102. Each of the components of list structure 52 is described in detail below.

List structure controls 92 contain attributes of the structure and are initialized when list structure 52 is created. One example of the controls associated with list structure controls 92 is depicted in FIG. 8. Referring to FIG. 8, list structure controls 92 include:

(a) Maximum Data-List-Entry Size (MDLES): An object or field that specifies the maximum size of the data list entry.

(b) List-Structure Type (LST): An object or field that indicates the list objects created on allocation. A field contains a counter indicator (CI), a lock indicator (LI), a data indicator (DI), an adjunct indicator (AI), a name indicator (NI) and a key indicator (KI).

The counter indicator specifies that either: a list-entry count and list-entry-count limit are defined or a list-element count and list-element-count limit are defined.

The lock indicator specifies whether or not a lock table is created.

The data and adjunct indicators specify whether: no list-set is created; list entries have adjunct only; list entries have data only; or list entries have data and adjunct in the list entries.

The name indicator specifies whether or not list entries are named.

The key indicator specifies whether or not the list entries are keyed.

(c) Lock-Table-Entry Characteristic (LTEX): An object or field that specifies the number of bytes in each lock-table entry. The number of bytes is the product of 2 raised to the power of the LTEX value.

(d) List-Element Characteristic (LELX): An object or field that specifies the number of bytes in each list element. The number of bytes is the product of 256 and 2 raised to the power of the LELX value.

(e) Minimum Structure Size (MNSS): A value that specifies the minimum number of units of SES storage that can be allocated for the list.

(f) Lock-Table-Entry Count (LTEC): An object or field that specifies the number of lock-table entries allocated.

(g) List Count (LC): An object or field that specifies the number of lists created.

(h) Structure Size (SS): An object or field that specifies the amount of storage allocated.

(i) Maximum Structure Size (MXSS): A value that specifies the maximum number of units of SES storage that can be allocated for the list.

(j) Maximum List-Set-Element Count (MLSELC): An object or field that specifies the maximum number of list elements that are available for assignment to list entries or retry-data blocks, or both, in the list set.

(k) List-Set-Element Count (LSELC): An object or field that specifies the number of list elements that have been assigned to list entries or retry-data blocks, or both, in the list set.

(l) Non-Zero-Lock-Table-Entry-Count (NLTEC): An object or field that specifies the number of non-zero lock-table entries that exist in the structure.

(m) Maximum List-Set-Entry Count (MLSELC): An object or field that specifies the maximum number of possible list entries in a list set.

(n) List-Set-Entry Count (LSEC): An object or field that specifies the number of existing list entries in the list set.

(o) Structure Authority (SAU): A value associated with each bit in the SID vector.

(p) User Structure Control (USC): A field per structure defined by the user.

(q) User-Identifier Vector (UIDV): An object or field that specifies the assigned UIDs, described below.

Referring back to FIG. 7, user controls 94 are created and initialized when the list-structure user is attached. In one embodiment, user controls 94 include the following fields (FIG. 9):

(a) A User Identifier (UID): A value that identifies an attached list user. A user identifier is either in the assigned or the unassigned state. A user identifier is in the assigned state when the associated assigned bit in the user-identifier vector is one. A user identifier is placed in the assigned state by the attach-list-structure-user command. A user identifier is in the unassigned state when the associated assigned bit in the user-identifier vector is zero. A user identifier is placed in the unassigned state by the detach-list-structure-user command, depending on detachment-request type, described below.

(b) A User State (US): A field that specifies the state of the user. The value has the following encoding: the user is detached; the user is attached. A list structure user exists when the associated user identifier is assigned. When a list structure user exists, it is either in the active or the inactive state. A user is placed in the active state by the attach-list-structure-user command. A user is placed in the inactive state by the detach-list-structure-user command when the detachment process is complete.

(c) A List-Notification Token (LNT): A value that specifies a list-notification vector to the system.

(d) A User Authority (UAU): A value that is compared and conditionally updated.

(e) A System Identifier (SYID): A value specified by the program when a message path is activated. The system identifier is maintained in the message-path status vector and copied into the user controls when an attach-list-structure-user command is communicated over the message path.

(f) A User-Attachment Control (UAC): A field per attached user defined by the user.

(g) A Detachment Restart Token (DURT): A value used to indicate how far along a detachment process has proceeded.

Referring once again to FIG. 7, lock table 96 consists of a sequence of one or more lock table entries 97 identified by a lock-table-entry number (LTEN). In one embodiment, lock table entry 97 includes a lock-table-entry number (LTEN), which starts at zero and runs consecutively and a lock-table-entry value (LTEV), including a global-lock manager (GLM) object and optionally, a local-lock-manager (LLM) object or both. The lock-table entry format is determined by the list-structure type located within list structure controls 92.

Commands associated with list structure 52 provide a means for updating lock-table entry 97. That is, a command may compare global-lock managers (GLM) and conditionally replace a global-lock manager (GLM), a local-lock manager (LLM), or both the global-lock and local-lock managers (GLM) and (LLM). The list commands also provide a means for reading an entry in lock-table 96 or the next non-zero lock-table entry, or for clearing lock table 96.

As previously mentioned, also contained within list structure 52 is list set 98. In one example, list set 98 includes one or more lists 99 represented by list controls 100, which are numbered consecutively, starting at zero. In one embodiment, list controls 100 include the following controls, as depicted in FIG. 10:

(a) List-Entry-Count Limit (LECL): An object or field that specifies the maximum number of possible list entries in a list. This object is initialized to the maximum list-set-entry count when a list structure is created.

(b) List-Entry Count (LEC): An object or field that specifies the number of list entries currently in the list.

(c) List-State-Transition Count (LSTC): An object or field that specifies the number of empty to not-empty list state transitions that have occurred.

(d) List Authority (LAU): A value that is compared and conditionally updated. The LAU is initialized to zeros.

(e) User List Controls (ULC): A field per list defined by the user.

(f) List-Monitor-Table: The list-monitor table contains information used to process the list-notification vector of each user who has registered interest in the state transitions of the list.

The list-monitor table is a sequence of objects, called list-monitor-table entries. The number of list-monitor-table entries is determined when the table is created and is equal to the maximum number of list-structure users. The list-monitor-table entries are numbered from zero to the user-identifier limit and are indexed by the user identifier (UID).

Each list-monitor-table entry has a list-monitoring-active-bit object, a list-notification-request-type object and a list-notification-entry-number object, each of which is described below:

(1) List-Monitoring-Active Bit (LMAB): An object or field that specifies whether the user associated with the list-monitor-table entry is monitoring the list-state transitions of the list.

When a user is not monitoring a list, all previously issued list-notification commands on behalf of the associated user for this list are complete.

(2) List-Notification-Request Type (LNRT): An object or field that indicates whether the list-notification-vector summaries are to be updated when an empty to not-empty state transition occurs on a monitored list.

(3) List-Notification-Entry Number (LNEN): An object or field that specifies a list-notification-vector entry.

When a list-state transition occurs, one or more list-notification commands are initiated for each user who is monitoring the list to the system which attached the user. All the list-notification commands initiated as a result of the list-state transition are initiated before the command that caused the list-structure transition is completed.

The list-notification command provides the information necessary for the system to update one list-notification entry and, when requested, the associated list-notification summaries, to reflect the new list state.

A user becomes a list monitor by registering with the list by means of a registered-list-monitor command. A user ceases to be a list monitor by deregistering from the list by means of a deregister-list-monitor command or by detaching from the list structure by means of a detach-list-structure-user command.

A list-notification command issued to a system for a user as a result of a not-empty-to-empty list-state transition must complete before another list-notification command on behalf of the same list and user that specifies the opposite list-state transition may be issued.

All SES list-structure commands capable of adding, deleting, or moving a list entry execute the list-monitor-notification process for each user monitoring a list that changes state.

When a transition notification is initiated to a system, any previously initiated but unsent notifications for the same list and user may be purged.

Each list 99 consists of a sequence of zero or more entries. The list-structure type (described above) determines whether all the list entries in list set 98 have a data list entry 104, an adjunct list entry 106, or both. Associated with each entry of a list 99 is one of list-entry controls 102. Controls 102 contain list-entry-location information and other information for controlling operations against data list entry 104.

In particular, list entry controls 102 include the following controls, as depicted in FIG. 11:

(a) A Data-List-Entry Size (DLES) indicating the size of the associated data entry.

(b) A List Number (LN) representing the list that a particular entry is associated with.

(c) A List-Entry Identifier (LEID) identifying a particular list entry. The list-entry identifier is unique to a list set 98 and is assigned by coupling facility 16.

(d) A Version Number (VN) object that is conditionally compared and conditionally updated, reflecting a program specified state for the list entry.

(e) An optional List-Entry Key (LEK) indicating a key, if one exists. When list-entry keys exist, the keyed list entries are ordered by the key with the lowest numerical key at the leftmost position. Elements with the same key value may be located by first or last within the same key value.

When an unkeyed list entry is created or moved, the target list-entry position is always located by an unkeyed position. When a keyed list entry is created or moved, the target list-entry position is always located by a keyed position and first or last within the same key value.

(f) An optional List-Entry Name (LEN). A list-entry name is unique to a list set 98 (FIG. 7) at any particular instant and is provided by the operating system program.

List commands provide a means for conditionally creating, reading, replacing, moving, or deleting one entry in list 99. A number of comparisons may be requested during these processes. They include a list-number comparison, a version-number comparison, a global-lock-manager (GLM) comparison, or any combination of the preceding. Additionally, when global locks are compared, local locks (LLM) may be compared. A list entry may be moved from one list 99 to another within the same structure 52 or from one position to another within the same list 99. This is disclosed in U.S. patent application Ser. No. 07/860,655 for "Method and Apparatus for Performing Conditional Operations on Externally Shared Data" by J. A. Frey, et al. (Attorney Docket No. PO9-92-008), incorporated herein by reference in its entirety as noted.

The position of a list entry in list 99 is determined when it is created, and may be changed when any entry in the list is created, deleted or moved. A list entry or list-entry position is located within a list set 98 by means of the list-entry identifier or the optional list-entry name (as described above), or by position. Position is specified by means of a list number, a direction, and an optional list-entry key.

The list commands also provide a means for synchronously writing and moving, moving and reading, or reading and deleting one entry of list 99. More than one list entry may be deleted synchronously, and more than one data list entry 104 or adjunct list entry 106 may also be read synchronously. Data list entry 104 is always returned in the data area designated in main storage by a message command/response block, described below. The adjunct list entry is returned in either a message command/response block or the data area, depending on the command. This is disclosed in U.S. patent application Ser. No. 07/860,633 for "Apparatus and Method for List Management in a Coupled DP System" by J. A. Frey, et al., (Attorney Docket No. PO9-92-009), incorporated herein by reference in its entirety, as noted.

In one embodiment, messages are communicated between CPC 12 and coupling facility 16 via a message command/response block 110 (FIG. 12). In one example, message command/response block 110 includes a message command block 112, a message response block 114 and an optional data block 116. Message command block 112 includes a command block 118 and a plurality of request operands 120 and message response block 114 includes a response descriptor 122 and a plurality of response operands 124. In one embodiment of the present invention, request operands 120 and response operands 124 include the operands listed below, which are depicted in FIG. 13. (An operand may be a request operand, a response operand or both, depending upon the command. It is also possible that other request and/or response operands exist, which are not shown in FIG. 13.) In one embodiment, the response/request operands include the following:

(a) Attachment Information (AINF): A value set by the program when the local cache is attached.

(b) Comparative Local-Cache Authority (CLCAU): A value used as a comparison value to the local-cache authority when a local-cache attachment is performed for an assigned local-cache identifier or when a local cache is detached.

(c) Comparative Structure Authority (CSAU): A value used as a comparison value to the structure authority when the structure is allocated and deallocated.

(d) Comparative User Authority (CUAU): A value that is compared to the user-authority object.

(e) Detachment-Request Type (DRT): A value that indicates whether the user identifier is to be unassigned when the list-structure user is detached. The value has one of two meanings: Keep the user identifier assigned and unassign the user identifier.

(f) List-Monitoring-Active Bit (LMAB): A value that specifies whether the user associated with the list-monitor-table entry is monitoring the list-state transitions of the list. The value has one of the two following meanings: Not monitoring the list and monitoring the list. When the list-monitoring-active bit indicates that the list is not monitored, all previously issued list-notification commands on behalf of the associated user for this list are complete.

(g) List-Notification-Entry Number (LNEN): An unsigned binary integer that specifies a list-notification-vector entry.

(h) List-Notification Token (LNT): A value that specifies a list-notification vector to the system. A list-notification token of zero indicates that the user may not be registered to monitor a list.

(i) LCID-Unassignment Control (LUC): A value that controls the unassignment of the local-cache identifier. When the value is one, the local-cache identifier is unassigned, and the local-cache controls are reset. The LCID value is available for assignment. When the value is zero, the LCID vector and the local-cache controls are not updated.

(j) Local-Cache Authority (LCAU): A value set by the program when the local cache is attached.

(k) Local-Cache-Entry Number (LCEN): A value that specifies a local cache entry.

(l) Local-Cache Identifier (LCID): An integer that identifies a local cache. The LCID must be assigned for a read-local-cache-information, attach local cache and detach local cache commands and must be attached for all other commands.

(m) Local-Cache Token (LCT): A value that identifies a local cache.

(n) Structure Authority (SAU): A value that is conditionally updated.

(o) User-Attachment Control (UAC): A field per attached user defined by the user.

(p) User Authority (UAU): A value that is compared and conditionally updated.

(q) User Identifier (UID): A value that identifies a user. A user identifier must identify an attached UID when a user is registered, and must identify an assigned UID when a user is deregistered or user controls are read.

(r) User State (US): A field that specifies the state of the user. The value has the following two meanings: The user is detached or the user is attached.

(s) User Structure Control (USC): A field per structure defined by the user.

(t) Allocation Type (AT): A field that indicates the type of allocation.

In addition to cache and list structures, there exists a lock structure which is comprised of a coupling facility list structure with an associated lock table and a set of operating system services to assist in lock contention resolution.

In support of the cache and list structures, described above, is a set of global controls 67, which is located in coupling facility 16 (see FIG. 3). In one embodiment, global controls 67 identify the coupling facility, describe its state, define its model-dependent limitations and summarize the status of its resources. In one example, global controls 67 include a free-space object, a free-control space object, a coupling facility authority object and a structure identifier (SID) vector. The SID vector is a string of bits, which increases sequentially having an initial value of zero. The structure identifier value provides an identification of a target structure by a command. A position i in the string is set to one when a structure is created with a SID value of i. The bit at position i is reset to zero when the structure is deallocated. A read SID vector command, returns the SID vector to the data area in the requesting program.

In one embodiment, a structure identifier is either in the assigned or unassigned state. A structure identifier is in the assigned state when the associated created bit in the structure-identifier vector is one. A structure identifier is placed in the assigned state when a structure is created by an allocate-cache-structure or allocate-list-structure command.

In addition, a structure identifier is in the unassigned state when the associated created bit in the structure-identifier vector is zero. A structure identifier is placed in the unassigned state by a deallocate-cache-structure or deallocate-list-structure command.

A coupling facility structure has one of the following states:

Allocated: The structure is created and commands are processed against structure objects.

Allocation Incomplete: An allocation process has been initiated for a structure, but the initialization of the structure objects has not completed.

Deallocation Incomplete: A deallocation process has been initiated for a structure, but the storage has not all been released.

Unassigned: The structure identifier (SID) value is available for selection by an allocate-cache-structure or allocate-list-structure command, as described in detail below.

A set of commands is provided for each coupling facility storage structure type, as well as additional commands for referencing global objects. The creation, deletion and attributes of a particular structure are controlled by the operating system program through allocation and de-allocation commands, described in detail below. Allocation commands for list structures are described in "Apparatus and Method For List Management In A Coupled DP System" (Docket No. PO9-92-009), by J. A. Frey et al., Ser. No. 07/860,633, Filed: Mar. 30, 1992, which is hereby incorporated by reference in its entirety. In addition, allocation commands for cache structures are described in "Sysplex Shared Data Coherency Method and Means" (Docket No. PO9-91-052), by D. A. Elko et al., Ser. No. 07/860,805, Filed: Mar. 30, 1992, which is also hereby incorporated by reference in its entirety.

In accordance with the principles of the present invention, an installation's rules governing the location and size of the allocated coupling facility structures are stored in a sysplex-wide coupling facility resource management policy (also known as an active policy). These rules determine the location of the coupling facility structures among the several coupling facilities which may be present in the sysplex configuration and their size in terms of the amount of coupling facility storage which is to be used. In one embodiment, the coupling facility policy is stored on a function data set, which is coupled to each central processing complex, as shown in the overview diagram of FIG. 14.

Referring to FIG. 14, the overview diagram is described in detail. In the system shown, two CPC's (CPC 12a and CPC 12b) exist. Each CPC is coupled to coupling facility 16; a couple data set 130, which includes the status for CPC 12a and CPC 12b; and a function data set 132, which includes an active policy 134 for coupling facility resources and one or more administrative policies 136, each of which is described in detail below.

CPC 12a includes a system monitor 126a located within operating system 13a and hardware 128a. Hardware 128a includes, for instance, I/S channels 18a (not shown) to connect coupling facility 16 via a bus 34a to CPC 12a, and I/O channels 22a (not shown), to couple CPC 12a via a link 26a to couple data set 130 and function data set 132.

Similarly, CPC 12b includes a system monitor 126b located within operating system 13b and hardware 128b. Hardware 128b includes, for instance, I/S channels 18b (not shown) to connect coupling facility 16 to CPC 12b via a bus 34b, and I/O channels 22b (not shown) to couple CPC 12b via a link 26b to couple data set 130 and function data set 132.

As described above, operating systems 13a, 13b include system monitor 126a, 126b, respectively, each of which monitors the status of CPC 12a and CPC 12b. Further, each operating system includes a coupling facility resource manager (CFRM) 127a, 127b, respectively, which govern the coupling facility resource use in a sysplex. CFRM provides services to the installation to manage the coupling facility resources usage based on the customer environment. These services include: externals to cover definition and environment setup which are provided by extensions to Cross-System Coupling Facility (XCF) (described in MVS/ESA Planning: SYSPLEX Management, IBM Publication (GC28-1620-1), Chapter 2 and Appendix A, which is incorporated herein by reference in its entirety), including a format utility and an administrative interface utility; externals to make CFRM operational to make a policy active and to determine coupling facility resource status in the sysplex; and situations managed include gain/loss of coupling facility access via coupling facility resource management policy enforcement, gain/loss of function data set which contains CFRM data, and cleanup of coupling facility resources for system failure.

Prior MVS/ESA versions provided support to recognize system failure as part of system monitor 126a, 126b and to allow the surviving systems to initiate recovery processing for the failed system. Part of the recovery processing is to cleanup on behalf of the failed system. In accordance with the principles of the present invention, cleanup for coupling facility resource management will be described below with reference to FIG. 39.

In addition to the above, components of the operating system use function data set 132 to provide a general repository mechanism for sysplex-wide policy information, (e.g., CFRM). Support is provided to allow the system programmer to tailor a function data set which supports CFRM. The tailoring is accomplished by specification of coupling facility resource management defined externals on format utility control card input. The format utility supporting function data set 132 is an extension of the XCF format utility.

In one embodiment, a primary and an alternate function data set is supported by XCF. In the event of an error on the primary function data set, XCF will automatically switch over to use the alternate function data set, if one exists. During their use, XCF synchronizes access to the primary and alternate function data sets to ensure their consistency. The capacity of an alternate function data set may be larger than its primary function data set, but may not be smaller. The operator can request that the alternate function data set be switched to become the primary. This might be done to increase the capacity of the function (if the alternate was larger than the primary that had been in use), or for maintenance of the volume on which the primary function data set resides.

Function data sets need not have full connectivity to all systems in the sysplex. Each XCF function determines whether or not it will provide function to any system when there is not full connectivity to all systems. If a function will operate without full connectivity, the function's services will not be available on systems which lack connectivity to the function data set.

As mentioned above, function data set 132 includes policy information. Policy information is used by functions to automate the operation of the function by providing administrative specification rather than requiring operator actions or responses. It allows the installation to control and manage the use of resources by the function without operator intervention. The policy may take the form of goals, rules, specific actions to be taken or not to be taken, weights, timing values, etc.

The scope of a policy matches the scope of the function for which the policy is in effect. This may or may not be the entire sysplex. Some functions may choose not to operate unless all systems in the sysplex participate in the function, and so the policies for those functions may not be usable unless full function data set connectivity exists.

As shown in FIG. 14, there are two classes of policy: administrative policy 136 and active policy 134. An administrative policy (also referred to as an administrative coupling facility resource management policy) is one which has been defined by the system administrator using an interface provided by Cross-System Extended Services (XES) and stored on a function data set, which is associated with the particular function. The administrative policy is not actively being used by the sysplex in real time. Many administrative policies for a given function may be defined. Each policy may be relevant at different times, reflecting varying workloads, configurations, or other installation considerations. The operator makes a policy active, or changes the active policy which is in effect for a function, via a SETXCF operator command, in response to these factors. Some functions support the deactivation of a policy entirely (via the SETXCF command), others do not.

One example of a SETXCF start command is as follows:

SETXCF START,POLICY,TYPE=CFRM,POLNAME=DAILY

The above command starts an active policy, named DAILY, for CFRM.

An administrative policy is supported by MVS services which enables the systems administrator to define for each structure, the quantity of the total coupling facility resource and a preference list of coupling facilities in which the coupling facility structure should be assigned. The preference list is used to designate the location of coupling facility structures so as to manage performance and capacity considerations. The systems administrator may also define an exclusion list of coupling facility structures which can be used to request that coupling facility structures occupy different coupling facilities if possible. The exclusion list is used to isolate coupling facility structures to different failure domains so as to avoid possible single points of failure for subsystem/system components who require high availability.

In one embodiment, an XCF format utility, such as the one described below, is used to create one or more administrative policies; delete administrative policies that are no longer required; and report on the administrative policy definitions.

The XCF format utility processing handles parsing of the input control card. Specifying the name (CFRM) allows the XCF format utility to load the data definition for coupling facility resource management. It is the data definition which supplies the item names supported by coupling facility resource management. The externalized item names allow a function data set to be built that will be large enough to support both policy and status data required by coupling facility resource management.

For coupling facility resource management, the external items allowed as control card input to the XCF format utility are as follows, each of which is described in detail below:

(a) POLICY--number of named administrative coupling facility resource management policies;

An example, could be a customer whose environment varies based on the time of day such that it would be appropriate to have an administrative policy for each shift of weekday operation and for weekend operation. In this example, the system programmer could request four as the number of administrative policies that can be defined within a function data set.

(b) CF--number of coupling facilities;

This should be the current number of coupling facilities the installation has installed or is planning to install and use in the sysplex referencing the function data set being formatted. The system programmer controls the number of coupling facilities that can be governed by one policy by specifying a list of coupling facilities and having each coupling facility used in the preference list of at least one structure. CFRM only allows the sysplex to use the resources of the coupling facilities listed in the active policy.

(c) STR--number of coupling facility structures per named administrative coupling facility resource management policy; and

The system programmer will determine this number based on the subsystem/system components which require coupling facility structures.

(d) CONNECT--number of connections per coupling facility structure.

The number of connections is a per structure number and the same number applies to all structures in any policy. This number is used to determine function data set size necessary to maintain real time status data associated with the active policy.

The real time maximum number of connections for a named structure type (e.g, lock, list, cache) is calculated at the first connect as the minimum of the formatted number from policy, subsystem/system component requested number of connectors, and any coupling facility implementation limit number. The number of connections in use is established by the subsystem/system component use of IXLCONN, described below, and the number must be within the maximum established by the first connect.

The installation is given the flexibility to determine a maximum value based on the customer environment since limiting the number of connections to a coupling facility structure will lessen the amount of space used by the function data set. This value will be used to reserve total function data set space for all coupling facility structures in the active policy and will be rounded to the next highest unit of 8. For example, if a named coupling facility structure supports a subsystem/system component which does one connection per system in a 4 system sysplex, then the number of connections could be defined to be 8.

Sample JCL to run the format utility to format a primary and an alternate function data set is depicted below:

    __________________________________________________________________________
    //IXCCFRM JOB
    //STEP 10
            EXEC
                PGM=IXCL1DSU
    //STEPLIB
            DD  DSN=SYS1.MIGLIB,DISP=SHR
    //SYSPRINT
            DD  SYSOUT=A
    //SYSIN DD  *
    DEFINEDS   SYSPLEX(PLEX1)
               DSN(SYS1.XCF.FDS01) VOLSER(3380X1)
               NOCATALOG
            DATA
                TYPE(CFRM)
                ITEM NAME(POLICY) NUMBER(6)
                ITEM NAME(CF) NUMBER(5)
                ITEM NAME(STR) NUMBER(20)
                ITEM NAME(CONNECT) NUMBER(32)
    DEFINEDS   SYSPLEX(PLEX1)
               DSN(SYS1.XCF.FDS02)
                VOLSER(3380X2)
               NOCATALOG
           DATA
               TYPE(CFRM)
               ITEM NAME(POLICY) NUMBER(6)
               ITEM NAME(CF) NUMBER(5)
               ITEM NAME(STR) NUMBER(20)
               ITEM NAME(CONNECT) NUMBER(32)
    __________________________________________________________________________

    ______________________________________
    //IXCCFRMP
              JOB
    //STEP20   EXEC    PGM=IXCMIAPU
    //SYSPRINT
               DD      SYSOUT=A
    //SYSIN    DD      *
    DATA TYPE(CFRM) DSN(SYS1.XCF.FDS01)
    VOLSER(3380X1) REPORT(YES)
    DEFINE POLICY NAME(POLICY1) REPLACE(YES)
    CF        NAME(FACIL01)
              TYPE(123456)
              MFG(IBM)
              PLANT(PK)
              SERIAL(123456789012)
              PARTITION(1)
              CPCID(00)
              SIDE(0)
    CF        NAME(FACIL02)
              TYPE(123456)
              MFG(IBM)
              PLANT(PK)
              SERIAL(123456789012)
              PARTITION(2)
              CPCID (00)
              SIDE (1)
    STRUCTURE NAME(LIST.sub.-- 01)
             SIZE(1000)
             PREFLIST(FACIL01, FACIL02)
             EXCLLIST(CACHE.sub.-- 01)
    STRUCTURE NAME(CACHE.sub.-- 01)
             SIZE(1000)
             PREFLIST(FACIL01, FACIL02)
             EXCLLIST(LIST.sub.-- 01)
    DELETE POLICY NAME(POLICY2)
    ______________________________________