Method and apparatus for invoking network agent functions using a hash table

Abstract

An agent receives requests containing multiple parameters over an information processing network. The process of obtaining information responsive to the request varies depending on the values of the parameters. The agent constructs a hash key using the parameter values, and uses the hash key to index an entry in a hash function table, the entry having a set of parameter values and a pointer corresponding to the function used to service a request for the indicated parameter values. The agent uses the pointer to call the function to service the request Preferably, the parameters may include wild cards, which are expanded into multiple requests, from which multiple hash keys are derived and multiple functions are called. The agent is preferably part of a larger distributed storage management program, comprising a central manager and a separate agent in each of multiple host computer systems. Each agent independently collects data from the network(s) attached to its host, analyzes the network(s), builds data structures representing the network(s), and uses the data structures to service information requests from the central manager. The manager collates the data from different agents to produce a coherent view of the network.

Claims

We claim:

1. A method for providing information from a local agent, said method comprising the steps of:

(a) receiving an information request from a remote requester attached to an information processing network, said information request containing a plurality of parameters;

(b) constructing a hash key from said plurality of parameters;

(c) using said hash key to access an entry in a hash function table, said hash function table containing a plurality of entries, each said entry containing a respective function pointer to a corresponding one of a plurality of functions which is invoked to obtain information responsive to said information request;

(d) executing a function identified by said function pointer to obtain information responsive to said information request; and

(e) transmitting said information responsive to said information request to said requester via said information processing network.

2. The method for providing information from a local agent of claim 1, wherein said information request contains at least one wild card parameter, said method further comprising the steps of:

accessing an entry in a wild card parameter table, said entry specifying a plurality of parameter values associated with said wild card parameter,

constructing a plurality of expanded information requests, each request of said plurality of expanded information requests corresponding to a respective one of said plurality of parameter values associated with said wild card parameter; and

performing steps (b) through (d) for each of said plurality of expanded information requests, each respective hash key constructed from a plurality of parameters being constructed using the respective one of said plurality of parameter values associated with said wild card parameter.

3. The method for providing information from a local agent of claim 1, further comprising the steps of:

constructing a structured data representation of an entity to be monitored, said structured data representation comprising a plurality of records, said records being linked in a relationship corresponding to a configuration of said entity to be monitored; and

accessing said structured data representation to obtain information responsive to said request.

4. The method for providing information from a local agent of claim 3, wherein said entity to be monitored is a storage network comprising a plurality of data storage devices, there being at least one said record corresponding to each respective data storage device.

5. The method for providing information from a local agent of claim 1, wherein said information request contains one of a set of commands, said set comprising a plurality of types of commands, and wherein said step of using said hash key to access an entry in a hash function table comprises:

(i) selecting a first hash function table from a plurality of hash function tables, said selection being dependent on the type of command contained in said information request; and

(ii) using said hash key to access an entry in said first hash function table.

6. The method for providing information from a local agent of claim 5, wherein said set of commands contains a first command having a first number of parameters and a second command having a second number of parameters, said first number being different from said second number.

7. The method for providing information from a local agent of claim 5, wherein a first hash key function is used to construct a hash key for accessing an entry in said first hash function table, and a second hash key function is used to construct a hash key for accessing an entry in a second hash function table, said first and second hash key functions being different.

8. A computer program product for providing information from a local agent, said computer program product including a plurality of computer executable instructions stored on a computer readable medium, wherein said instructions, when executed by said computer, cause the computer to perform the steps of:

(a) receiving an information request from a remote requester attached to an information processing network, said information request containing a plurality of parameters;

(b) constructing a hash key from said plurality of parameters;

(c) using said hash key to access an entry in a hash function table, said hash function table containing a plurality of entries, each said entry containing a respective function pointer to a corresponding one of a plurality of functions which is invoked to obtain information responsive to said information request;

(d) executing a function identified by said function pointer to obtain information responsive to said information request; and

(e) transmitting said information responsive to said information request to said requester via said information processing network.

9. The computer program product of claim 8, wherein said information request contains at least one wild card parameter, and wherein said instructions, when executed by said computer, further cause the computer to perform the steps of:

accessing an entry in a wild card parameter table, said entry specifying a plurality of parameter values associated with said wild card parameter;

constructing a plurality of expanded information requests, each request of said plurality of expanded information requests corresponding to a respective one of said plurality of parameter values associated with said wild card parameter; and

performing steps (b) through (d) for each of said plurality of expanded information requests, each respective hash key constructed from a plurality of parameters being constructed using the respective one of said plurality of parameter values associated with said wild card parameter.

10. The computer program product of claim 8, wherein said instructions, when executed by said computer, further cause the computer to perform the step of:

constructing a structured data representation of an entity to be monitored, said structured data representation comprising a plurality of records, said records being linked in a relationship corresponding to a configuration of said entity to be monitored; and

accessing said structured data representation to obtain information responsive to said request.

11. The computer program product of claim 10, wherein said entity to be monitored is a storage network comprising a plurality of data storage devices, there being at least one said record corresponding to each respective data storage device.

12. The computer program product of claim 8, wherein said information request contains one of a set of commands, said set comprising a plurality of types of commands, and wherein said step of using said hash key to access an entry in a hash function table comprises:

(i) selecting a first hash function table from a plurality of hash function tables, said selection being dependent on the type of command contained in said information request; and

(ii) using said hash key to access an entry in said first hash function table.

13. The computer program product of claim 12, wherein said set of commands contains a first command having a first number of parameters and a second command having a second number of parameters, said first number being different from said second number.

14. The computer program product of claim 12, wherein a first hash key function is used to construct a hash key for accessing an entry in said first hash function table, and a second hash key function is used to construct a hash key for accessing an entry in a second hash function table, said first and second hash key functions being different.

15. A method for servicing a remote request in a computer system, comprising the steps of:

(a) receiving a request from a remote requester attached to an information processing network, said request containing a plurality of parameters;

(b) constructing a hash key from said plurality of parameters;

(c) using said hash key to access an entry in a hash function table, said hash function table containing a plurality of entries each said entry containing a respective function pointer to a corresponding one of a plurality of functions which is invoked to obtain information responsive to said information request; and

(d) executing a function identified by said function pointer to service said request.

Description

FIELD OF THE INVENTION

The present invention relates generally to digital data processing, and more particularly to the management of networks of digital data storage devices.

BACKGROUND OF THE INVENTION

Modern computer systems have driven a demand for enormous amounts of data storage. Data traditionally has been stored in one or more mass data storage devices, such as rotating magnetic disk drives or tape drives, attached to a single computer system. As computer systems have become larger, faster, and more reliable, there has been a corresponding increase in need for storage capacity, speed and reliability of the storage devices. Increases in the data storage capacity and reliability of storage devices have been dramatic in recent years. But with all the improvements to the devices themselves, there are certain limitations to what can be accomplished. Additional configurations of storage devices have increasingly been offered in recent years to meet demand for larger capacity, faster, more reliable, and more accessible data storage.

One example of alternative configurations is the rapidly increasing popularity of so-called "RAIDs", i.e., redundant arrays of independent disks. A RAID stores data on multiple storage devices in a redundant fashion, such that data can be recovered in the event of failure of any one of the storage devices in the redundant array. RAIDs are usually constructed with rotating magnetic hard disk drive storage devices, but may be constructed with other types of storage devices, such as optical disk drives, magnetic tape drives, floppy disk drives, etc. Various types of RAIDs providing different forms of redundancy are described in a paper entitled "A Case for Redundant Arrays of Inexpensive Disks (RAID)", by Patterson, Gibson and Katz, presented at the ACM SIGMOD Conference, June, 1988. Patterson, et al., classify five types of RAIDs designated levels 1 through 5. The Patterson nomenclature has become standard in the industry.

Another example of a storage alternative is the concept of a storage subsysteim A storage subsystem implies a greater degree of independence from a host computer system than is typically found in an isolated storage device. For example, the subsystem may be packaged in a separate cabinet, with its own power supply, control software, diagnostics, etc. The subsystem may have a single storage device, but more typically contains multiple storage devices. The notion of a storage subsystem and a RAID are not necessarily mutually exchlsive; in fact many RAIDs are constructed as semi-independent storage subsystems, which communicate with a host through a communication link having a defined protocol. It is possible in such subsystems that the host is not even aware of the existence of multiple data storage units or data redundancy in the storage subsystem. To the host, the subsystem may appear to be a single very large storage device.

A configuration of multiple storage devices need not be attached to only a single host computer system. It might be that multiple computer systems are configured to share multiple storage devices. Thus, configurations of storage devices can be generalized to the concept of a storage network.

As used herein, a storage network is a configuration of multiple data storage devices, connected to one or more host computer systems, such that there is a communication path from each storage device to each host system which does not cross the system bus of another host system Because there exists a direct communication path from each system to each storage device, data on any device is readily accessible to any of the systems. Storage devices in a storage network are not necessarily identified with or controlled by a host This latter feature distinguishes a storage network from a simple network of computer systems, each having its own local storage devices. Thus, in certain computing environments, a storage network facilitates sharing of data and improved performance over a conventional network of host systems.

While it is theoretically possible to construct and maintain complex storage networks shared among multiple host computer systems using prior art hardware, in reality this is an error-prone and difficult task. Documentation and software support may be primitive or non-existent. A user must determine how to operate, configure and attach devices, and may have to write his own custom software routines to provide proper support for the network. Optimum physical configurations may depend on logical configurations and modes of operation, such as one or more RAID levels. There may be numerous hardware dependencies and limitations, such as number and type of devices that may communicate with a single I/O controller or adapter. Data may have to be collected from multiple sources and analyzed to provide needed information. All these requirements place substantial demands on the time, expertise and other resources of the user.

It would be desirable to support the construction and maintenance of storage networks with software which assists the user.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide enhanced data processing capability.

Another object of this invention is to provide enhanced support for calls to a server from an information processing network.

Another object of this invention is to provide enhanced support for distributed programs.

Another object of this invention is to enhance the capability to monitor devices using a distributed monitoring program.

Another object of this invention is to provide enhanced support for storage networks attached to multiple host computer systems.

An agent receives requests over an information processing network. Each request contains a plurality of parameters. The process of responding to the request varies depending on the values of the parameters. The agent includes a plurality of functions used to respond, each function being used for one or more sets of parameter values. Upon receipt of a request, the agent constructs a hash key using the parameter values, and uses the hash key to index an entry in a hash function table. The hash function table contains a plurality of entries, each entry having a set of parameter values and a pointer corresponding to the function used to service an information request for the indicated parameter values. Upon locating the appropriate entry, the pointer is used to call the function to service the request.

Preferably, requests may include wild card parameters. The agent refers to a wild card table to expand a wild card parameter into multiple parameter values which the wild card may assume. These parameter values are then used to construct a set of expanded requests, each request of the set corresponding to one of the parameter values. The set of expanded requests are then used to generate a corresponding set of hash keys, and the appropriate function is called for each respective expanded request.

In the preferred embodiment, the agent (also called a local agent) is part of a larger distributed storage management program which supports management of storage networks connected to multiple host computer systems through one or more controllers in each respective host. The distributed storage management program comprises a central manager portion and a separate agent in each of the host computer systems. The agents gather data and communicate with the manager across the information processing network, which is a communications path independent of the storage network. The manager collates the data from different agents to produce a coherent view of the network.

In accordance with the preferred embodiment, requests are generally for information concerning storage networks attached to a local host computer system. Each local agent independently collects data from the storage network(s) attached to the respective host in which the agent is located. Thus the view of the network obtained by any particular local agent is the view of its host. The agent operates as a server, responding to data requests from the central manager. The local agent is not a mere passive entity responding only to data requests, but actively builds an internal topological view of the network as seen by its host and collects data such as error events. This view is stored in a complex series of data structures which permit rapid access to individual device data, as well as to topological data, for use in responding to a variety of information requests from the central manager. The local agent also includes unknown device resolution capability to resolve the identities of certain devices connected to the network by analyzing information received from multiple controllers.

In the preferred embodiment, the storage network is a network of storage devices and host adapter devices connected by a communications medium employing the IBM Serial Storage Architecture (SSA) communications protocol. This protocol is designed to efficiently support transmission of data between multiple hosts and storage devices in a storage network, but does not easily support communication of data at a higher programning level. Specifically, it does not readily support typical client-server communication, such as remote procedure calls. The hosts are connected to each other (and optionally to a separate computer system which executes the manager) via a second network, designated the information processing (IP) network. The IP network typically operates in accordance with a TCP/IP. The IP network is designed to readily support client-server communication. Therefore, the IP network supports communication among manager and agents.

The agent described herein provides a rapid and easily maintainable mechanism for servicing heterogeneous information requests.

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a high level diagram of an interconnected network of computer systems utilizing a storage network, in accordance with the preferred embodiment of the present invention.

FIG. 2 is a high level diagram of an alternative example of a storage network configuration, wherein multiple storage networks serve multiple host computer systems, according to an alternative embodiment.

FIG. 3 illustrates in greater detail a host computer system which functions as the manager of a storage network, in accordance with the preferred embodiment of the present invention.

FIG. 4 illustrates in greater detail a host computer system attached directly to a storage network, in accordance with the preferred embodiment of the present invention.

FIGS. 5A through 5C illustrate ahigh level view of the class library objects for logically representing storage networks, in accordance with the storage management program of the preferred embodiment.

FIG. 6 illustrates a high level view of the canvas related objects which visually represent storage networks, in accordance with the storage management program of the preferred embodiment.

FIG. 7 illustrates the relationship between visual device representation objects and the network resource objects themselves, according to the preferred embodiment.

FIG. 8A shows a simple storage network loop configuration example.

FIG. 8B is an object diagram showing the object representation of the storage network loop of FIG. 8A, according to the preferred embodiment.

FIGS. 9A through 9E show the major data structures used to communicate information from a local agent to a central manager, according to the preferred embodiment.

FIG. 10 is a high-level view of a local agent and various components within its host system with which it interacts, according to the preferred embodiment.

FIG. 11 illustrates how a request received by the local agent is decoded to access the proper functional code sequence for servicing the request, in accordance with the preferred embodiment.

FIGS. 12A through 12C illustrate the major data structures held in shared memory 1003 of a local agent, in accordance with the preferred embodiment.

FIG. 13 is a flow diagram illustrating the process within the network daemon of resolving multiple unknown controllers.connected to the same host, according to the preferred embodiment.

FIG. 14 illustrates the appearance of the display screen during the monitoring mode of operation of the storage network manager for an example storage network configuration, according to the preferred embodiment.

FIG. 15 depicts the relationships among key object classes used in the discover operation.

FIGS. 16 and 17 are flow diagrams illustrating the various steps performed by the central manager in parsing a management set to discover the identities and configuration of devices within the set, according to the preferred embodiment.

FIG. 18 is a flow diagram illustrating the process of resolving unknown network devices within the central manager, according to the preferred embodiment.

FIG. 19 is a flow diagram illustrating the process of resolving an existing management set with the results of a discover operation, according to the preferred embodiment.

FIGS. 20A through 20K illustate the collection of found object lists at various stages of a discovery operation for an example configuration, according to the preferred embodiment.

FIGS. 21A through 21C illustrate the strings and substrings created during the process of resolving unknown network devices for an example configuration, according to the preferred embodiment

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

I. Architectural Overview

A distributed storage network management program manages a network of storage devices, which may be attached to multiple host computer systems. As a preliminary matter, it is necessary to understand the essential elements of a configured storage network in accordance with the preferred embodiment.

The storage management program of the preferred embodiment is occasionally referred to herein as "StoX". One or more versions of a program product having that name are being or are expected to be marketed by International Business Machines Corporation. While it is expected that all such versions will have similar overall structure and purpose, no statement is made that each and every detail described herein is consistent with each and every publicly released version of StorX, or with any publicly released version of StorX.

The Storage Network Concept

As explained above, a storage network as used herein is an interconnected group of storage devices and controllers. It is possible for a host to communicate with any storage device in a storage network to which the host is connected, without crossing another host's backplane bus (although the communication may go through hardware devices, such as storage adapters, associated with other host systems). Because the backplane bus of other hosts need not be crossed, it is possible to efficiently and rapidly transmit data through one or more controllers in other host systems to a remote destination. Controller-to-controller communication takes place via the storage interface itself.

FIG. 1 shows an illustrative example of one possible configuration of storage network, in accordance with the preferred embodiment. Host systems 111-113 store data in storage network 101. Storage network 101 comprises storage devices 120-129, which are coupled to network storage controllers 130-133 via communications links 140-147, as shown. Each host system 111-113 connected directly to storage network 101 contains at least one respective storage controller, host system 111 contains two network storage controllers 130,131.

Storage network 101 is merely an illustrative example of one possible configuration of storage network. FIGS. 2A, and 2B illustrate at a high level various alternative configuration examples of storage networks.

FIG. 2A illustrates the case where a single storage network 201 is connected to a single host computer system 211. Storage network 201 comprises storage controllers 221,222, which communicate via links 231,232 with storage devices 241-248. FIG. 2B illustrates a firther alternative storage network configuration, in which multiple storage networks 202,203 are connected to multiple host computer systems 212-214. Storage network 202 comprises storage controllers 223-225, which communicate via links 233-234 with storage devices 249-254. Storage network 203 comprises storage controllers 226-228, which communicate via link 235-237 with storage devices 255-263. It will be observed that storage network 203 is connected in a loop, which provides redundancy in case any single communications link fails, while storage network 202 is configured in a non-redundant fashion.

It will be understood that the storage network configurations shown in FIGS. 1, 2A and 2B are merely illustrative of a few different types of configurations, and are not intended as an exhaustive compilation of the different configurations possible. The number of host systems, I/O controllers, buses, and storage devices may vary considerably. Devices may be connected in redundant or non-redundant fashion. Controllers and buses may support connections to other devices. Typical storage network configurations are in fact much larger, but a relatively small number of devices is used for ease of illustration and understanding.

While all three of the storage networks shown in FIGS. 1, 2A and 2B can be monitored and managed using the storage management program described herein, certain features of the program described as the preferred embodiment are particularly designed to accommodate large, multi-host storage networks. For example, a distributed storage management program is usefull for managing a multi-host network, for reasons explained herein. But the single-host network of FIG. 2A could be managed by a storage management program residing entirely within the single host system.

The Manager/Agent Architecture

In accordance with the preferred embodiment, the functions of a storage network management program are divided between a central manager and a plurality of local agents. FIG. 1 illustrates at a high level a typical interconnected network of computer systems (information processing network) utilizing a storage network, in accordance with the preferred embodiment of the present invention. Information processing network 100 comprises host computer systems 110-113, which communicate with each other via information processing network communication medium 115. The network communication medium 115 is preferably a wired local area network (LAN) such as an Ethernet LAN or IBM Token Ring LAN, it being understood that communications media of other types and protocols could be used. Data is stored in multiple storage devices 120-129 in storage network 101. Host system 110 is not directly connected to storage network 101 in this example. Host system 110 performs the function of managing storage network 101.

Typically, storage devices 120-129,241-263, are rotating magnetic hard disk drive storage devices, sometimes also called "direct access storage devices", or DASD. However, storage devices 120-129, 241-263 could be other types of mass data storage devices, such as magnetic tape, optical disk, floppy disk, etc. Additionally, within any single network the storage devices may be a heterogeneous collection of storage devices of differing types, capacities, and other characteristics. Similarly, controllers 130-133, 221-228, communication links 140-147, 231-237 and hosts 110-113, 211-214 may be of the same type, or may be of mixed characteristics.

In the preferred embodiment, one of the host computer systems functions as a storage network manager, while the other systems function as agents of the network manager. Host system 110 is designated as the system which functions as a storage network manager. FIG. 3 is a block diagram showing the major components of host system 110 in accordance with the preferred embodiment. Central processing unit (CPU) 301 and system memory 302 are coupled to system bus 303. Bus 303 is used for communicating data among various components of system 110. Network adapter 305 coupled to system bus 303 is connected to network communications medium 115, allowing system 110 to communicate with other systems in the information processing network. Display adapter 306 coupled to bus 303 drives visual display 307 for displaying information to a user. Display 307 is preferably a cathode ray tube display, although other types may be used. Input adapter 308 receives input from an user through one or more input devices, such as keyboard 309 or mouse 310, it being understood that other input devices could be used. Local storage adapter 311 communicates with disk drive storage device 312 for storing data local to system 110. In the preferred embodiment, system 110 is an IBM Personal Computer, it being understood that other types of computer system could be used. It should further be understood that the major components shown above are by way of example, and many different configurations are possible.

Operating system 321 is stored in system memory 302 of system 110. In the preferred embodiment, operating system 321 is a Microsoft Windows 95 operating system, it being understood that other operating systems could be used. Also contained in memory 302 is a master portion of storage management program 331. Storage management program 331 is used to manage storage network 101. Program 331 runs in the environment of operating system 321, and preferably performs display related graphical user interface functions through operating system calls. While operating system 321 and program 331 are shown conceptually in FIG. 3 stored in system memory 302, it will be understood by those skilled in the art that typically the full program code will be stored in mass storage such as disk drive device 312, that only a portion of such programs may be resident in memory at any one time, and that program segments are loaded into memory 302 from storage as needed.

While in the preferred enibodiment, the master portion of storage management program 331 resides on a host system separate from the storage network 101, it would alternatively be possible for storage management program 331 to reside in one of the host systems directly connected to storage network 101.

In the preferred embodiment, host systems 111-113 which are directly connected to storage network 101 execute agent portions of the storage management program. FIG. 4 is a block diagram showing the major components of a typical host system 111, which is directly connected to network 101, in accordance with the preferred embodiment. Central processing unit (CPU) 401 and system memory 402 are coupled to system bus 403. Bus 403 is used for communicating data among various components of system 111. Network adapter 405 coupled to system bus 403 is connected to network communications medium 115, allowing system 111 to communicate with other systems in the information processing network.

Network storage I/O controllers 130 and 131 are coupled to bus 403 for communicating with other components of host system 111. Controllers 130,131 additionally are coupled to similar controllers in hosts 112,113, and to storage devices 120-129, through communication links 140-147, which collectively form network 101.

Additional devices may be coupled to system bus 403. For example, local storage adapter 408 is coupled to bus 403, for enabling communication with another (local) disk drive storage device 409. Terminal adapter 410 enables communication with an interactive user terminal (not shown). The configuration shown in FIG. 4 is by way of example only, and other devices (not shown) may also be connected. In the preferred embodiment, host system 111 is an IBM RS/6000 computer system, it being understood that other computer systems could be used.

It will be observed in FIG. 4 that SSA link 140 connects I/O controllers 130 and 131 directly, without going through system bus 403, and this connection is therefore part of storage network 101. On the other band, local storage adapter 408 and device 409 have no direct connection to storage network 101. While it is theoretically possible to transfer data from device 409 to one of devices 120-129 or to another host system, such a transfer would be through system bus 403. Therefore, adapter 408 and storage device 409 are not included in storage network 101.

Operating system 421 is stored in system memory 402 of system 111. In the preferred embodiment, operating system 421 is an IBM AIX operating system, it being understood that other operating systems could be used with appropriate hardware. Also contained in memory 402 is an agent portion of storage management program 431. In the preferred embodiment, agent portion 431 is a part of the storage management program which performs data gathering and monitoring functions. For example, agent portion can poll hosts and I/O controllers to determine the existing topology of a storage network, can monitor and report error conditions, etc., as described more fully herein. While operating system 421 and program 431 are shown conceptually in FIG. 4 stored in system memory 402, it will be understood by those skilled in the art that typically the full program code will be stored in mass storage, and appropriate portions loaded into memory 403 from storage as needed.

The SSA Protocol

In the preferred embodiment, communication links 140-147 comprise wired connections using the IBM Serial Storage Architecture (SSA) communications protocol. In this protocol, the storage network comprises multiple dedicated, bi-directional connections, each connection between two and only two devices. Thus, at the physical hardware level, a separate connection exists in each segment of a communications path. E.g., a bi-directional wired connection exists between disk drive 120 and 121, while separate such connections exist between drive 121 and 122, and between adapter 130 and drive 120.

Because links typically do not exist between every possible pair of devices, data being transferred from one device to another may have to pass through multiple links and devices. The failure of a single device or link would break such a communication path. For this reason, it is desirable, although not required, to arrange such SSA networks in loops, which are inherently redundant. For example, referring to FIG. 2B, storage network 202 is arranged in a "string" configuration, which is non-redundant, while storage network 203 is arranged in a loop configuration. If, e.g., the link between disk drives 252 and 253 were to fail, adapter 224 would be unable to communicate with drive 253. On the other hand, if the link between drives 258 and 259 were to fail, adapter 227 would still be able to communicate with drive 259 by routing a message through disk drives 257, 256, 255, adapter 226, disk drives 260, 261, 262, 263, and adapter 228.

An adapter sends a message to another device on the network by imbedding a "hop count" in an information packet, which is then transmitted to an adjacent device across the dedicated bi directional link. The receiving device decrements the hop count, and, if the hop count is non-zero, forwards the information packet to the next sequential device. For example, referring to FIG. 1, adapter 130 may communicate with drive 123 by sending an information packet to drive 120, having a hop count of 4. Each of the devices 120, 121 and 122 decrements the hop count and forwards the packet to the next device. When the packet reaches drive 123 and drive 123 decrements the hop count, the hop count is now zero, indicating that the message was intended for drive 123.

In order for this scheme to work, each adapter needs to know the relative location of the various disk drives in the network It does not necessarily need to know the identity of the other adapters, since it will not store data on them (although it must know there is something at the adapter location, in order to specify correct hop counts). Accordingly, each adapter maintains a listing of storage devices and their respective hop counts in its local memory. This listing is initially generated at power-on time by polling the devices in the storage network. The adapter may also poll in response to certain network events, or in response to a command from local agent 431.

A sequential series of SSA links from device to device as described above is referred to as an "SSA bus", since it is capable of transmitting data among multiple attached devices. However, it is not a bus in the true sense, since no arbitration is required. The SSA protocol supports rapid transfer of data for writing or reading to a storage device. It is not intended to support higher level comnmnications, such as client/server calls.

Each device on an SSA bus (i.e., disk or adapter) has a unique universal identifier associated with it. This identifier is guaranteed by the protocol to be unique across all devices which can attach to an SSA bus.

It should be understood that other storage network protocols could be used, including protocols which imply different connection topologies. For example, a bus-based protocol (such as SCSI) in which all devices are connected to a common communication carrier (bus), and arbitrate for control of the bus, could be used. Furthermore, while in the preferred embodiment the SSA protocol is supported, certain aspects of the manager/agent architecture, particularly the manager/agent remote procedure call interface, are defined to support other protocols, or mixed protocols. In this manner, the distributed storage management program of the preferred embodiment may be extended to support other protocols in the future.

II. The Central Manager

In the preferred embodiment, storage management program central manager 331 is implemented in object-oriented programming code. This implementation facilitates the manipulation of objects displayed on a visual display as well as the interconnecting relationships between different representations of physical objects which make up the network. While the description below is directed to this implementation, it will be understood by those skilled in the art that the storage management functions could have been implemented in conventional procedural programming code, or using other programming paradigms.

The manager supports various functions, which can generally be divided into two groups: the planning functions and the monitoring functions. The planning functions enable a user to plan storage network configurations. The monitoring functions (also known as "live mode") automatically discover existing storage network configurations, display these configurations to the user, report events, device characteristics, etc., and perform diagnostics. There can be some overlap of function, in that the planning function can be used to plan extensions to existing storage networks which are first mapped using the automatic discovery function. Both of these groups of function use a common set of data structures, specifically an object-oriented class library. The fact that the library is shared by both groups of functions does not mean that every object in the library is used by every function.

In the preferred embodiment, the manager is developed using the IBM Visual Age programming development environment. This product provides an Open Class Library having various object-oriented facilities, which are used by the manager where necessary. Other development environments may provide analogous facilities, or it would be possible to create necessary facilities.

FIG. 5 illustrates a high level view of the class library objects of the storage management program of the preferred embodiment. FIG. 5 uses a notational system known as "Booch notation". This system is generally known among those skilled in the art of object-oriented programming. An explanation of the Booch notational system can be found in Booch, Object-Oriented Analysis and Design With Applications, 2nd ed. (Benjamin/Cummings Publishing Co., 1994), at Chapter 5, pp. 171-228. In FIG. 5, certain class relationships (which are actually containment by value) are depicted as contained by reference for ease of understanding. The actual code uses containment by value for reasons of performance, it being understood that it would be possible to write the code as either containment by value or by reference.

NetworkImages class 501 holds the objects which make up the current management set. The management set can be thought of as the global set of objects capable of being manipulated and configured by storage management program 331. It is possible to save and store multiple nanagement sets, but only one set is worked upon at any one time. The management set may contain one or more storage networks. When program 331 is initiated, it creates a single Networklmages object. Methods can then be invoked to populate the NetworkImages object. E.g., the method open() populates NetworkImages with a previously saved management set. Alternatively, methods can be called to create objects (Hosts, PhysicalDisks, etc.) one at a time. All Device objects are added and removed using the add() and remove() methods, respectively. The program determines which Network object the Device object belongs in and places it in the appropriate Network.

Network class 502 is a container (collection) class for all of the primary objects (PhysicalDisks, Controllers, LogicalDisks, Hosts, UnknownDevices, Connections and Buses) contained in a single network image. The Network class corresponds to a single storage network. It is possible to have multiple Network objects in a single NetworkImages object (i.e., multiple storage networks in a single management set).

NetworkResource class 503 is an abstract base class which is used to provide an interface for classes that inherit from it. This class serves as the base class for the Host, Bus and Device classes. Although many of the object representing network resources could be lumped into a collection of NetworkResources or Devices, they are kept in separate collections for each device class, i.e., LogicalDisk, PhysicalDisk, etc. This provides some efficiencies when searching for particular objects or types of objects.

Device class 504 is an abstract base class which is used to provide a consistent interface for the devices that inherit from it, Device class 504 along with PhysicalDevice class 505 support extensibility. For example, if a magnetic tape device were to be added to the collection of devices configurable in a storage network, the new class could inherit from PhysicalDevice class 505, and thus maintain an interface consistent with other devices. Device class 504 groups all the functions that don't require a distinction between physical and logical device, e.g. seriaINumbero, nameo, and stateo.

PhysicalDevice class 505 is also an abstract base class which provides a common interface for physical (as opposed to logical) devices, e.g., Controller, PhysicalDisk, and UnknownDevice. Because every physical device has ports or connectors which are used to connect the device to other physical devices, PhysicalDevice class 505 contains at least one Port object by value. These Port objects are used to make connections to other Physical Device objects. It is PhysicalDevice objects (representing physical devices) as opposed to LogicalDevice objects that the storage management program configures by forming connections therebetween.

PhysicalDisk class 507 is used to define a PhysicalDisk object, and is derived from the NetworkResource, Device and PhysicalDevice classes. PhysicalDisk objects represent rotating magnetic hard disk drive storage devices. In the preferred embodiment, disk drives are the only type of storage device supported for the network, although it would be possible as noted above to extend the application to other types of devices.

Controller class 508 is an abstract base class which provides a common interface for different types of objects representing I/O controllers. Controller class 508 is derived from NetworkResource 503, Device 504 and PhysicalDevice 505 classes. The classes ExtController, IntController and InitAdapter (representing external controllers, internal controllers, and initiator adapter cards, respectively) inherit from Controller class 508.

ExtController class 511 is derived from Controller class 508 and is used to represent controllers that are physically contained outside of a host system. For example, an external controller may be a RAID controller which is located in a separate storage subsystem housing having multiple storage devices and supporting hardware.

IntController class 510 is derived from Controller class 508 and is used to represent most I/O controllers of the type that are physically mounted within a host system, and typically connected directly to the host system's backplane bus.

InitAdapter class 509 is derived from Controller class 508 and is used to represent initiator adapters, i.e. I/O controllers which reside within a host system for connecting the host system to an external controller.

Bus class 512 is used to contain a group of Connection objects that are contained on a single loop or string. In the SSA protocol, this amounts to the collection of Connections that form a single SSA bus. If the architecture were used to represent other protocols such as SCSI, the Bus class might be used to represent a single SCSI bus or similar construct.

Connection class 513 is used to provide information on the bus or link that is connecting PhysicalDevice objects. For the SSA protocol, a Connection object represents a single bidirectional link that joins two physical devices together. The Connection class contains one or more Port objects (described below). The Port class has a reference to a PhysicalDevice and contains an identifier which is used to store the port number that is associated with the port. For the SSA protocol, each Connection object contains two Port objects. FIG. 8A illustrates an example of a simple SSA storage network having two controllers and three disk drives. Each link is considered a connection. The connections are labeled C1 through C5. FIG. 8B shows an object diagram for the network of FIG. 8A., relating the Connection objects to the PhysicalDevice objects. All of the references with a PortX label and the Port object contained inside the Connection class. For example, Connection 5 (C5) is connected to Port4 of ControllerA and Port1of Drive3.

Port class 514 is contained by value inside of a concrete PhysicalDevice class. A Port object is used to contain the information on The location of a port by containing a reference to the corresponding PhysicalDevice and an identifier. The identifier stores the port number.

Host class 515 is used to define ahost system, i.e., a system in which at least one internal controller or initiator adapter resides. Only a host system having such an I/O controller can be connected to a storage network

LogicalDisk class 520 is used to represent a "logical" view of disks from the perspective of a host system, which is different from the actual hardware (physical) view. In the AIX host operating system of the preferred embodiment, a collection of multiple physical disks can be treated as a single logical disk, whereby host I/O functions access an address in the logical disk space, which is ultimately mapped to one of the disks. In particular, a group of disks storing data redundantly in accordance with a RAID plan should be a single logical disk. Theoretically, the "logical disk" class could be used to represent logical disks which are actually partitions (portions) of a physical disk, although this is not done in the preferred AIX embodiment.

LogicalConn class 521 is used to represent a "logical" connection, and is a companion to the logical disk concept.

Alias class 522 contains alias names for physical devices, known to particular hosts. I.e., the same physical device may have different identifiers in different host systems.

UnknownDevice class 506 is used to represent physical devices which are of an unidentified type or a type not known to storage management program 331.

In operation, storage management program 331 presents the user with a virtual "canvas", which can be likened to an artist's canvas, i.e., the area for drawing and displaying things. The class library depicted in FIG. 5 is used internally within storage management program 331 for representing physical devices, connections, and logical relationships. Additional classes are used to generate the graphical display of storage networks on a display screen, for visualization by the user. The structure of these additional classes is shown in FIG. 6.

Canvas class 601 is the base class for holding all objects which define what can be displayed on the display screen.

IDrawingCanvas class 602 contains the current contents of the canvas. The "canvas" is a virtual area for representing storage networks. Typically, the canvas is larger than the size of the physical display screen. As a result, the display screen is capable of displaying only a portion of the complete canvas at any one time.

IViewPort class 603 contains the definition of the "viewport", i.e., the portion of the canvas which is currently visible on the display screen. This portion may be thought of as a movable rectangular viewport, which can be placed over any arbitrary section of the canvas. The viewport's location is manipulated by conventional horizontal and vertical scroll bars.

VDevice class 604 contains objects defining the appearance of corresponding network resource devices such as Controller or PhysicalDisk objects. For example, a VDevice object will contain color, size, coordinate location, etc., of a representation of a network resource device.

VConnection class 605 is similar to VDevice class, but contains objects defining the appearance of Connection objects on the screen.

Box class 606 and Text class 607 contain objects which define box and text annotations, respectively. Such annotations have screen location, size and appearance, but unlike VDevice and VConnection objects, have no corresponding object in the class library of FIG. 5. Box and Text objects support annotations which make the screen representation of a storage network easier to understand, but these annotations are not themselves part of the network

IGList classes 610-614 contain information defining the icons or other graphical images and associated text, which are part of respective VDevice, VConnection, Box, Text and Canvas objects.

FIG. 7 illustrates the relationship between VDevice objects and the corresponding network resource objects themselves, according to the preferred embodiment. For each VDevice object 701, there exists a corresponding object 702 which inherits from NetworkResource class 503. NetworkResource, being an abstract class, does not directly contain objects, but objects inheriting from it would include, for example, PhysicalDisk, IntController, Adapter, etc. When storage management program 331 is operating in configuration planning mode, VDevice objects send messages directly to corresponding objects inheriting from NetworkResource. DeviceMonitor object 703 is used only for the storage management program's data gathering and monitoring functions, and can, for example, send a message to a VDevice object causing its screen representation to change in response to some event occurring on the network. IObserver 704 and IStandardNotifier 705 are similarly used only for network data gathering and monitoring.

The data representing a management set can be saved as a file containing a series of records, and later reloaded without baving to generate the management set from scratch (either in planning mode or live mode). The format of saved records representing a management set is explained below in Appendix B.

The central manager obtains data from various sources. In live mode, most configuration data is obtained from the local agents, as explained herein. In planning mode, this data is generally provided by the user. Additionally, data can be saved as a file (as noted above) and reloaded. Finally, a considerable amount of configuration information concerns the capabilities of types of devices and how they may be connected to other devices, which change only when hardware or software changes. Much of this information is contained in a rules file, which is loaded into the manager at its invocation. For example, information such as the speed of a device, number of ports, etc., would be contained in the rules file. By including this information in a separate file, it is possible to more easily support hardware and software changes, addition of new device offerings, etc. The format of data in the rules file is explained below in Appendix C.

It will be understood that the above described object-oriented class structures are illustrative of a single embodiment only, and that many variations of data structures are possible. For example, in addition to varying forms of class libraries, the function described herein could have been implemented in conventional procedural code, in which data is encoded in tables, linked lists, or any of various forms. Furthernore, depending on the exact form of the implementation, some attributes or fields may be unnecessary, while additional attributes or fields may be required It will further be understood that the class structures described above are not necessarily the only class structures used by storage management program 331.

III. The Manager/Agent Interface

In the preferred embodiment, the local agent communicates with the manager across an information processing network medium which is independent of the storage network medium. Specifically, multiple host systems are connected via an information processing network operating in accordance with a TCP/IP protocol, it being understood that other protocols could be used. This protocol is intended to readily support client-server communication. The manager and agent utilize remote procedure call interfaces 322, 422 in the respective operating systems 321, 421 of the manager's computer system 110 and the agent's computer system 111.

In general, the local agent provides information to the manager in response to a command from the manager. Some commands may require the local agent to perform some action, such as a command to turn on an indicator light as part of a diagnostic routine. In this operating mode, the agent is acting as a server and the manager as a client.

The manager polls the local agent periodically to learn of storage network events. A poll is conducted by asking for three specific attributes associated with each storage network adapter topology events (events which affect physical device configuration), logical events (events which affect logical assignments of devices) and error events. This information is requested using the LL_GetAttr command, described below. These three attributes are maintained as counters by the adapters. A change in the count of any event indicates that an event of the corresponding type has occurred. The manager can then make appropriate further inquiries to determine the nature of the event.

The local agent stores information about "resources" and "primary relationships". A "resource" is an object of interest in the analysis of a storage network; it could be a physical device, such as a physical disk or adapter, or a logical construction such as a logical disk (which is really a collection of physical disks) or an SSA bus (a form of device bus, which is really a collection of individual bi-directional binary physical links). A "primary relationship" refers to a direct physical or logical connection from one type of resource to another. Primary relationship information is not reflexive; information in one direction may be different from information in the other. Examples of primary relationships are:

Host to Host Bus

Host Bus to Adapter

Adapter to Device Bus

Adapter to Logical Disk

Device Bus to Physical Disk

Device Bus to Unknown Device

Logical Disk to Physical Disk

The local agent also stores "attribute" information for various resources, i.e., information which describes a resource. A complete listing of attribute type information is contained in Appendix A. An explanation of the command (remote procedure calls) from the manager to which the local agent responds follows.

LL_ListResources:

This command calls the local agent to list all resources known to its host which match the parameters of the call. The local agent returns a resource list 901 as shown in FIG. 9A, containing a plurality of resource ID entries 902. Each resource ID entry 902 identifies a single resource, and contains technology code 903, major type 904, minor type 905, and resource tag 906. For most resources, technology code 903 specifies a type of storage network protocol, such as SSA or SCSI. Some resources, such as host systems and host buses, are not specific to any particular storage network protocol (and may in fact be connected to storage networks of heterogeneous protocols). For these resources, technology code 903 is undefined. Major type 904 specifies the main category of the type of resource. Examples of major types are Hosts, Adapters, Physical Disks, Logical Disks, etc. Minor type 905 specifies a resource type with greater particularity, allowing the specification of different types of devices falling into the same "major" class. For example, there may be several different types of physical disks supported, each having its own storage capacity and other attributes. Resource tag 906 is a unique identifier assigned to each resource, to distinguish it from all other resources of the same major and minor type. Resource tag 906 is derived from the device UID and/or machine ID, and contains information used by the central manager to distinguish and uniquely identify devices found by different hosts. I.e., the manager used resource tag 906 to determine whether two "resources" found be two separate hosts are in fact the same device. When the manager issues a LL_List Resources call to the local agent, it specifies a resource type by technology code, major type and minor type. The manager may specify wild card parameters. The list 901 returned by the local agent contains all resources which match the specified parameters.

LL_TypeConnections

This command calls the local agent to list the types of primary relationships that are possible from a specified type of resource. The manager specifies a resource type by technology code, major and minor. The local agent returns a connection type list 911 as shown in FIG. 9B, listing the resource types which may form a primary relationship with the specified type of resource, and the maximum number of each type that may be so related. Each entry 912 in connection type list 911 specifies a type of primary relationship by technology code 913, major 914 and minor 915. Entry 912 further specifies a cardinality 916 which indicates the maximum number of resources of that type which may form a relationship with the given resource, the number 0 indicating no limit. Entry 912 further contains volatile flag 917, which indicates whether the primary relationship needs to be rediscovered on the occurrence of an event. While it would be possible to maintain all this information in tables in the manager, retrieving it from the local agent provides more flexible support for the addition of new device types in the future.

LL_ListPrimaryConnected:

This command calls the local agent to list all primary relationships of a specified type from a specified resource. The manager specifies a particular source resource by technology code, major, minor, and resource tag. The manager further specifies a type of target resource by technology code, major and minor (thereby specifying a type of primary relationsbip). The local agent returns a listing of all target resources which meet the target resource p ers and have a primary relationship with the specified source resource, along with certain relationship information. The structure of the returned information is shown in FIG. 9C. The primary connection list 921 contains one or more entries 922, each identifying a target resource and connection details. The target resource is identified by technology code 923, major 924, minor 925 and resource tag 926. For each such target resource entry 922 in list 921, there is a variable length array of connection records 927, each connection record containing information about the relationship between the source and target resource. The connection record is in the form of a connection data type identifier 928 and connection data 929. In most instances, array 927 contains only a single entry defining the primary relationship, but it is possible to contain multiple entries. Connection data 929 may be a single value, or may be a complex data structure. For example, primary connection list 921 for a device bus type source resource (not shown) would contain entries identifying the various storage devices and adapters on the bus, and connection data 929 would identify for each such target device the devices immediately connected to it, and port numbers through which they are connected, thus identifying the correct order of devices to the manager. This call is the normal means by which the manager discovers the topology of the network.

LL_ListConnected:

This command calls the local agent to list all resources of a specified type which are related to a specified resource within a specified depth level. I.e., if a primary relationship is a level of 1, then a resource C having a primary relationship with a resource B having a primary relationship with resource A is at a level of 2 with respect to A, and so on. The manager specifies a source resource by technology code, major, minor and resource tag. The manager also specifies a resource type for the target resource by technology code, major and minor, and a depth level for the relationship. The local agent returns a list of resources having the same structure as resource list 901, and containing an entry for each resource satisfying the specified conditions of the call. For performance reasons, this manager does not normally use this command, but it is defined as part of the call protocol for possible situations in which a global inquiry is justified.

LL_GetAttr:

This command calls the local agent to list the current values of specified attributes for specified resources. In the call, the manager passes a list of resources and attributes, specifying one or more resources by technology code, major, minor and resource tag, and specifying one or more attributes by attribute name. The agent returns the information sought in a resource/attribute list 941 as shown in FIG. 9D. List 941 contains an entry 942 for each resource specified by the manager in the call. Each entry 942 contains a technology code 943, major 944, minor 945 and resource tag 946 identifying a particular resource, followed by a variable length array of attribute information applicable to the resource, shown as fields 947-949. The array contains attribute names 947, data types 948 and attribute values 949. Multiple attributes may be associated with a single resource. Additionally, multiple data types 948 and attribute values 949 may be associated with a single attribute. This latter feature permits an attribute value to be expressed using different data types. For example, as shown in FIG. 9D, the attribute named "OS_Type" (representing the type of operating system running on a host) can be expressed either as data tpe "DT_OSType" (which is an enumerated data type) or as a string. For certain attributes, attribute value 949 may be a complex data structure, such as an array or list.

LL_AttrDesc:

This command calls the local agent to return the description of an attribute. This call anticipates the situation where attributes defined to the local agent are unknown to the manager, either because new devices having new attributes are defined, or the local agent is more current than the manager. The manager passes the name of the attribute with the call. The local agent returns attribute description data structure 951 defining significant characteristics of the specified attribute as shown in FIG. 9E. Attribute description 951 includes attribute name 952 (an enumerated data type), English name of the attribute 953 (a string type), volatile flag 954, readable flag 955, writeable flag 956, host specific flag 957, English description of the attribute 958, catalog base name 959, name set number 960, name message number 961, description set number 962 and description message number 963. Volatile flag 954 indicates whether the attribute changes. Readable flag 955 and writeable flag 956 indicate whether the attribute can be read by the local agent or written to the local agent (from the perspective of the manager), respectively. Host specific flag 957 indicates whether an attribute is specific to a particular host; e.g., a disk storage device may be known by different addresses to different hosts. Fields 959-963 are used to specify a location for messages, to enable support for different human languages. I.e., a message associated with an attribute is specified by catalog base name, set number and message number, which specify a location in a table of messages; the table contains text of messages in the language of the user.

LL_SupportedAttr:

This command calls the local agent to return a list of all attributes applicable to a specified resource type. By making this call, the manager can determine what are the attributes of any given resource type. It can then use other calls, such as LL_AttrDesc or LL_GetAttr, to determine the characteristics of attributes or their current values. The manager specifies a resource type by technology code, major and minor in the call. The local agent returns a list of the attributes applicable to the specified resource, the attributes being identified only by their enumerated data type.

LL_SetAttr:

This command calls the local agent to change (write) an attribute for a specified resource. Attribute information is by its nature a characteristic of the local system, and therefore must be modified by calling the local agent Most attributes are not writable (can not be written to by the manager using this call), but certain attributes (e.g., indicator light on) can be altered by the manager. Alteration of such an attribute causes something to happen. These are used primarily for diagnostic and repair actions. The manager passes a list specifiing one or more resources by technology code, major, minor and resource tag. The manager also specifies an attribute and a value for the attribute (the "value" of an attribute is possibly complex information such as an array or list). The local agent responds by setting the attribute to the appropriate value. By passing a list of multiple resources, it is possible to set the corresponding attributes of several different resources to the same value in a single call.

LL_ConnectionDetails:

This command calls the local agent to supply additional information about a relationship between two specified resources. This information is not necessary for a minimal understanding of the network topology, but may be useful to the user for some purposes. E.g., the fact that a particular adapter is in a certain physical slot location in a host bus is irrelevant for determining the network topology, but may be useful to a user who needs to replace the adapter. The Manager specifies a pair of resources by technology code, major, minor and resource tag. The local agent returns a variable length connection record array, each array entry specifying some information about the relationship between the two resources. The format of the connection record array is the same as array of connection records 927 returned by the local agent in response to the LL_ListPrimaryConnected call (note that one array 927 is associated with each pair of resources).

IV. The Local Agent

The local agent provides data to the manager and performs certain tasks at its request. Specifically, the agent acquires topology and attribute information concerning one or more storage networks to which its host is attached, and supplies this information to the manager.

FIG. 10 is a high-level view of the agent and its interactions. Local agent 431 is programing code and associated data residing in a host system, executing on its CPU 401. Agent 431 includes local library 1001, network daemon 1002, and shared memory 1003.

Local library 1001 is an independently running thread which forms the central control portion of local agent 431. It communicates with the manager by making remote procedure calls, invokes operating system functions, obtains data from shared memory, and directly communicates with storage adapters when necessary. Network daemon 1002 is an independently runmling tread executing concurrently on CPU 401. Daemon 1002 continually monitors the state of the storage adapters in its host system, and writes this state information in shared memory 1003.

Shared memory 1003 is not a physically distinct memory, but simply a set of data structures in system memory 402 which are used by two independently running threads, local library 1001 and daemon 1002. Local hbary 1001 has read-only access to shared memory 1003, while daemon 1002 has read/write access. Semaphores are used for locking so that library 1001 will not read the contents of memory 1003 while daemon 1002 is updating it.

Local library 1001 communicates with the central manager through the operating system's remote procedure call facility 1014. In the preferred embodiment, facility 1014 handles all the interface details. The local library merely utilizes the appropriate operating system supplied programming interfaces to its remote procedure call facility. Library 1001 does not concern itself with the details of the interface protocol, this being an operating system function. It would, however, alternatively be possible to incorporate the remote communication function into the local agent.

Object Database Management facility 1010 (ODM) is a portion of operating system 421 which maintains a database concerning "objects", and provides an application programing interface (API) to the database, whereby an application may make queries of the database. The "objects" which are the subject of this database are various components of host system 111, and are not to be confused with progranuning "objects" in an object-oriented programming environment For example, ODM maintains information about buses, adapters, disk storage devices, and other components of system 111. Local library 1001 and daemon 1002 access this information through the odm_get_list, odm_change_obj, and getattr APIs to operating system 421.

In general, the information maintained by ODM 1010 is information of a static nature, which only changes when a "cfgmgr" AIX command is run following devices being added or removed, or the system is otherwise reconfigured. For example, ODM maintains information about which physical devices (buses, adapters, storage devices, etc.) are components of the system, the addresses of those devices, physical locations such as bus slots, etc. Most of the non-RAID related attribute information which can be requested by the manager through the LL_GetAttr command is stored in the ODM, the most notable exceptions being RAID-related attnbutes (which are maintained by ssaraid operating system facility 1012) and volatile information such as event counters, certain state indicators, diagnostic attributes, etc.

Ssaraid facility 1012 is also a portion of operating system 421. Ssaraid 1012 is an auxiliary tool designed to support RAID functions. It is used by local library 1001 to obtain certain RAID-related attributes of the storage devices. Nonmally, this tool is invoked by a user by entering a command on an operating system command line or via "smit". The local library achieves the same result by creating a string containing the command line text, and then executing the command by opening a pipe to the process (i.e. performing a popen() call). The output is then read from the process's stdout.

Both the ODM facility 1010 and ssaraid facility 1012 are particular facilities available in the operating system of the preferred embodiment, i.e., IBM's AIX operating system. Other operating systems may offer different facilities from which this information could be obtained. Alternatively, if necessary information is not available from an operating system utility, some part of the local agent could maintain the information. E.g., the daemon could maintain the information in shared storage.

Local library 1001 is activated upon receiving a call from the central manager. A timer is set upon the receipt of the call, and reset every time another call is received. If the timer times out without receiving a call during the timeout period, (currently two minutes), the local library thread of execution dies, and its local data disappears. In order to keep the library continuously running and avoid the need to restart it, the central manager normally sends an LL_GetAttr request at intervals of about 1 minute, requesting event counts. This request also lets the manager know if there has been any change in event counts which might indicate that other action should be taken.

While running, the local library is normally idling while waiting for a request from the central manager. When the request isreceived, the library must parse it to determine how the information will be obtained. There is an action corresponding to each type of request, which may also vary with the parameters of the request. Most information used to satisfy requests is obtained from shared memory 1003, but it may also be obtained from ssaraid facility 1012, ODM facility 1010, or directly from an adapter itself. The requested information might be read directly from data records (e.g., from shared memory), or it might involve an exchange of communications between the library and the adapter. For example, a LL_Gettr request, which requests attribute information, is handled by calling the ssaraid facility 1012 if the requested attribute is a RAID-related attribute, but the same request is handled by retrieving information in shared memory 1003 if the requested attribute is an event count. The local library must also determine in which data structure and location the information can be found. The requested attribute may, for example, be located in one place for a disk and another for an adapter. Finally, some requests contain "wild cards" which may be used in place of specific parameters of the request.

The process whereby the local library determines how to service a request is shown diagrammatically in FIG. 11. A request received from the central manager is represented generically as 1101. This request contains a command field 1102 identifying the type of request, and multiple parameter fields 1103, 1104, 1105 containing the parameters of the request, it being understood that the number of parameters may vary. A parameter may contain a wild card. In the example of FIG. 11, parameter field 1105 contains a wild card parameter. The local library initially expands all wild card parameters by looking in wild card table 1120 for any entry corresponding to the field, command, or other parameters. In the preferred embodiment, the wild card table is fairly small, and therefore sophisticated indexing (such as hashing, binary tree search, etc) is not necessary. Each entry in wild card table 1120 contains a list of the parameters to which the wild card is expanded. The local library uses this list to convert the original request into a series of requests 1110, 1111, 1112, one corresponding to each parameter on the list, by replacing the original wild card with a respective list entry from wild card table 1120.

The local library then processes each of the series of requests 1110, 1111, 1112 (or the original request if there were no wild cards in it) by generating a hash key 1115 from certain request parameters, and using this key to access one of hash tables 1121, 1122, 1123, 1124, or 1125. The library contains five hash tables, each corresponding to one or more types of requests. Specifically, these tables are:

Attribute Table

Primary Connection Table

List Resources Table

List Connection Table

Connection Details Table

The type of command (not its parameters) determines the table to be accessed, as depicted in FIG. 11.

Each entry in one of hash tables 1121-1125 contains a set of input parameters and a pair of function pointers. The first function pointer points to a function used to read the requested information; the second function pointer points to a function used to write the information. This design includes the flexibility to read or write any data, although in general, one of the function pointers is null, since most information is either read or written, but not both.

A hash key for accessing one of hash tables 1121-1125 is generated from the parameters of the request. The hash key function for each respective table is listed below:

Attribute Table:

Key=(int(TechCode)+int(MajorType)+int(AttrName)*int(RDE _EndStop) mod TableSize

Primay Connection Table, List Connection Table, or Connection Details Table:

Key=((int(FromTechCode)+int(FromMajorType))*int(TC_EndStop)*int(RT_EndStop) +int(ToTechCode)+int(ToMajorType)) mod TableSize

List Resources Table:

Key=(int(TechCode)*int(TC_EndStop)+int(MajorType)*3) mod TableSize

Where:

int(TechCode), int(FromTechCode), int(ToTechCode) are the Technology Codes converted from enumerated values to integers for the specified parameter, the source device, or the target device, respectively;

int(MajorType), int(FromMajorType), int(ToMajorType) are the Major Type converted from enumerated values to integers for the specified parameter, the source device, or the target device, respectively;

int(AttrName) is the Attribute Name converted from an enumerated value to an integer;

int(TC_EndStop), int(RT_EndStop), int(RDE_EndStop) represent the number of possible enumerated values of TechCode, MajorType and AttrName, respectively; and

TableSize is the modulus of the hash key, currently set at 100.

The hash key indexes an entry in the appropriate hash table. Because a hash key is not necessarily unique, this entry will not always be the desired entry. The input parameters of the entry are compared to the input parameters of the request 1112. If they do not match, each subsequent entry in the hash table is compared until a match is found. Due to the granularity of the hash key, typically no more than a few compares are necessary to find the correct entry. The function pointer in this entry contains a pointer to the function which services the request 1130. It will be observed that it is possible for multiple hash table entries to point to the same function. This function is invoked, passing the parameters in request 1112.

In would alternatively be possible to hard code the access to different functions or procedures by means of a series of "Case" statements or other branching constructs supported in the progr ming language being used. However, the sheer number of possible functions supported by the local agent and the need to make provision for future alterations makes such a structure unwieldy. The use of hash tables to access function pointers, as described above, is easier to maintain and rapid to execute.

While shared memory is depicted as a single block 1003 in FIG. 10, its structure and operation are actually somewhat more complex. Daemon 1002 needs to be able to update a configuration record synchronously with local library 1001 reading configuration information. Therefore, there are actually three repositories of configuration information, one local to the local library, one local to the daemon, and one shared.

Network daemon 1002 is free to update its local copy of configuration information at any time. This enables it to run at fill speed, which is essential, since it handles live synchronous events (interrupts) from hardware. Only when it has a complete and consistent set of information does it attempt to update shared memory 1003 to the latest version, having first obtained a wite-lock semaphore. If the write-lock semaphore is unavailable, the network daemon continues to run unhindered, preparing the next version of the configuration information. Since the network daemon is not suspended when the write-lock is unavailable, it can keep records of events/interrupts, so that information is not lost when the daemon is unable to write the information to shared memory owing to a failure to obtain a write-lock semaphore. (Ibe usual reason for being unable to obtain a write-lock semaphore is that the network daemon has tried to obtain it at the very instant that the local library is already reading shared memory, having engaged a read-lock semaphore.) Since both daemons have their own local copies of the configuration information, the only time the use the semaphores is during the brief instants that it take to read or write shared memory. For the majority of the time, each works on its own copy of the information.

The local library is free to access its local copy of the data, completely unhindered by whatever updates may be available in shared memory. I.e., it can access the local copy many different times over a period of several seconds, knowing that the information at the last access is consistent with the information at the first. When the local library is at a suitable point in its function to request any current configuration information (usually at the start of a major function call such as LL_ListResources), it obtains a read-lock semaphore, and reads in the latest information from shared memory. Since it has the read-lock semaphore, it is guaranteed that the network daemon cannot update shared memory while the local library is tying to read it If the local library is unable to obtain the read-lock, it sleeps for a very short period, then tries again.

FIGS. 12A through 12C illustrate the major data structures held in shared memory 1003. FIG. 12A shows the overall structure of topology information in shared memory. This includes header block 1201, a collection of adapter records 1202, a collection of SSA node records 1203, hash table for device universal identifiers 1204, and table of string number universal identifiers 1205. Header block 1201 defines the memory allocation for shared memory 1003 and includes certain additional information such as the process ID of the network daemon. Hash table 1204 is used for rapid (semi-random) access to a particular SSA node record in collection 1203, as explained below. String table 1205 is used to store the universal identifier of strings of devices (as used here, "string" means an SSA bus, and includes a closed string, or loop, topology).

The bulk of topology information is contained in collections 1202 and 1203. Adapter collection 1202 contains one adapter record 1220 for each adapter located in the host system containing the local agent. SSA node collection 1203 contains one SSA node record 1250 for each SSA node on a SSA bus attached to an adapter in the same host system. The adapter itself is represented by two SSA node records, since an adapter has two pairs of ports (may be attached to two separate SSA buses).

FIG. 12B shows the structure of an adapter record 1220. Adapter record 1220 contains the following fields. Adapter name field 1221 identifies the adapter's name as known to ODM 1010. Adapter UID field 1222 contains the universal identifier of the adapter. Adapter serial number field 1223 contains the hardware serial number of the adapter. Smart adapter flag 1224 indicates whether the adapter is type "F" (smart adapter) or type "M". Adapter node number field 1225 contains an identifier used by the SSA device driver in accessing the adapter. Bus number field 1226 contains the host bus number on which the adapter is located. Slot number field 1227 contains the physical slot number within the host bus where the adapter is located. Daughter number field 1228 contains an identifier of a daughter board in which the adapter is located, if mounted on a daughter board. Partner number field 1229 is used to identity another adapter ("partner") on the same string. SIC A SSA Nodes pointer field 1230 contains a pointer to the SSA node record 1250 for the first pair of ports on this adapter known as SIC A). Port1 length field 1231 and port2 length field 1232 contain respectively the lengths of the string of devices attached to port 1 of SIC A and port 2 of SIC A; where this string is a closed string (loop), the value in port2 field 1232 is set to -1, and port1 field 1230 reflects the actual number of devices on this string. Additionally, loop flag field 1238 is set in this case. Topology version field 1234, logical version field 1235, and error version field 1236 are version counter fields for topology events, logical events, and error events, respectively. Change count field 1233 changes whenever any of fields 1234-1236 changes, indicating that an event has occurred. Need rescan field 1237 is used to indicate that the string should be re-analyzed as a result of some event Using List_SSANode field 1239 is a flag to indicate whether the List_SSANode function may be called for this SSA bus; this function is only available on type "F" adapters in which the configuration is legal. PosUncertain field 1240 is a flag to indicate that the position of the adapter within the string of devices is uncertain; this is true only in rare cases. A separate copy of fields 1230-1240 exists for the SIC B pair of ports.

FIG. 12C shows the structure of a SSA node record 1250. SSA node records are organized as a doubly linked list of records in hash index order. I.e., a hash index number for each SSA node record 1250 is computed from the lower order digits of the device universal identifier, and records are inserted into the list at the appropriate ordered location. Previous hash entry field 1251 and next hash entry field 1252 contain pointers to the previous and next SSA node record, respectively. If a specific device is to be accessed, its hash table index can be readily computed, and hash table 1204 used to obtain a pointer to a SSA node record having the same hash index. If this is not the desired record, the chain of next hash entry pointers 1252 is followed until the desired record is found. This is much faster than traversing the entire list of SSA node records (which may be very large) every time a record is to be accessed. Old unused SSA node records are placed on a separate free list, which is a singly linked list, for recycling should a new record be needed. Next free entry field 1257 contains a pointer to the next device on the free list if the record is on the free list. In use flag 1260 indicates whether a SSA node record is currently in use (i.e., on the doubly linked list of active records).

String number field 1256 contains an index to a value in string table 1205. The value in table 1205 is the universal identifier of the device in the same SSA bus (string) having the lowest universal identifier. This value is used to uniquely identify an SSA bus. Because this value is subject to change if devices should be added to or removed from the SSA bus, the SSA node record contains an index to table 1205, where the universal identifier for the string resides. Thus, if a device is added or removed causing the lowest number UID to change, it is only necessary to change the value in string table 1205, without changing each individual SSA node record.

Device UID field 1253 contains the universal identifier of the device at this SSA node. Device type field 1254 contains the type of device. UID is valid 1255 is a flag indicating whether the value in field 1253 is valid; in the case of unknown devices, the network daemon will create a fictitious identifier to distinguish the unknown device record from other records. This adapter-number field 1258 contains an index to an adapter record for an adapter connected to the same SSA bus. Where multiple adapters are connected to the same SSA bus, the daemon arbitrarily chooses one. Field 1258 is used to access the device through an adapter, so if there are multiple adapters, it doesn't matter which one is used. This network index field 1259 specifies which pair of ports (SSA bus) on the adapter is connected to the device. Reserved field 1262 is not used. Total ports nuimer field 1263 contains the number of ports on this device; this allows for future accommodation of storage devices having more than two ports. Error event time field 1264 indicates when this SSA node last reported an error event.

Map coordinate fields 1266-1269 are used only in diagnostic mode, for displaying a direct map of the network as seen by the network daemon, without intermediate alteration of data by the central manager. The Map position uncertain field 1265 is similarly used in diagnostic mode to indicate uncertainty in map position.

Port1 next device index field 1270 and port2 next device index field 1271 contain pointers to the SSA node record of devices attached to port1 and port 2 respectively of the current device. Port1 next device port field 1272 and port2 next device port field 1273 indicate which port number on the next device is attached to port 1 and port 2 respectively of the current device. In some cases (specifically, where type "M" adapters are used), the daemon is unable to determine which port numbers are used. In this case, port numbers are arbitrarily assumed for purposes of entering data in fields 1271-1274, and port uncertain flag 1261 is set to indicate that the daemon really doesn't know which ports are being used.

It will be observed that the data structures can be easily expanded to accommodate devices having different numbers of ports, by addition of another substructure containing fields 1230-1240 (in the case of an adapter serving more than two SSA buses) or 1270 and 1272 (in the case of a disk or other device at an SSA node).

Like the local library, network daemon 1002 operates on a timed life cycle. Specifically, shared memory 1003 is available to local library 1001 only when network daemon 1002 is active. If local library 1001 needs to access the data in shared memory 1003 and network daemon 1002 is inactive, local library 1001 starts the network daemon via a UNIX fork() & exec() operation. It then waits a predetermined time, and retries the access to shared memory. Upon sing the network daemon, a UNIX alarm() function time is started. The timeout period is preferably 15 minutes. However, local library 1001 also sends the network daemon a signal via the UNIX signal() function whenever local library accesses data in shared memory 1003. Upon receipt of this signal, the network daemon resets the alarm timer to the full original timeout period. The expiration of the timeout period causes a timer signal to shut down the network daemon. Upon receipt of this signal, the network daemon self-terminates, removing its data from shared memory 1003. Thus, the network daemon will remain active so long as the data in shared memory 1003 is accessed at intervals of less than 15 minutes.

While network daemon 1002 is active, it periodically checks the configuration of all networks attached to the host in which the daemon is located It initially obtains a listing of all adapters in the host (via an odm_get_list call to ODM 1010), and establishes the topology information repository in shared memory 1003. It then analyzes the topology of the network(s) attached to the listed adapters, and updates the topology information repository in shared memory 1003. The daemon then idles for a period, at the end of which it wakes up, checks for events and re-analyzes the network as necessary, and then updates the data in shared memory again. It continues to idle and re-check the network at periodic intervals. The period may be specified by a user, and is typically 10 seconds. It will be observed that the network daemon has no knowledge of how devices are grouped in management sets; it simply-obtains information for all devices attached to its host, and stores this in shared memory 1003.

The complexity of configuration analysis performed by daemon 1002 depends greatly on the type of adapter and network configuration. Certain controllers have more advanced capabilities. The network daemon of the preferred embodiment currently supports controllers of two basic types (designated type "M" adapters and type "F" adapters), it being understood that additional types having other capabilities could be supported. Type "F" adapters have more advanced function than type "M" adapters. Specifically, a type "F" adapter is able to detenmine the identity and position of all devices attached to it via a network (assuming the network is a "legal" configuration, i.e., configured according to certain pre-established rules). A type "M" adapter will not be able to determine the identity of other controllers in the same network, although it may know that there is a device of unknown type at the location.

The simplest case of configuration analysis performed by daemon 1002 is a legal network configuration attached to a type "F" adapter. In this case, the network daemon issues a List_SSANodes call to the adapter to list all devices visible to it. The adapter responds with a complete list of devices on the network, including device identifiers and position information. The network daemon then formats this information according to the format described above and stores it in shared memory 1003.

A user can easily create an "illegal" network configuration. E.g., the number of devices in a loop or string may exceed a pre-determined threshold, or cross-connecting of two separate networks on a single adapter. Such configurations, because they violate established configuration "rules", will cause the configuration record in the "F" adapter to be incomplete. The network daemon therefore "walks" the network, one node at a time, to determine the actual configuration. I.e., the network daemon issues transactions to the adapter to determine if there is a device connected to a particular port of the last known device, and if so, it attempts to analyze that new device. As it walks the network, it records which port of a device it "came in on", then uses the other port to continue its analysis if possible. For example, if an adapter connects to a disk via that disk's port 1, then the network daemon will examine the disk's port 2 for further devices. It repeats this process until it either runs out of devices (reaches the end of a string), or returns to the original adapter (loop). When "walking" the network, the daemon first examines the voltage at certain port pins to determine whether there is a device connected to the port, and only if the voltage indicates something connected, it sends a message to the connected device. It does this in order to avoid sending messages to non-existent devices, which could trigger extensive and time consuning diagnostics.

Where a network is attached to a type "M" adapter, the process is substantially different. Network daemon 1002 issues a call to the adapter to list all devices visible to it. This list will not necessarily be complete, since disks that are not ready or other adapters will not be visible. For each device found, the daemon issues another call to the adapter, to determine the device's hop count from each port of the adapter. A device with a hop count from each port of a pair is in a loop, whereas a device with only one hop count is in a string topology. After collecting all this information, it may be deduced that where there are missing hop counts, there are devices of unknown type. The network daemon then builds an internal map of reported devices. Devices represented as unknown type are included in the table where there are hop count gaps. Note that in some cases a hop count gap will not be apparent to the "M" adapter or its local agent. I.e., where an adapter in another host is at the end of a string, no gap will appear. Only the central manager is capable of resolving this topology, if it knows about all hosts..

If multiple "M" adapters in the host of the local agent are attached to a single network, each adapter will be unable to determine the identity of the other (although it may know there is something at the position in the SSA network of the other adapter). The daemon must resolve the identities of these adapters to obtain as comprehensive a view of the network as possible, even though the daemon will not be able to determine the identity of "M" adapters located in other hosts.

This resolution process is depicted in FIG. 13. Initially, each controller ("M" adapter) is analyzed as described above to create a network map as seen by that controller. If there is a SSA bus to which multiple "M" adapters are attached, i.e., the bus identifier is the same, then a first (base) controller ("M" adapter) is arbitrarily chosen from among the multiple controllers on the bus (step 1301). The network map as seen by the first controller may have one or more gaps representing locations where other controllers may be located.

The daemon then selects another controller, and analyzes that controller's view of the bus. The daemon selects a pair of devices to serve as cross-reference objects (step 1302). These must be devices of a type which will respond to "M" adapters, i.e., disk drives. Preferably, the daemon selects one device on either side of the selected controller. I.e., starting from one port on the controller, it hops along the network until it finds such a device, and does the same for the other network port of the controller. If it is not possible to find a device on either side of the selected controller, two different devices on the same side (reachable from the same port) of the controller are selected. This may occur, for example, where the network is a string instead of a loop, and the controller is at the end of the string. A cross reference object data structure is created for each of the pair of devices, which contains the hop count from the selected controller, and two "PossibleInd" pointers indicating possible locations of the controller.

Referring to the network map derived from the base controller, the daemon finds the location of a selected cross-reference device, and hops from this location the "hop count" to some network location (step 1303). This location (which may be a gap, or may be a device) is one of the "PossibleInd" locations, and is entered in the appropriate data structure (step 1306). In hopping along the network, it is possible to hop past the end of the network (i.e., a network in a string configuration). If this occurs (step 1304), additional gaps are added to the end of the network map, to represent devices of unknown type (step 1305). The daemon repeats this process for each direction (two) of each cross-reference object (two), a total of four repetitions (step 1307).

When all four "PossibleInd" locations have been determined, the daemon compares the two in one cross-reference object with the two in another (step 1308). If there is a match (step 1309), then this "gap" is the correct location of the selected controller, and the network map of the first controller is resolved to reflect this fact (step 1310). If there are additional controllers in this network and in the local agent's host, the process repeats until all such controllers have been analyzed (step 1311).

In the initial information gathering phase, the network daemon created separate sets of information for each adapter. Once the unknowns are resolved as described above (i.e., two adapters on the same network), one set of information will be deleted as duplicative, and the originally unknown device in the other network will be edited to include all the adapter information from the deleted set.

Referring to the example storage network of FIG. 1, this process will be described as performed by the network daemon within host 111. At step 1301, the daemon initially selects controller 130 (C130) as its base, and builds the following network map as seen by C130:

C130-D120-D121-D122-D123-D124-gap1-gap2-D129-D128-D127-D126-D125-gap3---

This network is actually a loop, gap3 connecting back to C130. At step 1302, the daemon selects C131 and identifies two cross reference devices, one on either side of C131. The nearest devices are D125 and D120, which are selected. The following cross reference object data structures are created:

                X-ref I                X-ref II
                DiskHop: 0             DiskHop: 1
                DiskID: D125           DiskID: D120
                PossInd1:              PossInd1:
                PossInd2:              PossInd2:

              X-ref I                  X-ref II
              DiskHop: 0               DiskHop: 1
              DiskID: D125             DiskID: D120
              PossInd1: D126           PossInd1: gap3
              PossInd2: gap3           PossInd2: D122